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:~$

このアカウントは、notestockで公開設定になっていません。

既にあるコードが何らかのアクセラレータの仕様を前提としていない以上、一旦GPU側のメモリにコピー→処理→CPU側のメモリへコピーという手順は不可避な気がする。んでもって、そのオーバーヘッドも多分あまり無視できないレベルかも。

うーん、あまり細かいデータばかりだとGPUとの受け渡しにかかわるオーバーヘッドが大きくなるから速度向上は狙えないような気がする。GPUがメインメモリ上のデータを直接触れるんなら話は変わるんだろうけど（できるの？）。

vec_tanh
N 16
N 384
N 512
N 128

vec_sigmoid
N 32
N 768

sparse_sgemv_accum16
rows 1152

softmax
N 256

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を載せられなくなってしまう。

これを延々と動くようにするとSEGV吐いて落ちる問題、問題を起こすWSLg上の環境だけでなく、Linux(Intel HD630, AMD Turks)でためしてみることにした。

すごく…Incognitoです…と思ったらやっぱりIncognitoだった。

Xでの電子QSLの議論を見てなんか*検閲により削除*な気分になったので、こういうNIP IDEAをdiscussionに投げてきました。Nostrでログとか電子QSL作るのって悪くないと思うんだけどどうなんすかねえ…？ https://github.com/nostr-protocol/nips/discussions/709

…な、なんぞ？

第39回医療情報学連合⼤会 FHIRシンポジウム HL7® FHIR® とは何か？ （page-infoだとModified: 2021/Feb/1になってる） https://fhir-research.med.gunma-u.ac.jp/img/file11.PDF

単に負荷かけるだけならOCCTみたいなツール使えば良いか…

まあこの問題は電源と関係ないんですけどね…

libigdrcl内で落ちてる…？

#4 0x00007f413a08fbae in ?? ()
from /usr/lib/x86_64-linux-gnu/intel-opencl/libigdrcl.so
#5 0x00007f4139e87095 in ?? ()
from /usr/lib/x86_64-linux-gnu/intel-opencl/libigdrcl.so
#6 0x0000565246bc1904 in main ()
(gdb)

(gdb) backtrace
#0 0x00007f413a2ee691 in ?? ()
from /usr/lib/x86_64-linux-gnu/intel-opencl/libigdrcl.so
#1 0x00007f413a2eea9c in ?? ()
from /usr/lib/x86_64-linux-gnu/intel-opencl/libigdrcl.so
#2 0x00007f4139ed4863 in ?? ()
from /usr/lib/x86_64-linux-gnu/intel-opencl/libigdrcl.so
#3 0x00007f413a0609fc in ?? ()
from /usr/lib/x86_64-linux-gnu/intel-opencl/libigdrcl.so

Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f413a2ee691 in ?? ()
--Type <RET> for more, q to quit, c to continue without paging--
from /usr/lib/x86_64-linux-gnu/intel-opencl/libigdrcl.so
[Current thread is 1 (Thread 0x7f4142e17740 (LWP 896))]

問題は無いと思っているけど念のため今夜もマシン動かしっぱなしにして電源が問題ないか様子を見ることに（電源をonにできない、という問題だったのでちゃんと起動すればﾖｼ!というチェックだけで良いんだけど）

日の丸〇〇と報じられることでプロジェクトが潰される、というのもよく知られた事象ですよね

このアカウントは、notestockで公開設定になっていません。

wslgの場合
uaa@DESKTOP-251U0UF:~$ cat /proc/sys/kernel/core_pattern
/mnt/wslg/dumps/core.%e
uaa@DESKTOP-251U0UF:~$
ってことでカレントディレクトリに出てこないのか。

これ、なんか一晩回してたらsegment faultで落ちた。
Ubuntuの特徴なのかulimit -c 0設定効いてるらしく、core残ってないので原因の探りようがない…もう一回動かすか…

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

