お気に入りタイトル/ワード

タイトル/ワード名(記事数)

最近記事を読んだタイトル/ワード

タイトル/ワード名(記事数)

LINEで4Gamerアカウントを登録
ValveはなぜSource EngineをLinux+OpenGL環境へ移植したのか。GTC 2013のValveセッションレポート
特集記事一覧
注目のレビュー
注目のムービー

メディアパートナー

印刷2013/03/23 00:00

ニュース

ValveはなぜSource EngineをLinux+OpenGL環境へ移植したのか。GTC 2013のValveセッションレポート

画像集#002のサムネイル/ValveはなぜSource EngineをLinux+OpenGL環境へ移植したのか。GTC 2013のValveセッションレポート
 2012年8月。Left 4 DeadシリーズやPortalシリーズなどで知られるValveは,同社の公式blogに興味深いエントリをポストして,コミュニティを賑わせた。その内容は要約すると,同じハードウェア構成のPCで,Windows版とLinux版の「Left 4 Dead 2」を実行したところ,Linux版のほうが約20%も高い性能を示したというもの。その事実はもとより,「Source Engine」にLinux版が存在し,開発されていたことに,コミュニティは驚いたのだ。

 NVIDIAの主催するGPU技術会議「GPU Technology Conference 2013」(以下,GTC 2013)では,この「Linux版Source Engine開発秘話」を取りあげたセッション「Porting Source to Linux: Valve's Lessons Learned」(SourceのLinux移植:Valveが学んだ教訓)があったので,興味深い業界動向も交えてレポートしてみよう。


なぜValveはSource EngineをLinuxへ移植したのか


Mike Sartain氏(Software Engineer, Valve)
画像集#003のサムネイル/ValveはなぜSource EngineをLinux+OpenGL環境へ移植したのか。GTC 2013のValveセッションレポート
 冒頭で説明なしに名前を出したが,Source EngineというのはValveが有するゲームエンジンだ。採用ゲームタイトルとして最も著名なのは,いまだと「Portal 2」か「Team Fortress 2」ということになるだろう。もともとはValveの看板タイトル「Half-Life 2」用のゲームエンジンだったため,“Half-Life 2 Engine”などと呼ばれることもあったが,正式名称ははじめからSource Engineだ。

 さて,このSource EngineをValveがLinuxへ移植したというのは,PCゲーマー,とくにWindowsベースのゲーマーからすると,突飛なことに思えるかもしれない。PCゲーム環境の標準がWindowsであることは疑いようがなく,かたやLinuxは,Mac OSよりもマイナーな存在だからだ。

 では,なぜ,移植作業に踏み切ったのだろうか。これには当然のことながらいくつか理由がある。

PCゲーム市場として中国は無視できない存在となってきているという
画像集#004のサムネイル/ValveはなぜSource EngineをLinux+OpenGL環境へ移植したのか。GTC 2013のValveセッションレポート
 セッションを担当したValveのソフトウェアエンジニア,Mike Sartain氏によれば,その1つは,PCゲーム市場として大きな割合を占めている中国のユーザーに配慮するためのとのことだった。
 中国のPCゲーマーは,その多くがWindows XP搭載機を走らせており,その割に搭載ハードウェアは最新世代に近くなっている。Windows XPだと,DirectX 9.0c(Shader Model 3.0)までしかサポートされず,GPU側がDirectX 10以降に対応していても,その機能は利用できないわけだ。

 しかしこの問題は,OpenGLを使えば解決する。OpenGLドライバなら,Windows XP環境であっても,最新世代のGPUが持つ機能を利用できるのだ。

