あんだよ…PR出てるじゃん https://github.com/dcti/dnetc-client-base/pull/22

rc5-72/opencl/ocl_common.cpp b/rc5-72/opencl/ocl_common.cppにある、
/status = clBuildProgram(cont->program, 1, &cont->deviceID, "-cl-std=CL1.1", NULL, NULL);
この"-cl-std=CL1.1"を外すと動く。

ふーむ、ビルドはできるけどバイナリはerror -11で落ちるから…ここから追うことはできるのか。やるかどうかはともかく。

oclcで https://github.com/dcti/dnetc-client-base にある*.clをチェックした限りでは問題無いのに、dnetcのバイナリはerror -11になるのが解せないな。そもそもどういう形式で.clを格納してんの？って話になるのだろうけど。

結局linux-sunxiベース？boot0 blob使ったU-bootでやれってことですか… https://github.com/orangepi-xunlong/orangepi-build/commit/5b98978bd16bb3624e78a307d2067d461bfca417#diff-e0f333c6e19eccb7bda6f1f038d71ef8ae689d90752eef11b4f5da6e23af1c76

ネズミ入り込むと面倒だよね…（実家がそうだった）

怪談なのか、それとも（足音の規定が無いので）小動物の足音なのか…

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

やっとASRockから返事来た「Intelに問い合わせ出してて、今チェックしてもらってる」って。

そういえばこういうmemset()は最適化で消えるんだっけ…？と思ったんだけど、関数の引数で取ってるsigに対するmemset()なのでこれは残さないとマズい。

https://github.com/bitcoin-core/secp256k1/blob/master/src/secp256k1.c#L374

関数内部で（ワークエリアとして）確保した領域に対するmemset()なら多分最適化で消されちゃうとなると…自分の書いたコードは果たして大丈夫なんだろうか…？あとで見とかないと。

とりあえずOpenCLでCPU→GPUないしGPU←CPU、GPU→GPUのデータ転送にかかる時間、雑な行列計算を行った際にかかる時間（CPUとGPUの比較）の測定をやってみたいなあ。どれくらいの規模のお仕事をさせると元が取れるのかが気になって気になって。

※何の生産性もないんだけど、興味には勝てぬ

と考えると、
{
char *buffer;
buffer = malloc(1024);
hogefuga(buffer);
free(buffer);
}
のhogefuga()が最適化によって消えないのは「たまたま消えてないだけ」という判断をした方が良いんだろうかね。まあ実際、関数の外には何も結果が出ていかないのだし。

コンパイラの解析機能が向上した日には、多分{malloc(); hogefuga(); free();}だけな処理も最適化で消される可能性はあるのかもしれないねえ…

現状だと、hogefuga()の後にあるfree()でbufferに対して何かするかもしれないからhogefuga()は消せない…仮にhogefuga(), free()を消したとしたらmalloc()も消さないといけなくなるけどそこまではまだ文脈を追えてないってところかねえ（malloc()～hogefuga()間にbufferに対する処理があった場合はどーすんのって問題もある）。

で、結局何をしようとしていたか思いっきり忘れてるので思い出そうとしてる。多分思い出せるけど面倒なのでやりたくない。

{
char buffer[1024];
hogefuga(buffer);
}
これだと最適化でhogefuga()の呼び出しが消えちゃって、
{
char *buffer;
buffer = malloc(1024);
hogefuga(buffer);
free(buffer);
}
これだとちゃんとhogefuga()が呼ばれる…多分malloc()とfree()の存在が抑止力になってるんだろう、なんとなく。

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

駄目ですね…画質プリセット最高/高はハングアップすることあり、中でないと怖くて遊べません。

@reasonset 演算結果を格納した変数なりなんなりをprintf()なりすれば生き残るんですけどねえ…もうちょい考えてみます

計算するだけするけどその結果は使わない（時間測りたいので）、というコード…最適化かけちゃうと消えるという問題があって、どうやって残したものか頭を抱えてる。結果を無理やりにでも使うとかそういうことでもしないと残らないんだろうか。

なんかAllwinnerの時代は黄昏かなあ…Rockchipだよね、流れ的に

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

今日更新したArc770のドライバで、果たしてオクトラⅡが安定して動くかというのは気になるところ。画質最高だと、何かの拍子にハングアップするんだよなあ…画質中（UHD730と同じ）だと大丈夫っぽいんだけど。

ちなみに画質最高だとオープニングはちょっとカクつくところがある。ウィンドウモード（1600×忘れた）という理由もあるのかも。

やっぱ770LE/16GBが投げ売りされていたあの時期に手にしておくのが正解だったんだろうなあ…ああいうチャンスを確実にモノに出来るかどうか、自分はできなかった身なのでその程度ってことなんだけど。

今回のドライバ更新でもその脆弱性に関してはどうなんのかという話は出てないし…

Intel謹製の750LE/770LEについてはIntelがきちっとサポートしてくれるだろうから心配不要なんだろうけど…ASRockのボード買った身としては例の脆弱性に当たるのか、（当たってなければそれで良しなんだけど当たってるかどうかの判定方法は示してほしい）当たった場合はどうすんのかをアナウンスしてくれないと困るんだよねえ。

…ほほーぅ？

[2023/8/17--6:35:37:748] : Device: Fw Data Version: major_version-> 101-> oem_manuf_data_version-> 3-> major_vcn-> 1
[2023/8/17--6:35:37:749] : [fwdata_update]:FWData update Image written to SPI
[2023/8/17--6:35:37:749] : [GfxFwUpdateThread]: FWData Update Status:(1)
[2023/8/17--6:35:37:751] : [GfxFwUpdateThread]: FwData Reg Key Update completed successfully

なんて記述があるから…多分、ドライバと一緒に更新用のファームウェアも配られていて自動的に更新されてるんじゃないかなーと見てる。

ASRock Intel Arc A770 Phantom Gaming D 8GB OC、ファームウェアのアップデートが出てるけど…リリース日は2023/Jan/16。https://pg.asrock.com/Graphics-Card/Intel/Intel%20Arc%20A770%20Phantom%20Gaming%20D%208GB%20OC/index.jp.asp#FAQ

とはいえ、C:\Intel\FWUpdateService\IntelGFXFwUpdateToolLog_2023-8-17_6-34-45.logを見るに、（続く）

Downfall, VPGATHER(DQ他)命令による脆弱性ってことは…10世代以前のAVX非対応なCeleron/Pentiumは影響しないってことで良いのかなあ

あとでよむ　https://qiita.com/rana_kualu/items/d1ce09874c5f9b03c555

freak31、「David Penn & Sex-O-Sonique - I Thought It Was You」が「David Penn & Sex O」（Oが曲名）になってる…名前の中に-が入るとちゃんとデコードできないのかな

Intel Arc A770のドライバの新しいのが来てるということで更新してみたけど、相変わらずdistributed.net[Windows:x86/OpenCL]はerror -11ですねえ…dnetc.exe内のOpenCLコードを抜いてビルドできるかどうか、元となるOpenCLソースをclBuildProgramに食わせるとどうなるか、辺りを調べてみる必要があるのかも。