そこはお金出さないといけない領域だと思う。ていうか、どの領域もお金も出さず、むしろ人も減らしたい（その割には能力高い人が欲しい）なんて言ってるようじゃ…

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

あれ、今度はclinfo通ってる。

int test(void)
{
asm __volatile__(".word 0x144f0000");
asm __volatile__("b 0x13c0000");
asm __volatile__(".word 0xd503201f");
asm __volatile__("nop");
asm __volatile__(".word 0xd65f03c0");
asm __volatile__("ret");
}

消す前にメモとして投げちゃう

一応販売店には（電源の動作報告と対応のお礼も併せて）何かあったら教えてくださいって問い合わせ出して、ASRockにもどうしたもんかねって問い合わせ出してみたけどさ。てーかCPUはマイクロコードの変更で対応したみたいだけど、GPUはどうすんのかなあ。なんとなく、脆弱性あるけどこのまま頑張ってね（はぁと）と放置な悪寒が。

https://jvn.jp/vu/JVNVU99796803/ これさ、「開発者にお問い合わせください」ってなってるけどIntelの文書 https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00812.html では「Contact Intel product support in your region」なんだよね。とはいえ自分の持ってるのってIntel謹製のLimited EditionじゃなくASRockのなんだけど…それでもIntelへ問い合わせて良いんだろうか？

歳食ったせいというのもあるかもしれないけど、PS1～PS2時代のいかにもポリゴンっぽさ丸出しな感じのゲームで良いじゃねーかと思うことが増えてる気がする。

なに…これ…（驚

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

sparse/非sparseはやっぱ分ける。めんどいので。

てーか本当にこの２年間は入手するモノに何かしらの不具合があるケースが多い気がする。無駄な時間を使いたくないなら本当に「定番品」を適切なお金、それこそ保険とかサポートとかの代金込みで払うくらいのことをしないとやってらんない気がする。

脆弱性報告の対象品を手にしている、という実績も解除できましたし♪（泣きながら

Arc A770でオクトラⅡ（画質設定最高/FullHD）動かしてるとハングアップすることが二度あったんですが…WSL2(Ubuntu)のclinfoが「Abort was called at 62 line in file: ./shared/source/os_interface/os_interface.h」とエラー吐いて動かないんですが…それでもまあ思い切って買ってしまったことは後悔してないです多分。

「見たら買え」（秋葉原の鉄則）
確かにそれはありますね。自分も何度か悔しい思いを…。

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

[Spoilers] [LONG] I tried translating the Latin lyrics again, and this is what I got. https://www.reddit.com/r/octopathtraveler/comments/jr5v59/spoilers_long_i_tried_translating_the_latin/ 歌詞を聞き取るためにPCMエディタとFFTフィルタを使うって…イマドキはそれくらい普通にやるんですかね（驚

rowsとcolsの値が要るけどsparse系はcolsについては不定になってるので最大値を調べないといけないという厄介な問題がある気がする…って、テーブル構築しながら調べれば良いから問題はな…あるね。最大値分からんし。

とりあえず最初のうちはsparse_うんたら系の実装（非sparseに関してはsparseの特殊形として扱う）で、高速化が見込めるかどうかを見てみるか。脈が無ければさくっと捨てれば良い。

ん－、(rows / step) * (cols + 1)が最大かなあ。

for (i=0;i<rows;i++) out[i] *= SCALE;
for (i=0;i<cols;i++) x[i] = (int)floor(.5+127*_x[i]);
idxのサイズも事前計算（というか一旦テーブルを舐める必要あり）
idx参照用のリストも作成するからサイズは分かる
問題はwのサイズだよなあ。32（もしくは16）×rows×colsかなあ。

https://www.intel.com/content/www/us/en/developer/articles/technical/introduction-to-gen-assembly.html

（CPUがブン回っているので）暑い

OpenCLいじる前に、DOT_PROD非対応なvec_sse.hのメンテしろって感じっすね

sparse_うんたら系もアレかなあ、CPUがGPUの処理しやすい形に編集してから渡せばいいのかなあ（なのでカーネル毎のワークロードが偏る可能性あり）。

※今までそれが実現されていないということは、単に手を付けていないだけなのか、手を付けても現実的ではない（不可能である）ことが示されているかの、どちらか。

Tutorial: OpenCL SGEMM tuning for Kepler https://cnugteren.github.io/tutorial/pages/page2.html
この例にもあるように、C[n * M + m] = acc；すべて独立した要素に対する独立した処理を並列化しているので、C[n * M + m] += accみたいな依存性のある処理については考えないといけない。

data[x] += foobar、真面目に書くとdata[x] = data[x] + foobarになる訳だし、こーゆう処理を複数のカーネルに分けちゃうと「別のカーネルが読み取るグローバルメモリーへの書き込みを避けます」に違反しちゃう。 https://hpc-event.jp/hpsc2023/material/hpsc2023_day3_workshop_part2.pdf
ていうか、OpenCLのカーネルプログラミングって複数のカーネルから同じメモリアドレスに関して同時に読み書きが発生した場合って何が起こるんだろう。ちゃんとロックがかかるとは考えにくいんだけど…

JVNVU#99796803 Intel製品に複数の脆弱性（2023年8月）
「2022年10月から2022年12月までに販売された次の製品に関するサポートについては、開発者にお問い合わせください。
INTEL-SA-00812: Intel Arc graphics cards A770およびA750」
https://jvn.jp/vu/JVNVU99796803/

どうやら「当たり」を引いちゃったみたい。