Google Developers Japan: Vulkan

Vulkan デベロッパーツールを用いた開発環境のご紹介

2016年4月20日水曜日

[この記事は Shannon Woods、テクニカルプログラムマネージャーによる Android Developers Blog の記事 "Optimize, Develop, and Debug with Vulkan Developer Tools" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]Vulkan™サンプルガイド Vulkan API で可能になる最適化

メモリ割り当てのアプリケーションによる制御: Vulkan には、メモリを GPU に割り当てる方法やタイミングを非常に細かく制御するメカニズムが用意されています。このメカニズムによって、自分のアプリケーションに適した独自の割り当てポリシーや再利用ポリシーを使用できます。最終的には、実行回数やメモリのオーバーヘッドが減り、コストのかかるメモリ割り当てのタイミングをアプリケーションで制御できるようになります。

非同期的なコマンド生成: OpenGL ES では、アプリケーションがドローコールを呼び出すと、すぐに GPU に対してドローコールが発行されます。一方 Vulkan では、代わりにアプリケーションがドローコールをコマンドバッファに対して発行するので、ドローコールを生成して記録する作業と、ドローコールを GPU に対して発行する作業を分けられるようになっています。コマンド生成をいくつかのスレッドに分散させることで、アプリケーションは複数の CPU コアをより効率的に活用できます。また、こうしたコマンドバッファは再利用できるので、コマンドの生成と発行に伴うオーバーヘッドが削減されます。

分かりにくい作業の解消: OpenGL ES で困ることの 1 つが、コマンドによって作業を開始させるタイミングについて API 仕様に明示的に示されていない、またはデベロッパーに対して明らかにされていない場合がある点です。Vulkan では、作業を明示的に開始させるコマンドと、そうではないコマンドを仕様で明示しているので、動作を予測しやすくなり、一貫性が向上しています。

完全なマルチスレッド設計: OpenGL ES アプリケーションでは、レンダリングを予測可能な形で正確に行うために、必ず 1 つのコンテキストに対応するコマンドは 1 つのスレッドから発行することになっています。Vulkan では対照的に、そうした条件がないので、アプリケーションはコマンドバッファの生成といった作業をいくつも並行して行えます。しかしその一方で、データの修正や読み取りを複数のスレッドから同時に実行する場合、その安全性が暗黙的に保証されるわけではありません。スレッドの同期を管理する権限や責任は、アプリケーション側が持つことになります。

モバイルフレンドリーな機能: Vulkan の機能には、多くのモバイル端末で使われている、タイリング方式の GPU で高いパフォーマンスを実現するのに特に役立つものがあります。個々のレンダリングパス間の相互作用に関する情報をアプリケーションで用意できるので、タイリング方式の GPU は限られたメモリ帯域幅を効果的に使うことができ、オフチップでのデータ読み取りの実行を避けられます。

シェーダーのオフラインコンパイル: Vulkan では、シェーダー用の中間言語である SPIR-V をサポートしています。これにより、シェーダーを前もってコンパイルしておいて、SPIR-V バイナリをアプリケーションと一緒に出荷することが可能です。こうしたバイナリでは、GLSL のような高水準言語よりも解析が簡単です。そのため、ドライバがこの解析を行う場合のばらつきが小さくなります。また、SPIR-V をサポートすることで、特別なシェーディング言語やクロスプラットフォーム対応のシェーディング言語のためのコンパイラをサードパーティが提供することも可能になります。

任意のツールによる検証作業: OpenGL ES では、呼び出したコマンドをすべて検証し、設定が望ましい範囲内にあることや、オブジェクトが動作に適切な状態になっていることを確認しています。Vulkan は、それ自体ではこうした検証を行いません。代わりに任意のデバッグツールを使用することで、Vulkan のコマンド呼び出しが正確であり、最終製品で実行時オーバーヘッドが生じないことを確認するようになっています。