NVIDIAの新機軸を理解する（1）：GeForce GRIDが描く「ゲームスタジオが独自のゲームプラットフォームを描く時代」

　Keplerアーキテクチャを採用するGPUの市場投入に合わせて，NVIDIAは，いくつかの新技術や方向性などを打ち出した。その内容は，NVIDIA主催の開発者会議「GPU Technology Conference 2012」以降，断続的に説明されてきているが，ここで一度，西川善司氏にまとめてもらおうと思う。第1回は，クラウドゲームを実現する「GeForce GRID」についてだ。

　NVIDIAは，Keplerアーキテクチャで，GPU仮想化技術を身に付けた。
　「GPUの仮想化」とは，1基のGPUを，見かけ上（＝論理的に）複数個あるように見せかける技術だ。

GTC Japan 2012でGeForce GRIDについての発表を行った橋本和幸氏（Sr.Director, Entertainment Technology, NVIDIA）

　仮想化が可能になると，CPUがそうであったように，GPUを応用する幅が各段に広がる。その可能性を細かく語ろうとすると，CPUの仮想化がどういうもので，それがエンタープライズの世界にどのようなメリットをもたらしたかまで語らないといけなくなるので，今回はあえて無視するが，ともあれNVIDIAは2012年，Keplerアーキテクチャへの移行に合わせて，「NVIDIA VGX」と「GeForce GRID」という，2つのGPU仮想化ソリューションを発表している。

　7月26日の記事などでお伝えしているとおり，NVIDIA VGXは企業向けのソリューションなので，本稿ではGeForce GRIDの可能性を，7月に開催されたGPGPU関連イベント「GTC Japan 2012」の内容中心に，考えてみたいと思う。

GeForce GRIDって何？

クラウドゲームサービスって何？

GeForce GRID Boardのイメージ。本文でグラフィックスカードとは述べたが，出力インタフェースが用意されていないので，「レンダリング専用カード」と述べたほうが正しいかもしれない

　本題へ入る前に，GeForce GRIDについての基本事項をおさらいしておこう。
　GeForce GRID（ジーフォースグリッド）とは，Kepler世代のGPUを複数搭載した専用グラフィックスカード「GeForce GRID Board」を搭載するサーバーによって提供される技術およびサービス名である。

　GeForce GRID Boardは，PCI Express x16接続のカードなので，普通にPCへ搭載できてしまいそうだが，一般ユーザーに市販されることはない。基本的には業務用製品という扱いになる。
　そして，このGeForce GRID Boardを搭載したサーバーでユーザーが何を得られるかと言えば，クラウドゲーム（Cloud Gaming）のサービスだ。

　では，クラウドゲームサービスとは何なのかというと，ざっくり言えば，下に挙げるようなゲームシステム（＝ゲームサービス）のことである。

1. サーバー側でゲームそのものを動かし，その映像をネット経由で配信
2. クライアント（＝プレイヤー）側は，インターネット接続機能と入力インタフェースを持ったPCやスマートフォン，タブレットなどでその映像を見て，アクション（＝ゲームに対応する操作）を行う
3. サーバー側でユーザーからのアクションをインターネット経由で取得し，ゲームを進行させる
4. 再び1.へ

クラウドゲームの進行イメージ

ソニー・コンピュータエンタテインメントが買収した「Gaikai」や，Ubitusの技術を用いた「ジークラウド」など，すでにいくつかの商用クラウドゲームサービスが始まっている

　クラウドゲームでは，サーバー側で「プレイに参加しているユーザー人数分のゲームクライアント」を動かす必要がある。このときサーバー上では仮想マシン――実体の存在しない，プレイ参加ユーザー専用のPC環境のようなもの――を立ち上げて，その上でゲームクライアントを動かすことになるのだが，ここで厄介になるのが，当該タイトルのグラフィックスレンダリングだ。

　GPUはこれまで仮想化に対応していなかった。なので，複数の仮想マシンからのレンダリング命令を直接実行することができなかった。その弱点があったため，これまでは，各仮想マシンにおけるレンダリングタスクを，サーバー上のハイパーバイザ（Hypervisor，仮想マシンの制御用ソフトウェア）に集約してスケジューリングし，GPUにレンダリングを発注し，その結果を各仮想マシンに戻すといった手法が用いたられていたほどだ。
　この従来的な手法をGPUのソフトウェア仮想化というが，Kepler世代では，GPUの仮想化をハードウェアレベルで行えるようになった。各仮想マシンは（概念的には）GPUを直接“叩いて”レンダリングできるようになったのだ。

