VulkanAPIの概要

それで、とにかくこの新しいVulkan APIの大きな問題は何ですか、そしてなぜ私たちは気にする必要がありますか？

Vulkan APIは、100語以内で次のようになります。これは、3Dグラフィックスおよびコンピューティングアプリケーション向けの、オーバーヘッドが少なく、金属に近いAPIです。 Vulkanは基本的にOpenGLの続編です。 もともとは「次世代OpenGLイニシアチブ」と呼ばれ、AMDのMantleAPIの一部が含まれています。 Vulkanは、他のGPU APIに比べて多くの利点を提供し、優れたクロスプラットフォームサポート、マルチスレッドプロセッサのサポートの向上、CPU負荷の低減、OSにとらわれないピンチを可能にするはずです。 また、ドライバーの開発が容易になり、さまざまな言語で記述されたシェーダーの使用など、ドライバーの事前コンパイルが可能になります。

これは93語なので、興味がない場合は、次の3,500語をスキップできます。 一方、今後数年間使用される予定のグラフィックAPIについて詳しく知りたい場合は、基本から始めます。

VulkanAPIがどのようにして生まれたのか

Vulkanは、2015年3月にKhronos Groupによって最初に発表され、暫定的な立ち上げ日は2015年後半に設定されています。Khronosに慣れていない場合は、15年前にいくつかの有名企業によって設立された非営利産業コンソーシアムです。 ATI（現在はAMDの一部）、Nvidia、Intel、Silicon Graphics、Discrete、SunMicrosystemsなどのグラフィックス業界。 Khronosについて聞いたことがない場合でも、OpenGL、OpenGL ES、WebGL、OpenCL、SPIR、SYCL、WebCL、OpenVX、EGL、OpenMAX、OpenVG、OpenSL ES、 StreamInput、COLLADA、およびglTF。

今では、おそらく「ああ、それはそれらの人たちだ」と考えているので、イントロの残りの部分をスキップして、API自体に焦点を当てることができます。

Vulkanは、その前身または前身とは異なり、モバイルやタブレットからゲーム機やハイエンドデスクトップに至るまで、さまざまなプラットフォームで実行できるようにゼロから設計されています。 APIの基盤となる設計は階層化されているため、つまりモジュラーと言えば、パフォーマンスに影響を与えることなく、コードの検証、デバッグ、およびプロファイリングのための共通でありながら拡張可能なアーキテクチャを作成できます。 Krhonosは、階層化されたアプローチにより、柔軟性が大幅に向上し、クロスベンダーGPUツールの強力なイノベーションが促進され、高度なゲームエンジンで要求されるより直接的なGPU制御が提供されると主張しています。

さて、多くのテクノフィリアが「フレキシブル」、「エクステンシブル」、「モジュラー」などのマーケティング用語について留保していることを理解していますが、今回は本物のマッコイを扱っています。 実際のところ、これがVulkanの背後にある基本的な考え方です。スマートフォンでゲームをする子供から、ワークステーションで建物やゲームを設計する両親まで、大衆向けのAPIとして想定されています。

理論的には、Vulkanは並列コンピューティングハードウェアで使用でき、数百億のGPUコア、小さなウェアラブルやおもちゃのドローン、3Dプリンター、車、VRキットなど、互換性のあるGPUを内蔵したほぼすべてのものを制御できます。

詳細については、PDF形式のVulkanの公式概要をご覧になることをお勧めします。

AMDマントルDNA

クローズ・トゥ・メタルのアプローチが不気味に聞こえる場合は、過去2年ほどにわたってAMDのGPUの発表をフォローしている可能性があります。 AMDは2013年にMantleAPIを発表したときに業界のオブザーバーを驚かせました。また、2015年3月にMantle 1.0をパブリックSDKとしてリリースしないことを発表し、APIのプラグを抜くことを決定したときに再び驚かせました。 一言で言えば、Mantleは、処理のオーバーヘッドを削減するため、特にCPUの面で、いくつかの状況でパフォーマンスと効率を大幅に向上させることを約束しました。 ゲーマーはやや遅いプロセッサを搭載したカスタムPCを組み立てて、一流のグラフィックカードにより多くのお金を投資できるので、それは良い考えのように聞こえました。 AMDにとっても非常に便利に聞こえました。同社はまだ優れたGPU製品を持っていますが、競争力のあるハイエンドCPUを何年も持っていなかったからです。

