これ良い。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
というか、この動作明らかにヘン。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:~$
既にあるコードが何らかのアクセラレータの仕様を前提としていない以上、一旦GPU側のメモリにコピー→処理→CPU側のメモリへコピーという手順は不可避な気がする。んでもって、そのオーバーヘッドも多分あまり無視できないレベルかも。
うーん、あまり細かいデータばかりだとGPUとの受け渡しにかかわるオーバーヘッドが大きくなるから速度向上は狙えないような気がする。GPUがメインメモリ上のデータを直接触れるんなら話は変わるんだろうけど（できるの？）。
sgemv_accum16
rows 48 cols 512 col_stride 48
rows 48 cols 16 col_stride 48
rows 512 cols 16 col_stride 512
rows 128 cols 306 col_stride 128
rows 128 cols 384 col_stride 128
rows 128 cols 128 col_stride 128
rows 1152 cols 128 col_stride 1152
Arc A770、動き出しました。
しかしOpenCL版のdistributed.net clientは動きません。
ちゃんと動いている物があるなら、エラーをわざわざ起こしておかしな状況を作り上げる必要も無いっちゃ無いんだがな…
clCreateBuffer()で-6(CL_OUT_OF_HOST_MEMORY)が発生し戻り値がNULLになってる。その領域に対し何かをしようとしてN/Aになってるがこの時にどういうエラーが出てるか、かなあ。そしてひたすらNULLに対して書き込みを試みた場合に何が起こるか、も要確認か。
そういえばUHD730でbwocl実行した場合、clEnqueueCopyBufferに失敗して測定結果がN/Aになるケースがありましたね…もしかして失敗するケースが重なるとおかしくなるというパターンなんでしょうか（今のところ問題なく動いちゃってますねえ）
uaa@DESKTOP-251U0UF:~$ ./cltest 0 0
Fri Aug 11 06:50:44 2023 6460102770
とりあえずテスト開始のメモ
bwoclそのものじゃないけど、簡略化したコード書いてちょっと試してるところ。タイムスタンプも表示させるようにして、何時間回すと落ちるかも分かるようにしてみたけど…大体この手のテストって、テストコード変えちゃうと問題が起こらなくなるとかそういうのがあるんだよなあ。
WSLg上の環境だけ落ちますねえ。テストプログラムをもう少し簡略化するなりして要点を掴んだものを作って、追いかけてみたいところですが…それやってるといつまで経ってもArcを載せられなくなってしまう。