GPUソフトウェア仮想化（ソフトウェアベースのGPU仮想化）の概念図

Keplerアーキテクチャを採用するGPUで可能になった，ハードウェアベースのGPU仮想化概念図。この図自体はNVIDIA VGXを説明したものだが，実のところ，GeForce GRIDとNVIDIA VGXの根幹技術は同じである

　1枚のカードにKeplerアーキテクチャを採用したどのGPUコアを何基搭載するのかといった，GeForce GRID Boardのハードウェア構成は，クラウドゲームサービスを行う業者やサーバーのスペックにもよるため，一概には言えないが，少なくとも，GK104やGK107を搭載する製品は存在するようだ。

　重要なのは，GPU 1基で複数クライアントのゲームグラフィックスをレンダリングできる点だ。現状のGeForce GRIDでは，シェーダプロセッサへの負荷が高いとか，フレームレートへの要求が厳しいとか，高解像である必要があるとか，そういった負荷の高いタイトルは2〜4クライアント分，そうでないタイトルは1基あたり4〜8クライアント分をGPU 1基に担当させることを想定しているという。

レンダリング結果はリアルタイムエンコードして

クライアントへストリーム配信

　さて，クラウドゲームサービスでは，ゲームグラフィックスを仮想マシンでレンダリングできただけでは不十分で，それ自体をユーザーの端末に伝送する必要がある。そこで利用されるのがビデオストリーミング技術だ。仮想化GPUによってレンダリングされた「連続したゲームグラフィックス」をリアルタイムにH.264（MPEG-4 AVC）形式へエンコードして，ビデオストリームとしてネット配信するのである。

　GeForce GRIDではこの部分も，Keplerアーキテクチャならではの要素を用いている。Kepler世代のGPUが内蔵するハードウェアH.264エンコーダ「NVENC」だ。
　元映像の複雑性やフレームレートにもよるが，NVENCでは基本的に，1080pのビデオをリアルタイムの4倍速でH.264形式へエンコード可能とされている。なので，複数の連続したゲームグラフィックスをH.264のビデオストリームとしてリアルタイム配信させるのにも十分利用できるというわけなのだ。

　ちなみにNVIDIAは「GeForce GRIDベースのクラウドゲーム環境が立ち上がれば，現在の家庭用ゲーム機と同等以上のグラフィックス品質を持ったゲームタイトルを，家庭用ゲーム機と同等以上の反応速度でプレイできる」と主張している。

GeForce GRIDにおける遅延（≒反応速度）イメージ

　反応速度を，遅延時間の形で従来のゲームシステムと比較したものが下のスライドだ。下段が家庭用ゲーム機，中段が従来のクラウドゲームサービス，上段がGeForce GRIDベースのクラウドゲームサービスを表している。
　筆者の目から見ても，示されている値の想定の甘さや説得力の低さは否めないのだが，要するにこの図は「ハイスペックなレンダリング能力を持ち，リアルタイムの何倍もの速さで映像をリアルタイムエンコードできる仮想化対応のGPUをサーバーに搭載すれば，クラウドゲームの体験は，家庭用ゲーム機でのそれに近づいていくはずだ」という，NVIDIAの予測というか，希望を示しているのである。

GeForce GRIDにおける遅延が家庭用ゲーム機とほとんど変わらないとするスライド。GTC Japan 2012では，橋本氏もこのスライドの見通しが甘いことを指摘していた

　GTC Japan 2012で橋本氏は，「現行世代のゲーム機と同等か，それ以上のゲームグラフィックス品質によるクラウドゲームが，GeForce GRIDならば実現可能」というメッセージを伝えるべく，GK107コアのGPUを1基搭載するGeForce GRID Boardが差さったサーバーでリアルタイム技術デモを動作させ，手元の端末でそれを操作してみせた。


　これは7月27日の記事で取りあげたものだが，あらためて紹介しておくと，デモ自体はシリコンスタジオがリリースしているポストエフェクトミドルウェア「YEBIS 2」のもの。GTC Japan 2012では，このデモを1280×720ドット解像度（720p）で，2台の仮想マシン上で動作させていた。
　実効フレームレートは30fps。上のムービーで映っているのは，GeForce GRIDサーバー上で仮想マシン2台分のリアルタイムレンダリングを行って，30fpsのリアルタイムH.264エンコードを行って，手元の端末へ伝送されてきたものだ。