Windows XPとDirectX 10世代以降に対応したGPUを組み合わせているユーザーが,使っているGPUの全機能を利用できるようにするには,OpenGLが有効
画像集#005のサムネイル/ValveはなぜSource EngineをLinux+OpenGL環境へ移植したのか。GTC 2013のValveセッションレポート 画像集#006のサムネイル/ValveはなぜSource EngineをLinux+OpenGL環境へ移植したのか。GTC 2013のValveセッションレポート

 「なら,Source EngineのWindows用DirectX版を,Windows用OpenGL版に移植するだけでいいのでは?」という疑問が当然のように出てくると思う。実は,この疑問に対する答えが,GTC 2013で,ちょうとValveのセッションの後に実施されたセッションにあった。NVIDIAのソフトウェアエンジニア,James Dolan氏による「Bringing PC and Console Games to Mobile: Tips and Tricks from the Trenches」(PCおよび据え置き機のゲームをモバイルへ:現場からのアドバイス)がそれだ。

James Dolan氏(Senior Software Engineer, NVIDIA)
画像集#007のサムネイル/ValveはなぜSource EngineをLinux+OpenGL環境へ移植したのか。GTC 2013のValveセッションレポート
 いま,ゲーム市場で急成長しているプラットフォームといえば,それはモバイルだ。もっといえばAndroid端末市場である。
 Androidの世界には7億5000万のアクティブユーザーがいるのだが,この数字は,現行世代の家庭用ゲーム機ユーザーの約10倍。市場規模も,2012年時点で300億ドル規模に達しており,2013年はさらに拡大すると見込まれている。

 もちろん,Android端末向けのゲームが,いずれも先端技術を駆使した素晴らしいエンターテイメント体験を提供してくれているかというと,「YES」とは即答できない。多くのタイトルは暇つぶしレベルの内容に留まっている。ただ,Androidの世界では,“暇つぶしゲーム”が一段落した後,高度なインタラクティブ映像メディアとしての(ビデオ)ゲームも望まれていくはずで,ゲームビジネス関係者は,そちらにも意識を向け始めているという状況なのだ。
 NVIDIAが提案する「Project SHIELD」は,まさにここへ向けたハードウェアソリューションである。

スマートフォン向けゲーム市場は成長の一途にある
画像集#008のサムネイル/ValveはなぜSource EngineをLinux+OpenGL環境へ移植したのか。GTC 2013のValveセッションレポート

 とはいえ,PC向けのゲームエンジンをAndroid環境へ直接持って行こうとすると,超えるべきハードルが高すぎる。そこで「まずはLinux+OpenGL環境へ移植してみよう」というのが,Dolan氏によるセッションの内容だった。

「スマートフォン向けに既存のゲームエンジンや大作ゲームを移植したいなら,まずはLinux+OpenGLへ移植してみよう」とDolan氏は呼びかける
画像集#009のサムネイル/ValveはなぜSource EngineをLinux+OpenGL環境へ移植したのか。GTC 2013のValveセッションレポート
Linux環境とAndroidなどのスマートフォンの開発環境は同じではないが,共通点は多いとDolan氏は主張していた
画像集#010のサムネイル/ValveはなぜSource EngineをLinux+OpenGL環境へ移植したのか。GTC 2013のValveセッションレポート 画像集#011のサムネイル/ValveはなぜSource EngineをLinux+OpenGL環境へ移植したのか。GTC 2013のValveセッションレポート 画像集#012のサムネイル/ValveはなぜSource EngineをLinux+OpenGL環境へ移植したのか。GTC 2013のValveセッションレポート

 Sartain氏はセッション中,一言も「Source EngineのAndroidプラットフォーム移植」については触れなかったが,業界のトレンドを踏まえるに,Valveは,Source EngineのLinux+OpenGL移植を完了したあとは,Android環境(あるいはiOS環境)への移植を考えているのかもしれない。


ゲームのプログラムコードをなるべく活かす方向で進められたエンジン移植


 Windows+DirectXからLinux+OpenGLへの移植作業では,さまざまな困難があったと,Sartain氏は振り返っている。
 マイナーながら重要な点として取りあげられたのはファイルシステムだ。大文字小文字を区別するLinuxと,区別しないWindowsでは,意外に面倒な問題となったという。文字フォントや多言語対応,多画面対応,マウスカーソル&キーボード制御は,Windows環境のほうが洗練されており,Linux環境ではすべてValveが自前で処理する必要があったために大変だったという。

 CPUパフォーマンスツールはRAD Game Toolsの「Telemerty」が便利だったそうだ。Telemetryは,現行の主要な家庭用ゲーム機やWindows,Mac,Linuxを網羅的にサポートしており,今回のような異なるプラットフォームへの移植ではかなり有効だったとのことである。

