西川善司の3DGE：AMDのVR向けSDK「LiquidVR」は，VRフォーマット戦争の調停者となりうるのか

Layla Mah（Head Design Engineer, AMD）氏は，もともとゲームグラフィックスのプロフェッショナル。DOOM 3において，影生成のRadeon向け最適化などに従事していた経験を持っている

　北米時間2015年3月3日，Game Developers Conference 2015（以下，GDC 2015）に合わせる形で，AMDは，仮想現実（以下，VR）向けのソフトウェア開発キット（SDK）である「LiquidVR」を発表した（関連記事）。

　同日AMDは，このLiquidVRに関する技術説明会を実施したので，今回はその内容を踏まえ，LiquidVRとは何かをまとめてみたいと思う。
　なお，説明会で登壇したのは，AMDでデザインエンジニア長を務めるLayla Mah氏だ。

Liquid VR，その登場の背景

　Mah氏によると，Liquid VRの開発目標は，下記の3項目だ。

• 快適（Comfort）なVR体験を実現する
• 互換性（Compatinility）の高いVRアプリケーションを開発できるようにする
• 魅力的なコンテンツ（Compelling Content）を作りやすくする

LiquidVRの開発目標は3C

　3項目はすべて「C」から始まることもあって，AMD内部では「3C」と呼ばれていたそうだ。そんな3C要素を実現するため，LiquidVRのSDK 1.0では，大きく分けて下に挙げる4つの機能要素が盛り込まれることになった。

• Latest Data Latch（最新データの受け取り）
• Asynchronous Shaders（非同期シェーダ）
• Affinity multi-GPU（高効率なマルチGPU活用）
• Direct-to-Display（ディスプレイへの直接表示）

LiquidVRのSDK 1.0で提供される4機能

Latest Data Latch〜頭部の向きや位置に関する最新情報を取得する機能

　Latest Data Latchは，一言でまとめるなら，VR対応型ヘッドマウントディスプレイ（以下，HMD）の向き追従（ヘッドトラッキング）に関係した機能項目になる。

　VRにおける「描画→表示」を順方向で考えた場合，まず「頭部の向きを取得」して，「その向きの視界を描画する」という流れになる。
　この描画を所要時間ゼロ秒で処理できれば何の問題もないが，もちろん，そうもいかない。そこで，最新世代のVR技術では，描画開始段階の頭部の向きを取得して描画に取りかかりつつ，その描画にかかる所要時間のうちに頭部がさらに動くことを想定して，映像表示の直前に，頭部の向きをもう一度取得するようになっている。そして，その「頭部の向きの最新状態」につじつまが合うよう，映像の描画にあたって「位置ずらし」するのだ。

　もう少し分かりやすい具体例を出してみよう。
　たとえば，ユーザーが首を左に素早く振っている途中で映像描画が始まったとする。その場合，GPU側で映像を描画（レンダリング）している間にも首は左方向へ回転し続けているはずなので，描画完了時にできあがった映像は，いわば過去のものとなっているわけだ。首は描画時点よりもさらに左に向いてしまっているので，描画された映像は，過去の映像として視界のやや右寄りに表示されたほうが，頭部の動きとは合致するはずである。

　最近，こうした処理系がVRでは必須といわれており，こういった位置ずらしのことを，Oculus VRは「TimeWarp」，ソニー・コンピュータエンタテインメント（以下，SCE）は「Temporal Reprojection」と呼んでいたりする。
　なお実際には，HMD上で映像を表示するにあたって，HMDが持つ光学系の歪みを吸収する「変形」（Image Warping）処理も同時に行われるので，その点は付記しておきたい。
　ともあれ，本稿では以後，この位置ずらしのことをTimeWarpと呼ぶが，このTime Warpにあたって必須の機能となるのが，Latest Data Latchなのである。

　Latest Data Latchでは，頭部の向きだけでなく，頭部の位置（※x，y，zからなる3D絶対座標）もサポートしている。Oculus VR「Rift」の「Development Kit 2」や「Crescent Bay」（開発コードネーム），SCEの「Project Morpheus」（開発コードネーム）は，いずれも頭部の6軸自由度（6DoF）に対応するわけだが，これらと組み合わせたとき，Latest Data Latchは，頭部の向きと位置，両方を取得できるのだ。

図中の歯車のアイコンがLatest Data Latch。Latest Data LatchはVRにおける映像描画時と映像表示時に利用する機能ということになる