泣き叫ぶAMDファンが彼らの救世主の死を悼むために集まったとき、マントルは奇跡的に復活しました。 良いニュースは、AMDのビジュアルおよび知覚コンピューティング担当副社長であるRajaKoduriが書いたブログ投稿の形で届きました。 偶然にも、宗教的なテーマに沿って、2013年のAMDのハワイローンチイベント中に、コドゥリがマウントで説教を行ったことがありましたが、私は逸脱します。

冗談はさておき、コドゥリのチームは良い仕事をしました。 Mantleは新しい業界標準にはなりませんでしたが、Vulkanの基盤になりました。 最大の違いは、VulkanがAMDGCNハードウェアに制限されないことです。 さまざまなベンダーのより多くのGPUで動作します。 あなたはおそらく私がこれでどこに向かっているのかを見ることができます。 さまざまなGPUアーキテクチャ、OSなどに対応する独自のAPIを使用するよりも、さまざまなオペレーティングシステムやハードウェアプラットフォームで動作する単一の低オーバーヘッドグラフィックスAPIを使用する方が少し優れています。

Vulkan APIは、OS、ハードウェア、人種、宗教に関係なく、Mantleパイのかなりの部分を取得し、それをすべての人と共有します。

ああ、もう1つあります。Mantleは最終的にMicrosoftとKhronosにDirectXとOpenGLの肥大化と非効率性について何かをするように強制しました。 ある仲間のToptalerが好んで言ったように、それは後部、つまり「バドンカドンク」での穏やかでフレンドリーなキックでした。

VulkanはOpenGLとどのように比較されますか？

明らかに、VulkanとOpenGLの基本的な違いを概説する必要があります。 Khronosは、新しいAPIを使用してドライバーの肥大化をどれだけ解消できるかを示す簡単な図を作成しました。

Vulkanを使用すると、アプリケーションを金属に近づけることができるため、多くのメモリとエラー管理、および多くのシェーディング言語ソースが不要になります。 ドライバーはより軽く、よりスリムになり、意地悪になります。 VulkanはSPIR-V中間言語のみに依存し、モバイル、デスクトップ、およびコンソール市場向けの統合APIを備えているため、開発者からより優しく、愛情のこもったケアを受ける必要があります。

しかし、待ってください、これは単にゲーム開発者により多くの作業をオフロードしませんか？ 確かに、彼らはハードウェアをより効率的に使用できるようになりますが、彼ら自身の工数はどうでしょうか？ これは、階層化されたエコシステムアプローチが争いに入るところです。

開発者は、Vulkanエコシステムの3つの異なるレベルまたは層を選択できるようになります。

• 最大限の柔軟性と制御を実現するには、Vulkanを直接使用してください。
• Vulkanライブラリとレイヤーを使用して、開発をスピードアップします。
• 新しいAPIで完全に最適化された既製のゲームエンジンを介してVulkanを使用します。

最初のオプションは明らかにすべての人に適しているわけではありませんが、それがいくつかの優れたベンチマークソフトウェアになると思います。 Khronosは、多くのユーティリティとレイヤーがオープンソースになり、OpenGLからの移行を容易にするため、2番目のオプションが「イノベーションの豊富な領域」になることを期待しています。 出版社が微調整と更新を必要とするいくつかのOpenGLタイトルを持っている場合、これは彼らが使用するものです。

最後のオプションは、おそらく最も魅力的なオプションです。これは、Unity、Oxide、Blizzard、Epic、EA、Valveなどの業界の大物によって重い持ち上げが行われているためです。

OpenGLとVulkanの簡単な表を次に示します。

正直なところ、この2つを比較するのは公平ではないと思います。 Vulkanはマントルの派生物であり、OpenGLは20年分の荷物を持ったマストドンです。 Vulkanは大量のレガシーなものを捨てることになっています。 それが要点です。 Vulkanは、SPIR-V中間言語を介して、テストと実装を合理化し、ドライバーをよりスリムにし、シェーダープログラムの移植性を向上させることになっています。

これで次の質問に移ります。 Vulkanは開発者にとって本当に何を意味しますか？

SPIR-Vは言語エコシステムを変革することが期待されています

では、SPIR-Vはどこで機能し、古き良きGLSLはどうなるのでしょうか。

GSLSは今のところ存続し、Vulkanでサポートされる最初のシェーディング言語になります。 GLSLからSPIR-Vへのトランスレータが手間のかかる作業を行います。これで、空腹のVulkanランタイムにSPIR-Vをフィードする準備が整います。 ゲーム開発者は、おそらくオープンソースのコンパイラフロントエンドに依存して、SPIR-VおよびVulkanバックエンドを使用できるようになります。 GLSLに加えて、VulkanはOpenCL Cカーネルをサポートできますが、C++のサポートの追加作業は進行中です。 将来のドメイン固有言語、フレームワーク、およびツールは別のオプションです。 クロノスは、新しい実験言語を開発する可能性についても言及しています。