　ムービーを見てもらうと分かるが，橋本氏はこのデモがリアルタイムであることを示すために，動きをいったん止めたり，視点を変えたりといった操作を行っていた。技術的にはたしかに可能そうだとイメージできても，こうして，このクラスのリアルタイムグラフィックスレンダリングを2インスタンス（＝2台の仮想マシン分）見せられると，あらためて驚かされる。

クラウドゲームはオンラインゲームのための

究極的なプラットフォームか

　橋本氏は，クラウドゲームサービスは，将来的にMMORPGのようなオンラインゲーム向けとして，最も適したゲームプラットフォームになるのではないかと予測している。

　現在のクラウドゲームサービスは，プレイヤーのゲーム実行環境をクラウド側の仮想マシンで実行させるという考え方だ。
　つまり，オンラインゲームをそのままクラウドゲームサービス化させた場合，ゲーム世界を司るオンラインゲームサーバーは別にあって，仮想マシンが動作するクラウドゲームサーバーと通信を行い，そこで得られた情報を基に，各プレイヤーのための「仮想マシンで実行されているオンラインゲームのクライアント」を動かすことになる。

今日（こんにち）のクラウドゲーム（左）。このシステムをそのままオンラインゲーム用に持って行くと，クライアントとクラウドゲームサーバーが通信し，さらにクラウドゲームサーバーとオンラインゲームサーバーが通信することになる（右）

　そもそも，「ゲーム環境」をクラウドへ持って行くのならば，もともと“クラウド側”にあるオンラインゲームサーバーと統合させたほうが合理的だ。そうすれば，オンラインゲームサーバーとクラウドゲームサーバー間における通信の遅延をなくすことができる。
　さらにいえば，各仮想マシンで同じランタイム（runtime，プログラムの実行に必要なソフトウェア）を動作させておくのも冗長的ではないか，と橋本氏は続ける。各ユーザーが仮想マシンで同じMMORPGをプレイしていると，クラウドゲームサーバー上では，プレイヤーの人数分だけ仮想マシンが起動し，その上でまったく同じプログラムが走り，グラフィックスデータがメモリに読み出されることになる。
　ならば，オンラインゲームサーバーとクラウドゲームサーバー側を統合させたサーバー側――本稿では便宜上，以下「統合ゲームサーバー」と呼ぶ――で，両方の機能を持つマッシブなゲームプログラムを実行させれば，各仮想マシンで走るフロントエンド分のプログラムは非常にコンパクトなものにできるはずだ。そうなれば実行性能は向上するはずだし，副次的にはエネルギー効率のよさももたらしてくれるだろう，というのが橋本氏の予測だ。

オンラインゲームサーバーとクラウドゲームサーバーを統合し，統合ゲームサーバー化するのが理想

　こうした統合ゲームサーバーの形態になると，現在でもオンラインゲームにおいて大きな課題とされている「同期とり」がかなり楽になる。
　一例としてこんなことを考えてみよう。あるオンラインRPGでプレイヤーが衣服などといった装備品をデザインしてキャラクターに着せたとする。そのオリジナル衣服を着たプレイヤーキャラクターは，そのままだと別のプレイヤーからは見えない。現状のオンラインゲームが取っている方式でこれを行う場合，ランタイムが当該オリジナル衣服のジオメトリデータやテクスチャデータをサーバーにアップロードすることになる。そして別のプレイヤーのランタイムは，当該オリジナル衣服を着たキャラクターが画面内に入ってきたとき，オリジナル衣服の関連データをサーバーからダウンロードして描画をすることになる。
　上記の例を現状のオンラインゲームでやろうとすると，クライアント側のオリジナルデータをサーバー経由で同期させなければならなくなる。だから，こういったことを行おうとするオンラインゲームは「Second Life」くらいしか存在しないのである。

　システムによってはクライアント同士が直接通信して，データをやりとりしているようなものもあるが，その場合は，サーバー・クライアント間通信だけでなく複数クライアント間通信も同時に発生するため，冗長性は拡大してしまう。

　そういった問題が，統合ゲームサーバーならばまったくなくなると橋本氏は強調している。付け加えるなら，新しいマップが提供されても，それをクライアント側でいちいちダウンロードする必要がなくなったり，クライアントやランタイムのバージョンアップをいちいち行わなくてもよくなったりという副次的なメリットもあるのだ。

