記事を読む前に押さえておきたい事
Vulkanのメモリ管理は乱暴に言うなら配列の管理をするようなものとなる。つまりCで言うなら
int myarray[arraynum];
配列の宣言と構造が似ている
設定項目が多いので戸惑うだろうが、それぞれのバッファー生成のしていることは
この宣言とそれほど変わらないということは気に留めてほしい
先に結論から
Vulkanは学習コストが低く済むGPGPU用途,つまりコンピュートシェーダーバインディングから学ぼう
三角ポリゴンの描画を最初の目標にすることを避ける
Vulkanなど、現代の3DAPIは3DCG用途からGPGPU汎用化が進んでいる
コンピュートシェーダーから学ぶと他GPGPU用途のAPI(OpenCL,CUDA,HIP)同士でシナジーがある
なぜVulkanをコンピュートシェーダーバインディングから導入するのか
コンピュートシェーダーから学ぶことはVulkanにおいて比較的低コストな導入かつ、今後の3DCG、およびGPUプログラミングにおいてより現実的な選択肢だからである
三角ポリゴンを描画コードを最初の目標にするデメリット
確かに三角ポリゴンの描画経験を積むことのメリットは大きく、3DCGエンジンを描くうえでは必要な基礎知識や経験ではあるが・・・
Vulkanで三角ポリゴンを描くためのコードは最悪の場合1000行近くに達する上、一つでも間違えるとクラッシュする設定が数多くある
→その上エラーコードの指す内容を理解するのが難しい
そもそも、ウィンドウを表示してCGを描画する画面を表示するだけで数百行、これも数々の繊細な設定をクリアしなければいけない。
さらに、この三角ポリゴンによる描画パイプラインはすでに旧式に近いものがあり、現代で要求されるモデルとやや乖離したものになっている。最低限レンダリングパイプラインの構造や必要なデータが何なのかを理解できれば、そのプログラムを書けたり、動かせるということはあまり問題ではなく、教養として理解できていれば、それでも良い
キーワードを確認しておくだけでも違う
Vulkanを含む低レイヤー3DAPIの位置づけの変化
Vulkanはもはや3DCGのプログラミングにとどまらない、後述するGPGPUによる汎用計算の並行処理のエンジン部分を担うプラットフォームに変わりつつあり、
現代の3DCGプログラミングにおいてもコンピュートシェーダー/非同期プログラミングワークフローの理解を前提とした設計が当たり前となっている。
(GPU駆動レンダリングが最たる例)
レイトレーシング処理もリソース管理やワークフローはこのシェーダーのそれがベースとなる。
(競合するDirectX12においても、2026年にGPU駆動の傾向はさらに強まっている)
学習用途としても…
そもそも、3DCGを学ぶためであればソフトウェアラスタライザーやレイトレーサーを学んで基礎レベルからその原理を知ることが、結局は全体のロードマップを歩むうえで早道であり、
先述の三角ポリゴン云々でさえ、実はその理解を前提にしたものとなる上、ここから入ると本質が見えにくくなり、肥大化したVulkanにおける各種設定に気を病む事に時間を使うべきではない!
Vulkanをコンピュートシェーダーから学ぶと他APIとのシナジーが強まる
CUDAやOpenCLといった同じくGPU上での汎用計算を目的としたAPIとの学習シナジーが強化されやすい
→それらで書かれたレイトレーサーやラスタライザーのソースコードを読む素地ができるほか、学びのアプローチの骨格を複数持つことができる
結論の再掲(まとめ)
Vulkanは学習コストが低く済むGPGPU用途,つまりコンピュートシェーダーバインディングから学ぼう
三角ポリゴンの描画を最初の目標にすることを避ける
Vulkanなど、現代の3DAPIは3DCG用途からGPGPU汎用化が進んでいる
コンピュートシェーダーから学ぶと他GPGPU用途のAPI(OpenCL,CUDA,HIP)ともシナジーがある
次回の記事予告
次回はGPUリソース(ディスクリプタ)に関する