開発者が何をするにしても、すべての道はSPIR-Vを経由してVulkanにつながり、次に多数の異なるデバイスにつながります。

SPIR-Vは、次の3つの方法で移植性を向上させることになっています。

• 共有ツール
• 単一のISV用の単一のツールセット
• シンプルさ

すべてのハードウェアプラットフォームが高級言語翻訳者を備えている必要はないので、開発者はそれらの少ないものを扱います。

個々のISVは、単一のツールセットを使用してSPIR-Vを生成できるため、高級言語の移植性の問題を排除できます。

SPIR-Vは、一般的な高級言語よりも単純であり、実装と処理が容易になります。

Vulkanの実装方法に応じて、パフォーマンスはさまざまな方法で改善されます。

• コンパイラのフロントエンドはもう必要ありません。多くの処理をオフラインで実行できます
• 最適化パスはより速く解決でき、最適化はオフラインで実行されます
• 複数のソースシェーダーが同じ中間言語の命令ストリームに還元されます

クロノスはパフォーマンスの数値を指定しておらず、「走行距離は確実に変わる」と述べています。 それはすべて、Vulkanの使用方法によって異なります。 ざらざらした詳細を確認したい場合は、必ずSPIR-Vホワイトペーパーを確認してください。

Vulkanは開発者の観点から有望に見えます

VulkanとSPIR-Vを開発コミュニティで人気のあるものにするためのいくつかの機能の概要を説明しました。Khronosもこの点を理解することに熱心です。 同じツールとスキルを使用して複数のプラットフォーム向けに開発する可能性は、特にさまざまなプラットフォーム間のパフォーマンスのギャップが縮まりつつある今、興味をそそられるように思われます。

もちろん、PC向けの高予算のAAAゲームの開発は、多額の現金と人的資源を伴う非常に複雑で時間のかかるプロセスであり続けますが、最新のIntelおよびAMDプロセッサで採用されているモバイルプラットフォームと統合GPUは、すでに多くのカジュアルゲーマー向けのGPUパフォーマンス。 さらに、小規模で独立した開発者、つまりフリーランサーは、主要なパブリッシャーによって開発されたAAAタイトルよりも、クロスプラットフォームのカジュアルゲームに取り組む可能性が高くなります。

Khronosは、SPIR-Vによって可能になった次の利点について概説しています。

• 開発者は、複数のプラットフォームで同じフロントエンドコンパイラを使用して、ベンダー間の移植性の問題を排除できます。
• ドライバーはSPIR-Vを処理するだけでよいため、ランタイムシェーダー/カーネルのコンパイル時間が短縮されます。
• 開発者はシェーダー/カーネルのソースコードを配布する必要がないため、追加レベルのIP保護を利用できます。
• フロントエンドコンパイラを含める必要がないため、ドライバはよりシンプルで信頼性が高くなります
• 開発者はメモリ割り当ての全体像を把握しており、それに応じてメモリ割り当てアプローチを微調整できます。

これは良さそうに聞こえますが、まだ長い道のりがあります。

Vulkan：動作しますが、進行中の作業です

私が言ったように、Vulkanはまだかなり進行中の作業であり、年末までに完全な仕様を取得する必要があります。 ただし、これまで見てきたことから、新しいAPIは、現世代のハードウェアを使用しても多くのパフォーマンスを引き出すことができます。

私がこれまでに見たVulkanの最高のイラストは、そこにある主要なモバイルGPUの衣装の1つであるImaginationTechnologiesからのものです。 Imagination Technologies GPU IPは、他の多くのARMベースのシステムオンチップ設計とともに、すべてのiOSガジェットで使用されており、一部の低電圧Intelx86チップでも使用されています。

先週、Imaginationは、Vulkanによって可能になったパフォーマンスの向上について詳しく説明したブログ投稿を公開しました。 ハードウェアの選択はやや珍しいものでした。PowerVRG6430GPUを搭載しためったに使用されないIntelクアッドコアプロセッサをベースにしたGoogleNexusPlayerです。 デバイスはPowerVRGPU用の最新のVulkanAPIドライバーでテストされ、リファレンスの実行はOpenGLES3.0で実行されました。 パフォーマンスのギャップは驚異的なものでした。