　Mah氏は詳しく述べていなかったが，LiquidVRの仕様を考えると，Latest Data Latchはおそらく，異なるメーカーのVR対応型HMDに搭載されている加速度センサーやジャイロスコープ（＝角速度センサー）などの違いを吸収し，必要な情報をレポートする仕組みを搭載しているものと見られる。

従来の方法（上段）では，CPUとGPU間で行われる定期的な同期のタイミングでしかこうした情報をやりとりできなかった。それに対してLiquidVRのLatest Data Latchでは，頭部状態情報の取得をmGPUが欲しいときにGPU主導で行える実装になっている（下段）

Asynchronous Shaders〜グラフィックスレンダリングパイプラインと並列動作するGPGPUベースのポストエフェクト処理群

　前述したように，VRでは，TimeWarp処理が欠かせない。
　その処理を行うためには，頭部の向き――6軸自由度システムでは頭部の位置も含まれるが，以下，その件は省略する――情報が必要であり，その情報を取得するための機能がLatest Data Latchであるわけだが，TimeWarp処理ではこれ以外にも，描画した映像の変形加工処理が必要になる。

　この変形処理は実質的に，3Dグラフィックスとしてレンダリングした結果に対して施すポストプロセス的な処理に相当する。そして，こうした画像ポストプロセスは，多くの場合，「単純処理の超並列処理」の形で実装できるから，GPGPU（Compute Shader）でまかなえるはずだ。
　というわけでLiquidVRでは，TimeWarp処理に必要な画像処理はもちろんのこと，そのほかのさまざまなVR向け画像処理をGPGPU的に実装し，ライブラリとして提供することになった。これが，LiquidVRのAsynchronous Shaders機能ということになる。

Asynchronous Shadersは，主にGPGPUで使われるVR向けポストプロセスライブラリ的な機能になる。TimeWarp処理向けの画像処理がその代表格だが，スライドには「大局照明」の記述もあった

　次の図を見てほしい。
　これは，TimeWarp画像処理をグラフィックス描画パイプラインで実装した事例になる。時間は左から右に向かって進行していて，中央付近の破線はVsync（垂直同期）を，ワイヤーフレームのような円はTimeWarp処理を示している。

VRでカク付きが起こってしまうケースの例

　図の上段側は，シーンの描画をVsyncよりもかなり前に終えられている例だ。TimeWarp処理を行ってもVsyncに間に合っているため，HMDでの表示に遅延は生じない。
　一方の下段は，シーンの描画こそVsync前に済んだものの，TimeWarp処理が終わったときにはVsyncのタイミングを逃してしまった例になる。この場合，HMD側には引き続き前フレームが継続表示されてしまい，新しい映像はその後のVsync時にやっと表示されることとなるため，映像体験としてはカク付き（Judder）を感じることになってしまう。

　では，Asynchronous Shaders機能があると，どういう対応が取れるだろうか。
　シーンの描画がVsyncの直前まで長引いてしまったして，そのままTimeWarp処理を行っていたのでは，先ほどの例の下段と同じ結果になる。そこで，こういう自体が予見できるときには，Asynchronous Shadersを使って「現在実行されているシーンの描画」と並行して，現在表示されている全フレームに対して，最新の頭部の向き状態と辻褄の合うTimeWarp処理を行って，表示するのだ。
　もちろんこれは，映像の正確性という観点からすると，事実上のコマ落ちに相当するわけだが，頭部の動きに対応しないカク付きよりはマシである。

TimeWarp処理をしていては直近のVsyncに間に合わないと判断されたときは，Latest Data Latchで最新の頭部の向き情報を取得したうえで，Asynchronous Shadersを使って前フレームに対してTimeWarp処理を行う。結果，事実上のコマ落ちにはなるが，少なくとも頭部の動きに追従した移動は相応に再現されるので，この事態がよほど連続で続いたりしない限り，ユーザーが違和感を覚えることはない（はず）

　ポイントは，グラフィックスレンダリングパイプラインによるシーン描画はそのまま継続させたまま，そのバックグラウンドで前フレームの映像に対してTimeWarp処理を行うところだ。
　Mah氏によると，これはAMDのGraphics Core Next（以下，GCN）アーキテクチャが持つ特徴とのこと。「GCNアーキテクチャのGPUであれば，グラフィックス描画に影響を与えず，同時に別処理をGPGPUで行える。これは競合のGPUにはない特徴だ」（同氏）。

