続・玩式草子 ―戯れせんとや生まれけん―

第32回 Days of WINE and Struggles again[1]

この記事を読むのに必要な時間:およそ 3 分

本連載では以前にもWINEについて取りあげたことがあります。その際は全くゼロからのスタートだったため,64ビット専用になっているPlamo-7.x上に32ビット用のビルド環境を整備するところから始め,一応,WINEは動作するようになったものの,3Dグラフィックスを多用した最近のゲームは動かないなぁ……というところで終了していました。

一方,WINEのアプリケーションDBを見ると,最近のゲームの多くが特に問題なく動いているようなので,Plamo側で解決すべき問題もありそうだ……と気になっていたこともあり,この夏休みに久しぶりにWINEと戯れてみました。

前回挑戦したころのWINEは4.1xから5.0くらいだったのに対し,現在のWINEは6.1xくらいまで更新されています。また,OpenGL回りの機能を提供するMesaや新しい3Dグラフィックス用APIのVulkanもずいぶんバージョンが更新されました。はたして,これら新しい環境を使えば,PlamoでもWindowsのゲームが動作するのでしょうか?

3DグラフィックスのためのAPI

WINEの具体的な話に入る前に,最近のWindowsのゲームを動作させる際に必要となる3Dグラフィックス回りの技術を整理しておきましょう。