シーンには、13,000から300の頂点に及ぶ、さまざまな詳細レベルの合計400,000個のオブジェクトが含まれています。 ワイドショットは、推定100万個の三角形、植物のアルファ、ノームと植物の約10個の異なるテクスチャを示しています。 各オブジェクトタイプは異なるシェーダーを使用し、ノームはインスタンス化されません。各描画呼び出しは、異なるマテリアルを使用した完全に異なるオブジェクトである可能性がありますが、最終結果は同様になります。

それでも、大きな注意点があります。これは、実際の生活で期待できるようなパフォーマンスの向上ではありません。 Imagination Technologiesチームは、誇張されたシナリオを使用してVulkanの優位性を強調し、それを限界まで押し上げました。この特定のシナリオでは、限界はVulkan対OpenGLESに有利です。 また、このテストはGPUにバインドされていますが、それでもVulkanの優れたCPU使用率を示す良い例であることに注意してください。

VulkanはCPU使用率をどのように削減しますか？

以前に持っていたOpenGL対Vulkanテーブル、より具体的には、そのタイルレンダリングビットを覚えていますか？ おそらくそうではないので、一言で言えば、ImaginationはVulkanを使用して、呼び出しをタイルにバッチ描画し、一度にタイルをレンダリングしました。 フレームがレンダリングされた時点でタイルがどこにあるかに応じて、タイルが表示されたり表示されなくなったり、詳細レベルを変更したりすることができます。 OpenGL ESでは、すべての描画呼び出しは動的であり、視野内にあるものに応じて、フレームごとに送信されます。 すでに実行されている描画呼び出しはキャッシュできません。

その結果、OpenGL ESは、ドライバーの状態を変更して検証するために、カーネルモードへの多くの呼び出しを必要とします。 Vulkanは、CPUオーバーヘッドを削減し、レンダリングループ中に検証またはコンパイルする必要をなくすために、事前に生成されたコマンド（コマンドバッファー）に依存しているためではありません。 イマジネーションチームは、コマンドバッファを再利用する機能を「状況によっては便利」であり、多くのゲームやアプリケーションで「かなりの程度」使用できると説明しました。

2番目のゲームチェンジャーは並列バッファー生成です。これにより、VulkanはすべてのCPUコアの能力を活用できます。 OpenGL ESは、マルチコアモバイルチップが登場する前に設計されましたが、過去3年間で、業界はAppleのAシリーズSoCとデンバーベースのNvidia Tegraを使用して、2、4、8、10のCPUコアに移行しました。唯一の注目すべき例外としてのチップ。 以前のブログ記事の1つで、モバイルSoCのトレンドについて話しました。これは、今後の最適化Androidコンパイラについて説明しているので、追加情報を確認できます。

例えを試してみましょう。Vulkanが内燃エンジンの場合、ターボチャージャーとインタークーラー（コマンドバッファー）とほぼ同じように、その出力の一部を保存して再利用し、4、6、効率を損なうことなく8気筒または10気筒（並列バッファー生成）。 VulkanとOpenGLESの比較は、新しい小型のターボエンジンを、おじいちゃんのTriumphTrophyの古い単気筒エンジンと比較するのと少し似ています。

まあ、少なくともおじいちゃんはモッドではなく、適切なロッカーでした。

最終的には、ほとんどのシナリオでCPUバウンドであるOpenGL ESとは異なり、利用可能なすべてのハードウェアを有効に活用できる、はるかに効率的な環境になります。 つまり、Vulkanは、CPUをより低いクロックに保ちながら、同様のレベルのパフォーマンスを提供できるため、消費電力とスロットルを削減できます。

潜在的なVulkanAPIの欠点（ネタバレ注意：それほど多くはありません）

私はつまらないものではありません。 VulkanAPIの長所と短所をリストすることも重要だと思います。 幸いなことに、いくつかのマイナーなものと、場合によっては1つまたは2つの大きなものを除いて、それほど多くの短所はありません。 Vulkanがスライスされたパン以来の最高のものであり、次のプロジェクトでそれを試してみたい場合は、次の点のいくつかを検討することをお勧めします。

• 特定のシナリオでコードの複雑度を追加
• 市場投入までの時間
• 業界サポートのレベル
• 一部のプラットフォーム（デスクトップ）では、Vulkanはそれほど関連性がないか効果的でない場合があります
• 一部のプラットフォームでVulkanを使用するように開発者を説得する
• レガシーハードウェアとの限られた互換性

開発者がこの投稿で概説されている優れた機能のいくつかを実装したい場合は、かなりの量の作業が必要になります。 それぞれをコードで実装する必要がありますが、良いニュースは、業界のリーダーが新しいドライバーの更新でプロセスを簡単にすることです。

