対応できるフォーマットを取得し、Depth/Stencilバッファ、イメージ、ビューを作成します。必要なメモリを割り当ててこれらを紐付けます。次の描画バッファのIDを取得します。自分が描画したい物です。ここで挙げたのは単純なケースで、1つのターゲットバッファしか使わないパターンです。:単純なテスト・単純な物で描画したい場合。基本的にVulkanは通常のアプリケーション本体に書く物ではありません。描画フレームワーク内から呼び出す物です。CPUが描画以外の処理に忙しい場合。Vulkanの性質を活かすためには、描画用の前処理にCPU時間を割く必要があるためです。DirectXの仕様を読んで悩んでいる方。これはちょっと微妙な意見です。Threadの場合でもVulkanをうまく使うことで効果は出せます。性能を最も引き出せるのは複数のスレッドで描画した場合だと思います。:CPUバウンド描画。今までOpenGLやDirectXを使って複数のコアで作業していても、描画による処理でCPUが足りなかったパターン。callが必要なアプリケーション。安定した描画時間が必要な場合。ドライバの勝手な裏作業をなくすことで、描画にかかる時間を見積もりやすくなります。描画APIの勉強以外、ほとんどOpenGL系でも十分です。Extensionを利用すれば、Vulkanとほぼ同じ事を楽にできます。Vulkanは仕事上で専門に描画APIを叩く方に向いている仕組みです。CAD類の開発者以外はあまり調べなくても困らないのではないかと思います。難しいと思ったところ今回の記事を書くにあたって、Vulkanのすべての機能を使ったわけではありません。仕様を細かいところまで完全にマスターして、理解したわけではありません。使った分の個人的な感想です。ユースケースごとの説明が足りないこのフラグの組み合わせで本当にいいのか、という確証を得られない場合がありました。このため、あるフラグを設定しない場合はどうなるのかなどの疑問を持ちながら開発を進めました。メモリのタイプ・転送について、またViewの切り替えについて、不明確な部分が多かったです。Targetのreadとwriteの状態を切り替える概念を理解しても、実装・設定に関して、不安なところがありました。passについて、説明が物足りないAPIの説明はいいのですが、ユースケースやパターンに関する説明が不足しています。APIの説明を読んでも、見えていないところもあります。API仕様書ではなく、概念やユースケースを説明する本が存在しない新しいAPIであるため一定は仕方ないことですが、これによってDirectXやOpenGLでの経験がないプログラマがVulkanを理解するのが難しくなっていると思います。DirectXやOpenGLのAPIをたくさん叩いた経験があったとしても、内部で起きている事・GPUの設計を理解していなければ理解しにくい部分があります。暗黙的なノウハウがかなり多いと感じています。ヒントVulkanを利用した開発をおこなう際にヒントとなりそうなものをいくつか紹介します。StyleのAPIを利用しても特に問題ありませんし、定義・仕様書が大変よく出来ているのですが、原則的にC++ラッパーを利用した方が良いです。https://developer.nvidia.com/open-source-vulkan-c-apiC++ラッパーはオーバーヘッドがなく、しょうもないミスを防ぎやすく、メンテナンスしやすいVulkanコードを組めます。使わない理由はないと思います。型安全なEnum指定によって定数指定ミスを防げますし、IDEで自動的に関数やEnumを補完できるため、開発がかなり楽になります。今回は勉強のために、作業途中でC++版の自前ラッパーを作ったのですが、本記事の執筆時点でNVIDIAがC++ヘッダの自動生成ツールを提供しています。Vulkanコードを真剣に組むなら、使うべきだと思います。Groupによってメンテナンスされています。Layerを使ったバリデーションを活用しましょう。わかりやすいエラーを出せばいいのにと感じることもあります。それでも無言でcrashするより、大変素晴らしいです。エラーではないが推奨されない指定についてWarningを出してくれるケースもありました。これによって、コピペによるフラグの設定ミスなどを修正出来ました。Layersの使い方を説明したサンプルコードはこちらです。Playground当社で開発している2Dゲームエンジン"Playground"でVulkanを実験的にサポートするために行った対応を紹介します。エンジン固有の事情も含まれるため、前提を補足しつつ説明します。binding.Playgroundではもともと描画用の頂点データを実行時にCPU側で計算しているため、GPU側のバッファを一切使っていません。OpenGLのドライバーと同じ働きをし、命令コマンドを貯めながら、転送する頂点のデータも貯める構造です。描画命令を実行する前に先にメモリの転送を行います。stateless)エンジンの実行時にOpenGLのステート切り替えをしていたため、エンジンのRefactoringはおこなわずに同じ動作を再現しました。フラグとステートの差分を管理し、使うPipelineを切り替えるようにしました。supported.エンジンではシェーダーやターゲットバッファの切り替えをサポートしていますが、今回は最小限の作業で可能な範囲の対応をおこなったため、シェーダーの切り替えやターゲットの切り替え部分は未実装です。テクスチャーの切り替えVulkanでは二つの方法が存在すると認識しているのですが、試したのは片方だけです。Layoutをテクスチャー毎に作成(OpenGL系でいうと、Uniform値の塊を設定するオブジェクト)することで実現します。Layoutを作成せずに、すべてのテクスチャーを配列化して、indexでアクセスする方法です(試していないし、実装方法を調べていません)。今回対応したものはこんな感じです。SDKとネット上に存在するVulkan関連のサンプルコードを追いかけて学習するためのおすすめフローを簡単に紹介します。Groupのホームページから始めましょう。SDKへのリンク、仕様書、ドライバーなど、すべてそろっています。https://www.khronos.org/vulkan/個人的にNVIDIAのカードを持っているため、NVIDIAのドライバーをインストールし、LunarGのSDKもインストールしました。LunarGのSDKをインストールすると、Debug/Validationレイヤーが追加されるので役に立つと思います。今回の記事で扱ったのは感想や全体的な話がメインでした。サンプルコードをもとにして具体的にVulkanを試したい場合は、次の順でみていくと良いでしょう。Willemsのサンプルが一番機能が揃っていると同時にやる事が多く、フレームワーク化されています。Dumpレイヤーを使ってよいかもしれませんが)。Metal)はGPUの内部構造にフィットしやすい・計算モデルを近づけているため、今後のハードウェアの進化にあたって、APIも進化すると個人的に思います。今までハードルだった古いAPIの体系が消えたことで、今後のAPI拡張はハードの性能を十分に引き出しながら進められると思います。Rasterizationの拡張、などなど、すでに進化は始まっています。:Vulkanの調査とPlaygroundエンジンへの組み込み作業をおこなったのは2016年6月でした。2016が開催されました。このなかでVulkanに関する良い資料が公開されていたので紹介します。:Vulkanは低レベルAPIであると言われることが多いですが、個人的にはそうは思いません。たしかに気をつけるべき事、やる事はかなり増えますが、今までの描画APIの流れで考えると自然なものが多いです。Vulkanは完全に新しい概念というわけではなく、これまでの歴史の流れと追加されてきた概念の続きを担うAPIです。具体的には、可能な限り事前処理できるものを増やす、データの再利用生を高める、描画時の負担を減らす、メモリアクセスをより柔軟にコントロールできるようにする、というトレンドに沿うものです。これらを実現しやすくなるかわりに、GPUや描画パイプラインの細かいところまですべて理解する必要があります(覚える事は多いですが、昔からやっている描画エンジニアなら特に問題ありません)。現時点のVulkanが抱える問題は、まだ丁寧なドキュメントがないことです。ある事を実現したい時に複数の方法を考えつくことが多いのですが、何が「正しい」かという答えが出ない場合もあります(そもそも答えは存在しないかもしれません)。ユースケースごとのわかりやすい例がありません。何年間もゲーム機やPCでのグラフィック描画で苦労した経験者は悩む事が少ないでしょう。私は描画APIをバリバリ触ってゲーム機向けの開発をおこなったことがないため、正当な評価をするための能力や経験が乏しい部分もありますが、より暗黙的なノウハウに依存しないマニュアル作りとさまざまな全体図/例の提示がほしいと感じました。Sellers(AMD)のVulkan本に期待したいと思います。