クラウドゲーム時代にはゲームスタジオが

ゲームプラットフォームを設計する

　橋本氏はまた，今後のクラウドゲームが持つ可能性についても語っている。

橋本氏が示した，クラウドゲームにおける今後の展開可能性

　遅延は小さくできるといってもなくすのは困難だ。なので，「遅延が大きくなるとプレイヤー側の不快度が如実に増すユーザーインタフェース部分だけはクライアント側で描画して実行させる必要があるだろう」（橋本氏）。

　氏は，レンダリングされたゲームグラフィックスのビデオストリーム化にも工夫の余地があるとしている。それは，ゲームグラフィックスを，あらかじめビデオストリーム化する前提でレンダリングしてしまうことだ。
　たとえば背景は低ビットレート，あるいは低フレームレートでビデオストリーム出力し，メインキャラクターや敵キャラクターだけを高ビットレート，ハイフレームレートでビデオストリーム出力するのだ。それらをプレイヤーの端末側にあるビデオプロセッサで，フレームレート変換しつつ合成まで行う。いうなればLoD（Level of Detail）の考え方を，ビデオストリームの工程にも応用してやるわけだ。こうすればネット帯域幅も削減でき，ひいては操作時の遅延までもが低減できるという理屈である。

　そして，橋本氏による指摘のなかでも最も重要だと筆者が感じたのが，ゲームエンジンそのもののクラウド対応だ。
　ここでいう「ゲームエンジン」とは，「Unreal Engine」ようなミドルウェア的なものよりも，もっと広い概念を指している。むしろ「ゲームプラットフォームのクラウド化」と言い換えたほうが分かりやすいかもしれない。

　現在のところ，ゲームを開発するときには，「PS3用にしよう」「ニンテンドー3DS用にしよう」といった感じで，ターゲットプラットフォームをまず決定する必要がある。それに対してクラウドゲームであれば，ゲームスタジオ側は，クラウド設備への投資は必要である一方，プレイヤーが所持しているゲームプラットフォーム（＝ハードウェア）を気にしなくていい。
　そして，ターゲットプラットフォームを選択しなくてよくなれば，ターゲットのプレイヤー数は格段に広がる。ネットワーク接続機能と最低限の映像表示機構，そしてゲームをプレイするための入力インタフェースを持つハードウェアなら，どんなものでもゲームをプレイできるようになるからだ。現在は，PS3やXbox 360用のタイトルをニンテンドー3DS用に移植しようとしたら大変な労力が必要になるが，クラウドゲームなら，ハイエンドPC用となる，極めてシェーダリッチなゲームであったとしても，片手持ちできるスマートフォンのようなハードウェアでプレイできるようになる。このインパクトは大きい。

　もちろん，ゲームスタジオ側はクライアント端末側のフロントエンド部分，入力インタフェースなどの最適化を個別に行う必要は出てくるだろうが，プラットフォームごとにゲームを設計したりチューニングしたりするのに比べれば，開発規模はぐっと小さくなる。大した問題にはならないだろう。

　付け加えるなら，こうした「ゲームエンジンのクラウド化」という概念を拡大解釈すると，ゲームスタジオ側はゲームを設計するときに自由なハードウェア構成を決められるということにもなってくる。
　クラウドゲームサーバー側のハードウェアをリッチなものにすれば，ハイエンドのグラフィックス品質でゲームが提供できる。また，それなりに低スペックなクラウドゲーサーバーでカジュアルゲームを提供するという選択が可能になるのだ。

　これまで，家庭用ゲーム機は短くて5年，長ければ（まさに今世代がそうだが）8年もハードウェア仕様が変わらないものだった。そうなると，動かせるゲームのスペックがハードウェアに縛られて固定化されてしまうことが否めない。
　クラウドゲームであれば，新しいプロセッサが出るたびにサーバー側をスペックアップしていけるので，いうなれば動的にゲームハードウェアのスペックを向上させられる。クラウドゲーム時代のオンラインRPGは，メジャーバージョンアップ時にクラウドゲームサーバー側のハードウェアも更新されて，グラフィックスや物理シミュレーションエンジン，AIなどが一気に一世代ジャンプするというのも不可能な話ではなくなるのだ。

　こうした論調の究極系が「ゲーム機はなくなる」に結びつくのだろうが，短期的にそこまでいかなくても，クラウドゲーミング環境の実現に，NVIDIAがかなり本気であることだけは間違いない。