玄人志向 KRPW-BK750W/85+から（差額を払って）DEEPCOOL PQ750Mに替えてもらったんですが、何事もなく動いちゃいますね…

（githubに投げて比較とかたまにやってます…すみませんすみません）

diff -wだっけ？適当に空白無視してくれるやつ。

hoge = fuga;
foo = bar;
みたいに=の位置を揃えるとかやってた時期は確かに昔あったけど（ってプロポーショナルフォントだとちゃんと表示されないか）、今は揃えてないかなあ。そろえることが面倒というのもあるけど、後々のメンテが面倒臭いので。

誰かのコードに手を入れる、って時はまあその流儀になるたけ合わせはしますけどね…

このアカウントは、notestockで公開設定になっていません。

個人的には、Windowsのイベントログにいちいち残してほしくない、かなあ。他の重要なエラーとか警告を見逃してしまうのが非常に困る。

このアカウントは、notestockで公開設定になっていません。

あー、Arc A770動かしたい！（手元にASRockの8GB物があるけど電源の問題が未解決なので挿せない）

WHEA-Logger event 17が起きてたのは蟹なNIC(RTL8111)を挿してた時なので（RX6400が手元にあった時はどうだったんだろう、そこまで調べてなかった）物によるんだと思います、多分。

そもそもリカバリして問題が無いことになったエラーをいちいち「なんかエラーが起きてたけどリカバリしたからね！」って記録する意義がどこまであるのか、って話だと思う。確かに頻度が低いならマシンの劣化の指標とかにもなるんだろうけど…errataでバリバリ起こるよ！ってんなら「もうええわ表示せんといて」ってなると思うんだよなあ。

もしかして手元の13thGen機で起こってるWHEA-Logger event 17ってこの辺絡みなんじゃ

13th Gen（12th Genも該当するはず）のPCIe周りのerrataって強烈ですなあ
RPL012 PCIe Link May Fail to Train Upon Exit From L1.2 https://edc.intel.com/content/www/us/en/design/products/platforms/details/raptor-lake-s/13th-generation-core-processor-specification-update/errata-details/#RPL012
RPL013 Incorrectly Formed PCIe Packets May Generate Correctable Errors https://edc.intel.com/content/www/us/en/design/products/platforms/details/raptor-lake-s/13th-generation-core-processor-specification-update/errata-details/#RPL013

古のSuper I/O(FDC37B78x)の仕様書 https://www.mouser.com/datasheet/2/268/37b78x-461440.pdf p.149を見るに、電源ボタンからの入力(Button input)をSuper I/Oがラッチして電源のnPowerOnへ伝えるような作りになっているから…Super I/Oが動作するための+5VSBがちゃんとしてること、という条件は必須になるよなあ（なんかもっと高度なマイコンでも使ってるかと思ってた…って、イマドキならその可能性もあるか）。

確かに自分はMostr使ってるんでこんな感じにAP側のを流し込めちゃうんですよねー（ってMostrを処理対象のリレーに含めていないと多分読めないと思います、Nostr側からは）。

結構長いんですねT0って。https://edc.intel.com/content/www/us/en/design/ipla/software-development-platforms/client/platforms/alder-lake-desktop/atx-version-3-0-multi-rail-desktop-platform-power-supply-design-guide/2.01/timing-housekeeping-and-control-required/#_Ref484872659

+5VSBが立ち上がるまで最大2秒ってことは…この期間の出力がおかしくてマザーボード上の電源管理コントローラが誤動作してるとかそんな感じのシナリオを考えてしまうな。 https://edc.intel.com/content/www/us/en/design/ipla/software-development-platforms/client/platforms/alder-lake-desktop/atx-version-3-0-multi-rail-desktop-platform-power-supply-design-guide/2.01/-5vsb-required/

@redbrick ありがとうございます。とりあえず、何とかしてもらえるよう交渉してきます。

