Vulkanの仕様と格闘し様々な合法行為の証明をし続けながら、モバイルGPUベンダーの出してる様々な情報を漁りまくってたら、ようやくGPUや描画のことがもう少し包括的に分かってきた気がする

実装しようと思っててちょっと調べて話を知ったがClustered Forwardの、タイルへのアクセスパターンの直列化によるVGPRプレッシャーの低減はなるほどだった

Vulkanマジで凄いが、特に仕様書のレベルが凄い
例えば、Execution Dependencyだけでreadからwrite、つまり前フレームで読みこみ専用で読んだ領域をもう一度書き込み領域に認識し直すというのは理論上いいはずだが、access scopeだけ無にするのも気持ち悪い気がして、実際大丈夫かな？言及ないかな？と思うと、やはり7.1のnoteにちゃんと書いてあったりする。

クリスマスなので満を持してVulkan始めました　Androidクロスプラットフォームの準備も整ったし

心がエンジニアじゃないのでCMakeを人生でようやく初めて触ったが便利かもしれない
Vulkanを加えることによるマルチプラットフォームの実装を始めていたが、Android Studioのプロジェクトは既存のMSVCプロジェクトを盗み見れる感じに簡単に出来た

回転運動を入れるか

人生だ

この状況ではむしろ自分が完全に外敵だと俯瞰できるが、最悪だ

simdに食わせるメモリは生の数値に基づいた配列である必要があって、atomicの配列にすることはできない（例えば、atomicはサイズについて、sizeof(T)と一致することは努力目標でしかない）
データ指向開発的ゲーム開発では、基本的にはN個の対象にループアンロール的処理を行うような活用なのだから、mm_store系で行うような処理は、一回のJobで基本的に全ての場所について一度しかかきこまれず、Jobとしての終了後に何かで可視化するのでこれは別にOKなのだが

loadについて、x86のMOVはrelax,acquire　armのLDRはrelaxを持つみたいだが
relaxさえない謎loadって何らかのISAとしてはあり得るの？
マルチスレッド環境だと絶対失敗する謎ロードみたいな…
C++のatomicを利用しない変数にmutexなしでアクセスした場合に出張ってくる可能性があるような形で存在できる可能性だけはあるんじゃないかと思った

SIMD基盤を試す形で物理エンジンの実装をしているが楽しい