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

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

本連載では以前にも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社単独で仕様を決定し、ライブラリ等も実装できるため、過去との互換性よりも新技術の採用に積極的でした。

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

この風向きが変ってきたのは、スマートフォンに代表される携帯端末の普及からです。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に代わる新たな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)へと展開し、現在に至っています。

Linuxと3Dグラフィックス

さて、前節では3Dグラフィックス技術の進化を概観したものの、Linuxはその中でどのような位置にいたのでしょう?

当初からGUI OSとして開発されてきたMS Windowsは、GDI(Graphic Device Interface)のような機能をシステムの中核に据え、急速に高機能化するビデオカードにもD3Dなどの技術で積極的に対応し、Windows Vistaのころからはユーザーインターフェイスも3D化する(Windows Aero)など、グラフィックス回りに関してはLinuxよりもずいぶん進んでいました。

Linuxは、元々UNIX互換OS(POSIX)のカーネルとして開発されたため、GUIについては「X Window Systemが使えればいいな」程度にしか考えておらず、カーネルレベルでのグラフィックス技術への対応はなかなか進みませんでした。

状況が変わってきたのは、ビデオカードが急速に高機能化していく90年代末ごろからです。開発が80年代に始まったX Window Systemは、⁠ビデオカードは画面データを映像信号に変換するだけの機器」という設計だったため、自前で演算能力を持つようになったGPUを制御できません。

そのためLinuxやXサーバの開発者たちは、DRI(Direct Rendering Infrastracture)という設計を提唱し、ユーザアプリケーションがXサーバやカーネルを経由してGPUを直接制御できるような仕組みを開発しました。

その後、DRIは2度の改訂を受けてDRI3となり、カーネル内部のDRM(Direct Rendering Manager)とそれを操作するためのライブラリであるlibdrmと共に開発が続いています。

GPUを直接操作するDRM機能の開発にはGPUの技術情報が必須なものの、最近はこれらの開発にIntelやAMDの技術者が積極的に関わり、最新のGPUも利用可能になっています。

さて、前節で紹介したOpenGLは標準規格なものの、Khronos Groupが提供しているのは3Dグラフィックスに必要な機能とその機能を果すための関数名だけで、実際にGPUを操作してその機能を実現するためのライブラリの実装はGPUメーカ等に任されています。

IntelやAMD、NVIDIAといったメーカは、それぞれ自社のGPU用のドライバを作成し、Windows用だけでなくLinux用も公開してはいるものの、それらは特定のディストリビューションやカーネルバージョンに依存していて、使い勝手はあまりよくありません。

一方、このOpenGLの機能をOSSとして実装しよう、というプロジェクトも古くから存在します。それがMesaプロジェクトで、OpenGLの規格が策定された最初期から、その機能を実装したライブラリをOSSとして公開しています。

図2 Mesaプロジェクトのホームページ
図2 Mesaプロジェクトのホームページ

このMesaプロジェクトにもIntelやAMDの技術者が参加して、GPUの最新機能がいち早く利用できるようになりました。加えて最近では、OpenGLのみならず、組込み環境向けのOpenGL ESや次世代APIのVulkanGPUをより汎用的な用途に使うためのOpenCLGPUの持つ動画のエンコード/デコード機能を使うためのVA-API/VDPAUなどにも対応し、MesaプロジェクトはGPUを利用するための総合ライブラリに発展しています。

長くWindowsの後塵を拝していたLinuxの3Dグラフィックス機能も、DRIとMesaライブラリのおかげでWindowsに遜色ない程度に進化しました。さて、それではこれらの機能をWINEがどのように使うのか、次回から紹介していくことにしましょう。

おすすめ記事

記事・ニュース一覧