画像集#013のサムネイル/ValveはなぜSource EngineをLinux+OpenGL環境へ移植したのか。GTC 2013のValveセッションレポート
Telemetryはマルチプラットフォーム対応のパフォーマンス解析ツール
画像集#014のサムネイル/ValveはなぜSource EngineをLinux+OpenGL環境へ移植したのか。GTC 2013のValveセッションレポート
「DirectXのAPIバージョン番号引く7」で,対応するOpenGL世代がだいたい分かる

 グラフィックス周りでは,Source Engine自体が,エンジン側のレンダリングエンジンモジュールで抽象化されているため,DirectX(=Direct3D)コールをOpenGLコールに変換するモジュール「togl」を作って対応したという。ちなみにtoglという名称には「OpenGLへ……」の意味が込められているそうだ。

Direct3D環境下で実行されるSource Engineのソフトウェアスタック図
画像集#015のサムネイル/ValveはなぜSource EngineをLinux+OpenGL環境へ移植したのか。GTC 2013のValveセッションレポート
 示されたソフトウェアスタック図上ではソフトウェアのレイヤーが増えているように見えるが,OpenGL自体がかなりドライバレイヤーに近い構造であるため,性能面における負の影響はほとんど無視できたとSartain氏。ちなみに冒頭で紹介した「Left 4 DeadがWindows版よりLinux版のほうが20%高速」という話に出てきた「Linux版」は,toglでレンダリングしたものだとされている。

OpenGL環境下で実行されるSource Engineのソフトウェアスタック図
画像集#016のサムネイル/ValveはなぜSource EngineをLinux+OpenGL環境へ移植したのか。GTC 2013のValveセッションレポート

OpenGLの拡張仕様
画像集#017のサムネイル/ValveはなぜSource EngineをLinux+OpenGL環境へ移植したのか。GTC 2013のValveセッションレポート
 といっても,Direct3DとOpenGLとでは文化背景が違うため,toglの開発はやさしいものではなかったようだ。
 Direct3DがC++前提の世界なのに対してOpenGLはC言語ベースだったり,近年のDirect3Dでは比較的厳格な仕様規定があるのに対して,OpenGLはややその点がゆるかったりという違いがあるため,Direct3DでできることをOpenGLでやろうとすると,NVIDIAやAMD,Appleといった大手メーカーの定める拡張機能(Extensions)へ直接アクセスする必要が出てきたりする。AMD製GPU用のOpenGLドライバが,NVIDIA製GPUのとある拡張機能をサポートしている場合もあれば,サポートされていない場合もあるからだ。

Direct3DとOpenGLの違い
画像集#018のサムネイル/ValveはなぜSource EngineをLinux+OpenGL環境へ移植したのか。GTC 2013のValveセッションレポート 画像集#019のサムネイル/ValveはなぜSource EngineをLinux+OpenGL環境へ移植したのか。GTC 2013のValveセッションレポート