古いアプリやゲームでのVulkanの実装と同様に、市場投入までの時間も別の懸念事項です。 Vulkanはまだ技術的なプレビューです。 初期の仕様と実装は2015年末までに予定されているため、現実的には、2016年半ばまでは実際のアプリケーションはあまり見られないでしょう。

業界のサポートは問題ではありません。 結局のところ、これはクロノスの標準ですが、しばらく時間がかかる場合があります。 これが、この投稿をモバイルセグメントに焦点を当てた理由の1つです。 モバイルソフトウェアとハ​​ードウェアはより急速に進化し、Vulkanがデスクトッププラットフォームに影響を与えるまでにはさらに数四半期かかる可能性があります。 これが業界の仕組みです。デスクトップのニッチでは、心配すべきことがたくさんあります。プロのアプリケーションのサポート、ピッチフォークを振るうゲーマーの大群が、破れたフレームごとに類人猿をしているなどです。 ただし、VulkanがAMDのマントルから派生しているという事実は心強いものです。

VulkanはCPUバウンドの設定で、特にマルチコアモバイルSoCで驚異的なことを行うことができますが、これらのパフォーマンスの向上はデスクトッププラットフォームでは制限されます。 デスクトップは、より高いレベルの効率でマルチコアプロセッサを処理し、グラフィックを要求するアプリケーションのほとんどはGPUにバインドされています。

パズルのすべてのピースが所定の位置に収まるまで、一部の開発者は思い切ってVulkanをいじりたがらないかもしれません。 多くの人は単に実験する時間がなく、絶対に必要な場合にのみ新しいスキルを学びます。 この初期段階でVulkanを使用するために既存のモバイルゲームを微調整するために多くのお金を費やし、工数を浪費することは、多くの開発者やパブリッシャーにとって選択肢にはなりません。

古いハードウェアとの互換性は、もう1つの懸念事項になる可能性があります。 Vulkanには、OpenGLES3.1またはOpenGL4.1ハードウェアと新しいドライバーが必要です。 たとえば、ImaginationTechnologiesのPowerVRシリーズ6GPUはそれをサポートできますが、シリーズ5はサポートできません。 QualcommのAdreno400シリーズはOpenGLES3.1をサポートしていますが、300シリーズはサポートしていません。 ARMのMaliT600およびT700シリーズはOpenGLES3.1をサポートしていますが、古いT400シリーズの設計ではサポートが不足しています。 幸いなことに、Vulkanが関連するようになるまでに、サポートされていないGPUを備えたほとんどのデバイスは見えなくなります。 これらには、iPhone 5 / 5C、特定の5000シリーズExynosチップに基づく第4世代iPadおよびSamsungデバイスが含まれます。 Adreno 300シリーズGPUは、Snapdragon 410、Snapdragon 600、Snapdragon 800、801などの比較的最近の多作なデザインで使用されているため、Qualcommベースのデバイスはそれほど幸運ではない可能性があります。バルカンは本当に関連性があります。

長生きしてレンダリングする

Vulkanがゲームチェンジャーになるかどうかを言うのはまだ時期尚早ですが、Vulkanには十分な可能性があることに同意していただけると思います。 それは大したことだと思います。その仮定は、GPU業界をカバーする10年の経験に基づいています。 ただし、時間がかかります。Vulkanは、デスクトップランドスケープを変更し始める前に、モバイルでその存在感を感じさせると思います。

ほぼ同時に、Vulkanに最適化されたドライバー、ゲームエンジン、およびゲームで、新しいハードウェアを試してみることができます。ハードウェアを少し調整するだけではありません。 モバイルSoCの開発は、私が今は触れないいくつかの理由で行き詰まっていますが、14 / 16nm FinFETノードがより多くのメーカーに利用可能になり、主流のハードウェアではなく経済的に実行可能になるため、2016年は業界にとって大きな年になるでしょう。フラッグシップチップ。

開発者は、はるかに強力で効率的なハードウェアを試してみることができ、新しい低オーバーヘッドのグラフィックスAPIがアイシングになります。 無意味に高い解像度は視覚的な品質には何の役にも立たないが、それでも電力を浪費するので、ハードウェアベンダーがマーケティングの仕掛けとしてディスプレイ解像度を使用するのをやめることを心から願っています。 残念ながら、平均的な消費者はこれを理解しておらず、箱にもっと大きな数字を見たいと思っているので、これはすぐには起こらないと思います。 この奇妙な問題については、今後の投稿の1つで調べるつもりです。そのため、気になる場合は、コメントセクションにご注目ください。