ビギナートランジスタ読本などの、奥澤清吉先生の本…最近はオークションでも出物は少ないし値段も上がってる感じ。

fdata-sectionsでデータをセクション分けして（そのサイズも取れる？）、それをVideo-RAMへ転送するコードを書けばいいんだろうか…なんかROM化コードと同じようなことをやろうとしているような気がしなくもなく。

（伏せる）一択じゃん…（他を知らないので）

nostr:npub1rarr265r9f9j6ewp960hcm7cvz9zskc7l2ykwul57e7xa60r8css7uf890 なんかこの辺のバッファの内容もGPU側から触れるように細工しないとダメっぽい

uaa@emeraude:~/LPCNet$ grep static build.opencl/_deps/lpcnet-src/nnet_data.c

static float gru_a_embed_sig_weights[294912] = {

static float gru_a_embed_pred_weights[294912] = {

static float gru_a_embed_exc_weights[294912] = {

static float gru_a_dense_feature_weights[147456] = {

（省略）

uaa@emeraude:~/LPCNet$

なんか知らんソースを自動生成して食わせてんのかよ…💢

うーん、思いつくところは書き換えたんだけど、どうもSVMとして確保したメモリではないポインタを食わせようとしている箇所があるようで、「そんなアドレスは知らぬわ」と蹴られるんだよなあ

nnet.cおよびlpcnet.cの、該当するコードの該当する関数が使うバッファを、ベクタエンジン用のバッファに挿げ替えるという面倒な作業があるけど…手間がかかるだけで（再帰とかstaticとか使ってなさそうだと）厳しいものではないと思う多分きっとおそらく。

そこまで手をかけても、実はAVXの方が早いのでした残念、という結果になる可能性は高いと思うよ？

test_vecのSVM対応は終わった。ここから本番…nnet他全て必要なものを、SVM対応しないといけない（面倒臭い）。

xiph版は当然使ってた

ちょ、sgemv_accum8x4もsparse_sgemv_accum8x4もdrowe/LPCNetでは未使用なのか…（xiph版はどうなんだろ）

CH55xをArduinoIDEで使う (2022/01/09) https://qiita.com/akita11/items/d7baed4ca3c06e292637

あー、ビルドし直しだこれ（無理やり-lOpenCL突っ込んでビルドしたからそれを再度やるのは面倒すぎる…CMake周りの整備しないとダメっすかそうですかマジやりたくない…）

AVX最適化入れて、i3-13100で4秒未満（i7-7700でも7秒切り）。

i7-13700KですらRTX4090を回しきれてないって、どんだけのCPU持ってくれば良いんですか…？ https://pc-builds.com/ja/bottleneck-calculator/result/1jC1ci/1/general-tasks/1920x1080/

ボトルネック計算機…どの程度信用できるかは分からないけど https://pc-builds.com/ja/bottleneck-calculator/ i3-13100+RX6400だとグラボが弱い、RTX3060はちょうどよい塩梅という表示になってる。RTX3080だとプロセッサが弱い。

GPU買うならOpenCLに触ってみるか…そういやLPCNet（ニューラルネットワークを使った音声CODEC）を以前AVX→SSE化したけどこれはGPUで速くなるんだろうか？という疑問があったので愚直にそれを実行してみたという訳です。

ここまで遅くなるとは、と逆に驚いちゃったけど…GPUに演算をさせる場合にどういうところが問題になるのか、というのは少しわかった気がする。

g: VRAM→メインメモリ p:メインメモリ→VRAMで見てみたけど、これは粒度が細かすぎて（転送コストが高すぎて）メインメモリ上でAVXに任せた方が速いに決まってる案件なのかも。

g 1024

g 128

g 1536

g 192

g 2048

g 3072

g 4608

g 512

g 64

p 1024

p 11348

p 1224

p 128

p 1536

p 157184

p 192

p 197120

p 2048

p 3072

p 3264

p 34816

p 416

p 4608

p 479232

p 512

p 576

p 594432

p 64

p 66048

p 98496

でもなんかOpenCL越しに何かが動いてる、ってことだけは確かっぽい。

ズレてる…？

sparse_sgemv_accum16..............: fail

0 0.000000 1.000000

1 1.000000 2.000000

2 2.000000 0.000000

3 3.000000 1.000000

4 4.000000 2.000000

5 5.000000 3.000000

6 6.000000 4.000000

7 7.000000 5.000000

8 8.000000 6.000000

9 9.000000 7.000000

10 10.000000 8.000000

11 11.000000 9.000000

12 12.000000 10.000000

13 13.000000 11.000000

14 14.000000 12.000000

15 15.000000 13.000000

16 80.000000 74.000000

17 83.000000 77.000000

18 86.000000 80.000000

19 89.000000 83.000000

20 92.000000 86.000000