sparse_sgemv_accum16の場合、

ix = idx;
for (i = 0; i < rows; i += 16) {
cols = *ix++;
for (j = 0; j < cols; j++) {
ix++;
x_cnt++;
y_cnt += 16;
w_cnt += 16;
}
}
idx_cnt = ix - idx;
とでもして、事前にデータサイズを測ってからGPUに食わせるしかないのかも。

書いてみたところで動くかどうかも知らないし、パフォーマンスが出るかどうかも知らない。今はそれ以前の問題だし。

sparse_なんとかの類、これってGPGPU向きじゃない気がする。結局何バイトのデータをの出し入れしないといけないのか、というのがちょっと分からないんだけどコレ。 https://github.com/drowe67/LPCNet/blob/master/src/vec.h#L165 （OpenCL側のコードをホストから呼び出すコードを書く際に気づいた…気づくの遅いよ！）

いや、全部が全部実装してないな…

うええ、3通りのコードが要るのこれ、同じ関数なのに。
DOT_PRODあり：USE_SU_BIASあり
DOT_PRODあり：USE_SU_BIASなし
DOT_PRODなし

これ良い。OpenCL Cで書いたコードを予めビルドできればerror -11に悩む心配がなくなる… https://github.com/koturn/oclc

test_vecだと
sgemv_accum16rows 160 cols 2 col_stride 1
sparse_sgemv_accum16 rows 32

こいつはSSE/AVX/NEON化はされているが…OpenCL化したらどうなるかというのは結構気になっていて。 https://github.com/drowe67/LPCNet/blob/master/src/vec.h

GPU温度は55～56℃。部屋がまだ涼しいのもあるしテストコードが止まってるのでGPUがヒマしてるからってのもある。とはいえ、足元からぬるい風が吹いてくるのはこの季節は地味にツラいものがあるな…

というか、この動作明らかにヘン。UHD730だと7秒毎、Arc770だと1秒毎にタイムスタンプが付いてくんだけど…それ以上の時間になってる。なんとなくなんだけど、長時間動作で落ちる系ってメモリリークの類だったりしないか？（それも簡単に再現できないやつ）

…テストプログラム、killedで落ちてる。
Sat Aug 12 02:52:18 2023 19 599545324
Sat Aug 12 03:03:34 2023 20 599926237
Sat Aug 12 03:13:27 2023 21 599044050
Sat Aug 12 03:20:28 2023 22 599798131
Sat Aug 12 03:30:45 2023 23 601436247
Sat Aug 12 03:36:21 2023 24 600044281
Sat Aug 12 03:44:41 2023 25 600336348
Sat Aug 12 03:56:29 2023 26 600504050
Sat Aug 12 04:04:55 2023 27 599742801
Sat Aug 12 04:23:35 2023 28 604521154
Sat Aug 12 05:36:35 2023 29 615542402
Killed
uaa@DESKTOP-251U0UF:~$