Khronos Groupに参加するゲーム関連企業名一覧(の一部)
画像集#020のサムネイル/ValveはなぜSource EngineをLinux+OpenGL環境へ移植したのか。GTC 2013のValveセッションレポート
 今後は,こうしたDirect3D→OpenGL移植作業というのが増えてくる可能性が高いため,Sartain氏は「何かOpenGLの仕様に不満があれば,OpenGLの規格策定機関であるKhronos Groupに参加すべき」だと述べていた。
 氏によれば,DOOMシリーズの開発元として知られるid SoftwareのJohn Carmack氏が,「垂直同期をとっていたらコマ落ちが起きてしまう」問題対策として,「垂直同期待ちをするが,待っていたらコマ落ちがひどくなりそうなときはテアリング(ティアリング)を許容する」という拡張仕様を,リクエストしてあっという間に実装させたという逸話もあるそうだ。

 また,Direct3DとOpenGLでは,x,y,zの3次元直交座標軸が,前者は左手座標系,後者は右手座標系となっているという違いがあるのは有名な話だが,それよりも根本的な問題としては,「シェーダプログラムをそのままでは流用できない」というのがあるとも,Sartain氏は述べていた。Direct3D用のシェーダプログラム言語は「HLSL」(High Level Shading Language),OpenGLは「GLSL」(OpenGL Shading Language)で,両者は名称がよく似ているのに互換性がない。

 そこでSource Engineの開発チームは,「シェーダコードの短いものはDirect3D用のHLSLプログラムをコンパイルした後に逆アセンブルしてGLSLプログラムとして利用する」というアプローチを採択した。デバッグがしづらくて苦労したそうだが。
 また,それ以外にも,オープンソースのクロスシェーダコンパイラを利用したこともSartain氏は明かしている。これはHLSLプログラムをGLSLプログラムに変換したり,あるいは逆の変換を行ったりするものだ。

シェーダプログラムの移植
画像集#021のサムネイル/ValveはなぜSource EngineをLinux+OpenGL環境へ移植したのか。GTC 2013のValveセッションレポート 画像集#022のサムネイル/ValveはなぜSource EngineをLinux+OpenGL環境へ移植したのか。GTC 2013のValveセッションレポート 画像集#023のサムネイル/ValveはなぜSource EngineをLinux+OpenGL環境へ移植したのか。GTC 2013のValveセッションレポート

 デバッグ作業は決して楽ではなかったが,最終的には,1つのゲームランタイムを動かして,Direct3DとOpenGLの両方でレンダリングし,それらをリアルタイムに比較して差分を取って出力するシステムまで構築できたという。

Direct3DとOpenGLの両方でレンダリングし,それらをリアルタイムに比較するシステム
画像集#024のサムネイル/ValveはなぜSource EngineをLinux+OpenGL環境へ移植したのか。GTC 2013のValveセッションレポート


「OpenGLがテクノロジードライバーとなる時代」に向けて


 OpenGL寄りの業界人の話なので,ある程度バイアスがかかっているものとして受け止める必要があるが,GTC 2013に参加していた,Khronos Groupのある上級メンバーは,「DirectXがテクノロジードライバーだった時代は終わった」と,筆者に対して述べた。

 実際,Windows 8では最新版のDirectX 11.1が統合されているのだが,Windows 7用にDirectX 11.1が提供されるかどうかは未定だ。また,2005年のDirectX 9時代末期にはDirectX 11までのロードマップが示されていたのに対し,DirectX 12の話は2年前から何も出ていない。DirectXの進化する道筋が見えてこないのだ。この不安感を,PCゲーム業界にいる開発者達は敏感に受け止めている。

 前出のKhronos Groupメンバーは,「DirectX(=Direct3D)は,WindowsというOSの根幹部分に吸収され,機能の一部となり,あとは安定動作に進化の焦点を絞って熟成を深めていくだろう」という見方をしていた。
 成長著しいスマートフォン業界や,そのグラフィックス技術を支えるOpenGLファミリー(※スマートフォン向けにはOpenGL ESが提供されている)と,進化の足音が止まったDirectX……。

 ゲームの世界において,OpenGLが主導権を握る可能性があれば,(DirectXを捨てきれないまでも)OpenGLの動向を気にしていこうという機運は,今後も高まり続けるはずである。

Valve公式Webサイト(英語)

GTC公式Webサイト(英語)

  • 関連タイトル:

    OpenGL

  • この記事のURL:
4Gamer.net最新情報
プラットフォーム別新着記事
総合新着記事
企画記事
スペシャルコンテンツ
注目記事ランキング
集計:04月18日〜04月19日