なに…これ…（驚

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

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

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

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

「見たら買え」（秋葉原の鉄則）

確かにそれはありますね。自分も何度か悔しい思いを…。

[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の特殊形として扱う）で、高速化が見込めるかどうかを見てみるか。脈が無ければ作っと捨てれば良い。

for (i=0;i

for (i=0;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の処理しやすい形に編集してから渡せばいいのかなあ（なのでカーネル毎のワークロードが偏る可能性あり）。

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

data[x] += foobar、真面目に書くとdata[x] = data[x] + foobarになる訳だし、こーゆう処理を複数のカーネルに分けちゃうと「別のカーネルが読み取るグローバルメモリーへの書き込みを避けます」に違反しちゃう。 https://hpc-event.jp/hpsc2023/material/hpsc2023_day3_workshop_part2.pdf

ていうか、OpenCLのカーネルプログラミングって複数のカーネルから同じメモリアドレスに関して同時に読み書きが発生した場合って何が起こるんだろう。ちゃんとロックがかかるとは考えにくいんだけど…

書いてみたところで動くかどうかも知らないし、パフォーマンスが出るかどうかも知らない。今はそれ以前の問題だし。

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なし