ATX電源チェッカは確かに電圧は見えるけど、おそらくTiming, Housekeeping and Control – REQUIRED https://edc.intel.com/content/www/us/en/design/ipla/software-development-platforms/client/platforms/alder-lake-desktop/atx-version-3-0-multi-rail-desktop-platform-power-supply-design-guide/2.01/timing-housekeeping-and-control-required/ みたいなタイミングの問題は見えないはず。あとは、+5VSBの安定性も多分見えないから…それ絡みなんだろうな。流石に手持ちの機材では追えないが。

B250 MINING EXPERTに例の電源繋いでみましたが…事態としては「詰みではないがクソ厄介な状況」になっています。

電源が入るときはちゃんと入るものの、入らないときは入らないという不安定な状態、という結果になりまして。

とりあえず今日調べていただいたお店の人に相談してみますが…「相性」の一言で片付けられちゃう可能性は割とありそうな気がします。

B250マザーではちゃんと動く、の方がまだ楽な案件かも。（でもこれ600W電源積んでる…実は400W電源と交換してA380入れるのが最善解だったんじゃ？！）

Cでgoto使うな小学校校歌を歌う人から見るとそんな雑な修正すんなと怒られそうなんだけど…細かく面倒見てる余裕なんて無くとにかくお手軽に結果を得ないといけない局面なのでということで、お赦しを。

GPUが複数あった場合に面倒くさいことになりそうな気がするけど。

とりあえずなんとなくOpenCLでGPUをぶん回し続けるよう改造してみた

問題は、これで動いちゃった場合は完全に詰みなんですよね。「動くじゃん」→「不良品じゃないよね」なので。

件の電源、とりあえずつないだマザーを壊す殺人(?)電源ではない以上…手元の別マシンに繋いで試すのはアリなんだろうということに今更気づいたので、後で試してみましょう。

とりあえずWHEA Logger17の件は一旦これで置いとけるようになったので、電源の問題だな早急に解決しないといけないのは…初期不良対応機関を越えたのでサポートができないとか面倒なことになる前にもろもろ片付けないと。

WHEA Logger 17って結局「エラーは起きたけど回復しといたからね」という内容なので、多分動作上の実害はほとんど無いんだろうけど…とはいえイベントログに大量のごみをぶち込まれてしまうとそれはそれで困るというのはあるし、PCIeデバイスを生やすときに大丈夫なのかと要らぬドキドキを感じないといけないのもまた疲れる…

マジでPC自作は今後やめようかしらとか考えたくなった。

まさかとは思うけど、12th/13th以降のIntel機ってIntel以外のPCIeデバイスを繋いでくれるなっていうんじゃないよねえ…？

Inspiron 15 5000 Series (5567) 　Windows10(64bit) 　イベントログに大量の警告 イベント17 WHEA-Loggerがあります。 (01-10-2017) https://www.dell.com/community/%E4%B8%80%E8%88%AC-%E3%83%8E%E3%83%BC%E3%83%88%E3%83%91%E3%82%BD%E3%82%B3%E3%83%B3/Inspiron-15-5000-Series-5567-Windows10-64bit-%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88%E3%83%AD%E3%82%B0%E3%81%AB%E5%A4%A7%E9%87%8F%E3%81%AE%E8%AD%A6%E5%91%8A-%E3%82%A4%E3%83%99%E3%83%B3%E3%83%8817/td-p/5291818

WHEA Logger17って結構よく起こってるってことなのかなあ？

realtek whea logger 17で雑にググると https://www.google.com/search?q=realtek+whea+logger+17

Realtek PCIe GbE Family Controller Event ID 17 from WHEA Logger (10-08-2021) https://community.intel.com/t5/Ethernet-Products/Realtek-PCIe-GbE-Family-Controller-Event-ID-17-from-WHEA-Logger/td-p/1320500
New 12900K build, getting thousands of WHEA-Logger (Event ID: 17) errors a minute (03-08-2023) https://community.intel.com/t5/Processors/New-12900K-build-getting-thousands-of-WHEA-Logger-Event-ID-17/m-p/1463235