筆者の世代では,PC互換機の映像出力用パーツは「ビデオカード」と呼称していました。一方,最近の高性能なGPUを載せたカードは「グラフィックボード(グラボ⁠⁠」とも呼ばれています。この呼称の違いが示すように,映像出力用パーツの役割も,CPUが作成した画像データを映像信号用に変換して出力するだけの機能から,GPUを使って3Dデータを演算処理し,自前で画像データを生成して出力できるまでに進化しました。

この進化を導いたのが,OpenGLと呼ばれる3Dグラフィックスの技術規格です。OpenGLは,CG作成を得意とする「グラフィックス・ワークステーション」で知られたシリコン・グラフィックス社(Silicon Graphics Inc.)が,自社のワークステーション用に開発したライブラリ(IRIS GL)を元に機能を整理して,3Dグラフィックスを作成,操作するためのAPIとして公開したものです。

図1 OpenGLの実行例

図1 OpenGLの実行例

1992年に最初のバージョンが公開されたOpenGLは,当時のUNIXワークステーションメーカに広く支持され,ワークステーションの分野では「業界標準」として普及していきました。

一方,90年代になるとPC互換機の性能が急速に向上し,PC互換機でも3Dグラフィックスを扱いたい,というニーズが生じてきます。Windowsでこの分野を支配していたMicrosoft社も,当初はワークステーション寄りのWindows NTでOpenGLを採用したものの,仕様の規模が大きいOpenGLには個人ユーザにとって不要な機能が多い,と考えて,OpenGLのサブセット的な仕様を持つDirect3D(D3D)を開発し,ゲームやマルチメディア向け機能をまとめたDirectXの一部としてWindows 95に組み込みました。

OpenGLは,3Dグラフィックスの性能を上げるため,それぞれの機能を専用のハードウェアで実現しやすい設計になっていて,⁠OpenGL対応」をうたうビデオカードの出現を促しました。その流れはD3Dにも受けつがれ,多くのビデオカードメーカが,3Dグラフィックス用の機能を組み込んだビデオカードを開発,販売し,3D性能の高さを競うようになりました。それに伴い,OpenGLやD3Dの仕様も改訂されていき,ソフトとハードの両輪から3Dグラフィックスの技術が急速に進歩していきました。

OpenGLは「業界標準」であるため,さまざまな企業の代表者が集まったOpenGL Architecture Review Board(ARB)という組織が規格を策定しています。そのため,過去との互換性を重視し,新機能に関しても各企業の思惑に配慮した仕様になりがちなのに対し,D3DはMicrosoft社単独で仕様を決定し,ライブラリ等も実装できるため,過去との互換性よりも新技術の採用に積極的でした。

OpenGL ARBは,2006年に非営利の標準化団体クロノス・グループ(Khronos Group)の傘下となり,以後のOpenGLの仕様はKhronos Group名義で公開されています。

何よりも"Windows native"に開発されていることから,Windowsが支配するデスクトップPC上のゲームや3Dグラフィックス作成といった分野はほぼD3Dとそれを含むDirectXが支配するようになって行きました。

Microsoftが開発しているゲーム機XBoxも,中身はDirectXの実行に特化したWindows機です。

この風向きが変ってきたのは,スマートフォンに代表される携帯端末の普及からです。iOSを開発しているAppleも,Androidを開発しているGoogleも,3Dグラフィックス用のAPIにMicrosoftが支配するD3Dは使わず,OpenGLのサブセットとして組み込み機器向けに開発されたOpenGL ES(Embedded System)を採用しました。

デスクトップPCの市場規模がワークステーションを上回ったように,携帯端末の市場規模はデスクトップPCを上回っています。その結果,スマホを含めたマルチプラットフォームで動くアプリを開発したい企業は,OpenGLにもDirectXにも対応する必要が生じ,ゲームエンジンなどもDirectXとOpenGL双方に対応するようになってきました。

一方,3Dグラフィックスがアクションゲームなどに普及して行くにつれ,OpenGLやD3Dの弱点も目立つようになってきました。

OpenGLやD3Dは3Dグラフィックスをいかに生成,操作するかに着目したAPIで,実際にGPUを操作して処理を実現するのはより下層のドライバ任せです。加えて,バージョンアップによってAPIが高機能になってゆくにつれ,GPUとの間に何層もの処理がはさまり,オーバーヘッドが増加しました。そのため,GPUメーカや3Dのアクションゲームを開発している業界などから,レスポンスを良くするために,GPUなどのハードウェアを直接操作するような機能を求める声があがり始めました。

OpenGLやD3Dの開発が始まった当時は,さまざまなビデオカードメーカがそれぞれに特徴を持ったビデオカードを提供していたため,ハードウェアレベルで対応するのが困難だったのに対し,最近ではGPUメーカも限られてきて,提供する機能もほぼ同等になってきたので,対応がしやすくなった,という事情もあるようです。

そこでOpenGLに代わる新たなAPIとしてAppleが提案したのがMetalAMDが提案したのがMantleで,両者ともOpenGLの経験を踏まえつつ,CPUとGPUを統合的に扱えるような,よりハードウェアよりの機能を提供しています。

Appleは,従来採用していたOpenGLを非推奨として,Metalへの置き換えを進めているようです。一方,Mantleは,Khronos Groupが計画していた「次世代のOpenGL」に採用され,Vulkanという名称で規格化されて,Androidがいち早く採用を表明しました。

また,Microsoftも最新のD3D12では,従来の設計方針を大きく変更し,MetalやVulkan同様,GPUを直接操作できるようなAPIを追加して迎え撃とうとしています。

このように,グラフィックス・ワークステーションから始まった3Dグラフィックスの技術は,UNIXワークステーションからデスクトップPC,さらには携帯端末へと対象を広げつつ,高機能で重いAPI(OpenGL/D3D11)とハードウェアに近い低レベルなAPI(Metal/Vulkan/D3D12)へと展開し,現在に至っています。

「ハードウェアに近い低レベルなAPI」と言うと簡単そうに聞こえるものの,従来はドライバがよきに計らってくれていたレベルの処理すら自前で用意する必要があるため,プログラミングはより大変になります。OpenGLでも三角形1つ画面に描くだけに100行を超えるコードを必要とするのに,これらのAPIを使うとどうなるかはちょっと想像したくありません。⁠苦笑

著者プロフィール

こじまみつひろ

Plamo Linuxとりまとめ役。もともとは人類学的にハッカー文化を研究しようとしていたものの,いつの間にかミイラ取りがミイラになってOSSの世界にどっぷりと漬かってしまいました。最近は田舎に隠棲して半農半自営な生活をしながらソフトウェアと戯れています。

URLhttp://www.linet.gr.jp/~kojima/Plamo/index.html