Affinity multi-GPU〜マルチGPUをVRで高効率に活用する

　Affinity multi-GPU機能は，VRに適したマルチGPUソリューションを提供するものだ。
　複数のGPUをシステムに搭載してレンダリング性能を強化するにあたって，最も効率が良い（＝高い性能が得られる）のは，Alternative Frame Rendering（以下，AFR）方式だとされている。たとえばAとB，2基のGPUからなる2-wayシステムがあったとして，Aには奇数フレームをレンダリングさせ，Bには偶数フレームをレンダリングさせるようにすれば，それぞれの描画処理を効率よくオーバーラップさせることができるというのがその理由だった。

　しかしVRの場合，次フレームの描画をもう一方のGPUで先行開始ができたとしても，表示時にTimeWarp処理が入る運命にある。VRの場合はむしろ，その時間軸において切り取ったシーンの描画を早く終えることを目的として複数のGPUを活用したほうが効果が大きい。
　VRの場合は――実質的に3D立体視でも同様だが――その瞬間のシーンを左目と右目から同時に描画する必要がある。であれば，左目用の映像をGPU A，右目用の映像をGPU Bで描画すれば，それぞれの描画を独立・並列に実行できるから，2つの映像をより高速に描画できるはずだ。

　そこでLiquidVRでは，GPUを2基搭載するシステムにおいては，2基あるGPUをそれぞれ左目用と右目用の映像描画に割り当てる仕組みを実装したのだ。それがAffinity multi-GPUの正体である。

Affinity multi-GPUは，2基のGPUを左目用と右目用の描画にそれぞれ割り振る機能

　Affinity multi-GPUのメリットは，アプリケーション側だと，2基のGPUを意識せずに描画を設計できるところにある。
　平面視のゲームグラフィックスにおけるAFRでは，各GPUが異なる時間軸上のシーンを描画するため，最悪の場合，2基のGPUがまったく異なるシーンデータで描画を取りかかることがありえた。だからこそ，「各GPU上のローカルメモリ（≒グラフィックスメモリ）に何をコピーして何を新たに用意しなければならないか」を見極める必要があり，アプリケーション側ではそこに配慮する必要があったのだ。

　ところが，VRにおけるシーンの左目用描画と右目用描画では，同一時間軸上のシーン描画となる。なので，異なるのは，左右の視点座標と視界の向きくらい。シーンデータは完全に同一のはずである。
　そこでAffinity multi-GPUでは，グラフィックスドライバが，描画に必要なデータを自動的に2基のGPUに転送し，異なる視点位置と視界向きの情報だけ個別に用意して，それぞれに描画を仕掛けるようにした。こうすれば，2基のGPUを持つシステムで自動的にVRでの性能が向上するというわけである。

システムに搭載されるGPUの数が1基か2基かをとくに意識することなくVRアプリケーションを開発できる。GPUが2基搭載されたシステムでは，自動的に高速化が図られるイメージだ

Direct-to-Display〜HMDを使いやすくするための機能群

　Direct-to-Displayは「表示」（Display）に関連した複数の機能から構成される。

Direct-to-Display機能は複数の機能項目からなる

　1つは，LiquidVR側で，異なるメーカー間で存在する，HMDの表示仕様の違いを吸収するような機能だ。
　LiquidVRがサポートしているVR対応型HMDであれば，VRアプリケーション側は，システムに接続接続された「HMDごとの仕様の違い」を気にせず開発できる。たとえば，HMDごとにHMDの表示解像度や表示画角などは異なるが，そうした違いはLiquidVRで面倒を見てくれるというわけである。

　2つめは，Windows環境下においてデスクトップ環境を維持したまま，接続したHMDに対してだけVR映像を出力できる機能だ。最近のRadeonはどれもマルチディスプレイ機能「Eyefinity」をサポートしているが，ここではEyefinityを応用し，HMDが接続された映像出力端子に対してのみVR映像を出力するといったことを可能にする。

　3つめは，現在表示しているフロントバッファに対して直接描画する機能だ。
　一般的な3Dグラフィックスアプリケーションでは，表示されていないバックバッファに映像を描画して，表示されているフロントバッファと，描画されたバックバッファの機能を交換して（フリップして）表示するメカニズムを採用しているが，LiquidVRでは，あえて意図的に，表示中のフロントバッファに描画することができる機能を搭載している。
　Mah氏いわく「この機能をAsynchronous Shadersと併用することで，TimeWarp処理をしているそばからHMDに対して映像を出力していける」とのことだ。