UEFI 2603→2403でWindows起動時のWHEA-Logger17は消えた、とはいえNICは外さないとやっぱり出る。とりあえずこのバージョンを使って、NICは外してオンボードのを使って運用。

電源は結局こっちでは動かず（また後で相談が必要そう）
WHEA-Logger17はNIC抜いても起動時に出ているので、UEFIのバージョンを下げて様子を見てみます（今2603なので、候補はあと3つくらいある）

NIC：これから抜いてみる
電圧：CPU +1.163V, 12V:+12.192V, 5V:+5.160V, 3.3V:+3.376V, DRAM:+1.200V
電圧は多分大丈夫。ていうか同じNICさしてても以前は問題なかった（ってASPM切ってたからか？）という記憶があるから…Arc載せるのでASPMは必須科目になるし…

NIC抜いて、頭冷やして考える、そこからいこう。

UEFIをロールバックする（できるのか？）というのも一案…？

@redbrick 蟹のNICが繋がってるPCI Expressポートっぽい…

…あれ？何故WHEA-Logger event 17が出てる？

UEFI SetupのAdvanced→APM Configuration→Restore AC Power LossはPower Offになってる。まあこれはそういうもんとして…
Tool→Event LogでAC Power Loss!が幾度かと4S Forced Shutdown!が残ってるのが気になるな。
全然無関係の可能性も当然あるとして。

UEFI setupで電源周りの設定とか何かあったかなあ（ちょっと見てくる）

@hadsn 電源チェッカーではPG信号は300msになっていたからおかしくないと判断してるんですけどねえ…

@hadsn 分からないのが、ATX→Baby-AT電源コネクタ（スイッチ付き）だけ繋げている状態だと電源のファンが回り続けている点。無負荷で回ってるってことは、多分電源自体の自動シャットダウンの問題ではないんだと思う。

@hadsn その可能性を今疑っているんですが…HDDとSSDとマザーを繋げた状態で、電源入らないんですよね…

ATX電源チェッカー、使う機会はそんなにないだろうけどあると便利そうだなーというのがお店で見た時の率直な感想。

これ、PS_ON#とGNDを繋ぐというのは合ってるんだけど、つんつんするというテスト方法は間違い。

繋いでる間ずっと電源が供給されるから、つんつんする程度ではファンがぴくっと動く程度の動作になるのは当然。

DOSPARAのお店での動作チェックでは問題なかったことと（感謝）、手元にあったATX→Baby-AT変換ケーブル＋電源スイッチでのチェックでも動いてたので、もしかすると接触不良とか他の原因を疑う必要があるのかも。

あーもうっ、どうなってるの一体…後でもう一回繋げ直して動作確認するしかないじゃないか…

自由研究とは言うけどさ、如何に先生ウケして高評価を取るかという、親サイドによる競争だったりもするよね…

このアカウントは、notestockで公開設定になっていません。

「アローゼン」（下剤）が、ストⅡの波動拳のイントネーションで聞こえてしまう呪いを受けてしまってのぅ…ちょっと困るときがあるんじゃ…

この手を使うか…以前試したOpenCLベンチマーク(http://lucuda.web.fc2.com/bwocl/index.html)、これを延々と動くように改造しちゃえばとりあえず負荷かかるかなーって

Orange Pi Zero3向けのAnrdoidソースを落とす（二回目）
圧縮していても36GB近いんだけど、これ展開するのはちょっと勇気要るな…

sys_config.fexに手を入れて、それっぽいU-bootを仕立てて動かすしか手はなさそうだな…って、修正済のはどこかにあったりする？

ATX電源が動かない件、何も結線しない状態で電源のPS_ON#とGNDをその辺にあったリード線でつんつくすると電源ファンが一瞬だけぴくっと動くので（普通なら回りっぱなしになるよね？）、やっぱり動かないという扱いで良い気がしてきた。

…というか、他のマザーで試そうかなと考える前に、なぜこの手法を思い出せなかったんだよ自分、というのがこのtootの主旨。