まさに五里霧中な状態で手探りで触っています(笑)
見れば見るほど節々が怪しく感じるggml-syclなのですが、現状焦点をあてた部分を何度か作り直しながら着実に進んでいるという実感を得つつあります。
まずは、動かすことを目標に手を入れてみました。
convert.cppの中の型変換処理ロジックの一部になっている部分に手を入れていますが、ダメな部分は、全ての要素を一次元で扱っているため、扱うインデックスが色々と制約に引っかかってきてしまいます。まずはこれを疑似的に次元を増やしてみました。が、この方針は結果的にポインタ操作の制限を簡単に超えてしまいあまりうまくいきませんでした。それでもの実装を行ったことでCUDAとSYCLの違いがようやく見えてきました。
SYCLの実装のドキュメントを見てみると、結構柔軟にできていることも実感しつつ、再度一次元で実装する形で実装しなおしました。ただ、これはスタート地点と同様の制限に絡んでくるので、さらに実行時に処理を分割することで対処しました。この分割するような処理はすでに組み込まれている感じなのですが、CUDAからコンバートしただけで、しかも元となるCUDAの実装も変更され改善されているのですが、現状のSYCLの実装は古いCUDAのコードが基になっている感じが強く、あまり意識しすぎるとロジックがおかしくなって行くので、できるだけ簡素に実装することにしました。
実装後実行してみるとqueueに分割して処理を投げ込む形になるのでとりあえずいつものようにwait()で同期をとりながら溢れないように回避させました。
ここまでくると、今まで止まっていた場所ではない部分で不具合が出てくるわけで…(笑)
最初は少し違う部分でlevel_zeroのエラーが発生してしまったので調べてみるとホストメモリーが足りないとかそんな感じだったので様子を見てみると、メインメモリーを食いつぶして処理がkillされました…ｗさっきはエラーメッセージが出てたので、少しの差でぎりぎり死んでる感じです。swapを用意すれば動いてくれそうな気もしますが、sdの実行時のオプションの--faを付けてみたところ、メインメモリーの消費の仕方が変わったのですが、余計な処理が走ってしまうようで…
[SYCL][OP] call ggml_sycl_add done
[SYCL][OP] call ggml_sycl_silu: dst=' (view) (view) (view)':type=f32;ne=[128, 128, 512, 1];nb=[4, 512, 65536, 33554432] src0=' (view) (view)':type=f32;ne=[128, 128, 512, 1];nb=[4, 512, 65536, 33554432]
[SYCL][OP] call ggml_sycl_silu done
[SYCL][OP] call ggml_sycl_im2col: dst='node_96':type=f16;ne=[4608, 128, 128, 1];nb=[2, 9216, 1179648, 150994944] src0='leaf_29':type=f16;ne=[3, 3, 512, 512];nb=[2, 6, 18, 9216] src1=' (view) (view) (view)':type=f32;ne=[128, 128, 512, 1];nb=[4, 512, 65536, 33554432]
[SYCL] ggml_sycl_op_im2col max_work_group_size:512
[SYCL] im2col_sycl num_blocks:18 OW:128 N_OH:128
[SYCL] im2col_sycl global(128, 128, 4608) local(1, 1, 256)
[SYCL][OP] call ggml_sycl_im2col done
[SYCL][OP] call ggml_sycl_mul_mat: dst='node_99':type=f32;ne=[16384, 512, 1, 1];nb=[4, 65536, 33554432, 33554432] src0=' (reshaped)':type=f16;ne=[4608, 16384, 1, 1];nb=[2, 9216, 150994944, 150994944] src1=' (reshaped)':type=f16;ne=[4608, 512, 1, 1];nb=[2, 9216, 4718592, 4718592]
[SYCL] ggml_sycl_op_mul_mat_sycl (1)
[SYCL] ggml_sycl_op_mul_mat_sycl (2)
[SYCL][OP] call ggml_sycl_op_mul_mat_sycl/to_fp32_sycl: dst='node_99':type=f32;ne=[16384, 512, 1, 1];nb=[4, 65536, 33554432, 33554432] src0=' (reshaped)':type=f16;ne=[4608, 16384, 1, 1];nb=[2, 9216, 150994944, 150994944] src1=' (reshaped)':type=f16;ne=[4608, 512, 1, 1];nb=[2, 9216, 4718592, 4718592] : converting src0 to fp32
[SYCL] ggml_sycl_op_mul_mat_sycl consted.
[SYCL] ggml_sycl_op_mul_mat_sycl asserted.
[SYCL] ggml_sycl_op_mul_mat_sycl alloced.
[SYCL] convert_unary_sycl k:75497472
[SYCL] convert_unary_sycl local x:512
[SYCL] convert_unary_sycl global x:75497472
[SYCL] convert_unary_nc_sycl ne02_fdv(1,0,1)
[SYCL] convert_unary_nc_sycl global_x:262144 local_x:512 cnt:75497472
また違うところでGPUが沈黙してしまいましたｗどこかでqueueに処理を投げすぎてあふれさせたのだとおもいます。このログを見る限り f16からf32への変換処理で落ちてそうですが…まぁ--faなしの時よりも前で止まってるのでどこから手を付けるか…正直ちょっと疲れたので休憩がてら愚痴ってたりします(笑)
im2colに手を加えた部分も意味が解ってない状態で手を入れているのでそちらもちゃんと動いているのかが謎だったりしますが…
なのでちょっと512x512で実行して出力がまともに行えているか確認していました。
テストで1stepで実行しているので判断に困るような画像が出力されましたが、何か出力されたことは確認できました。(笑)
私の環境では比較的短時間（１０分ぐらいｗ）で出力できるので通常の4stepで実行してみます。目視比較では以前に出力したプロンプトだったので、同一のものが出力されていました。結果としてロジックはまともに動いていそうです。
「ロジックは」と付けたのは何となく出力時間がCPUと大差ないような？と感じたので。
とりあえず見てみると、現状のカーネル部分のロジックで無駄な処理があるので手を加えていたら別の形になってしまいました…ｗが、vaeの実行時間は167秒ほど。以前は90秒という数字を見かけていた気が…記憶が怪しいのでCPUでも実行してみました。
CPUは96.02sでしたw 現状だとCPUより遅くなってるという現実が突き付けられました(笑)（その後、ifdefで切り替えていた部分が切り替わってなかったので、再度実行したところ 96.11sという数字が…時間差だけでは誤差ぐらいにはなっているかな？でもgpuの方が遅いというのは意味ない感じ…）
まぁ片や4コア、一方 gpuでは2コア（1セット）…クロック数に至ってはgpuは1GHzといろいろと比較が悩ましいですが、コスパはgpuの方が有利なのは間違いないのですが。
動作が怪しい部分もあるので現状がすべてではないとはいえ、先行き不安ですｗ
さらにvaeでgpuを使用すると現状ではcpuでの実行よりも明らかにメモリーを消費するので現状の環境(swapなし)だと実行すらできない感じなのも先行きが不透明な感じに…
まぁいろいろ楽しいですけどｗ
0 件のコメント:
コメントを投稿