　「シーン描画」と「TimeWarp処理」の両方がVsyncタイミング前に終わっていない場合，LiquidVRではAsynchronous Shadersを利用して，前フレームに再TimeWarp処理した“その場しのぎ”をするしかない。しかし，Direct-to-DisplayとAsynchronous Shadersを併用すると，TimeWarp処理をしながら映像出力できるので，シーン描画に掛けられる時間を長く取れるようになるというのがAMDの主張である。

最新シーンの描画完了がVsyncに間に合わないときは，LiquidVRのDirect-to-Displayを用い，描画完了しているところからTimeWarp処理してフロントバッファに描き出していける

　映像信号はフロントバッファを走査（スキャン）することでディスプレイ機器に送出されるので，フロントバッファの内容が書き換わるような描画をすると，テアリング現象を誘発してしまうはずだ。
　実際問題，テアリングは起こりうるのだが，VRでは75fpsや90fpsなどといったハイフレームレートが前提となるため，数フレームに1回のペースで「Vsyncに間に合わない」状態になったとしても，気づかれにくいとされている。もっとも，そんな状態が連続すると，さすがにテアリンクは知覚されるはずだが。

LiquidVRは，VR界のDirectXやVulkanを目指す？

　現在，さまざまなメーカーからVR対応型HMDの発表が相次いでいるが，当然，各HMD間には互換性がない。
　それこそ1990年代中期から後期のGPU乱立時代，GPUメーカーは，ゲームアプリケーション側に「対応プログラム」を用意してもらって，専用ゲームの魅力でGPUを売るような商法を展開していたが，現在のVR HMD乱立状態を見ると，ああした戦国時代の再来が予感される。

　GPUの場合，Windows環境においてはMicrosoftのDirectXがGPUごとの機能差を吸収し，アプリケーション開発側の苦労をある程度軽減させることができた。
　今回AMDが発表したLiquidVRは，VRアプリケーション開発向けSDKという位置づけだが，HMD製品ごとの機能差を吸収し，VRアプリ開発に必要な基本機能を一通り提供するミドルウェア的な側面も強い。それこそ，役割的には“あのとき”のDirectXのようだ。

Oculus VRのAnuj Gosalia氏（Director of Engineer）は，LiquidVRへの対応意志を表明（上）。CrytekのDario Luis Sancho Pradel氏（Senior Programmer）もCRYENGINEのLiquidVR対応方針を発表した（下）

　現在のLiquidVRは，AMD製のSDK/ミドルウェアということで，GCNコアベースのRadeonと組み合わせたときにしか利用できない。ただ，機能自体はどれも「かゆいところに手が届く」便利なものが多く，汎用性は高いといえる。
　立ち上がったばかりのVR業界としても，VRを一発ネタで終わらせずに継続的に発展させていきたいはずで，そのためには，VRアプリが広くリリースされる必要があることは理解していることだろう。それだけに，LiquidVRのような，VRアプリ開発向けSDK/ミドルウェアは今後，ますますニーズが高まっていくはずである。
　最近のゲーム開発はゲームエンジンベースで開発されることも多い。LiquidVRのようなVR SDKやVRミドルウェアは，ゲームエンジン側で対応してしまえば，ゲームエンジン上でゲーム開発をするときにはまったく気にする必要のないものだったりする。その意味で，AMDは，“汎用SDK”として売り込むというよりも，VR HMDやゲームエンジンとの協業を目指していくことになるのではなかろうか。

　AMDの技術では，自社開発した新世代グラフィックスAPI「Mantle」が，オープンスタンダードAPI「Vulkan」の一部としてKhronos Groupに採用されたばかり（関連記事）。
　もしかすると，AMDはLiquidVRでも，このようなオープンスタンダードの立ち位置を狙っているのかもしれない。ただ，AMD自身はVRシステムを持っていないので，業界における発言力がどの程度あるのかは，計り知れないところがある。

LiquidVRの説明会場にあった，Cresent Bayベースのデモを体験中の筆者。体験しているのは，「ロボットと兵士とが激しい戦闘をしている戦場がスローモーションで展開される世界」を駆け抜けていくデモだ。このデモはUnreal Engine 4ベースなので，Unreal Engine 4もLiquidVRに対応するということなのだろう

AMDのLiquidVR解説ページ（英語）