- Apple M1/M2 GPU向けのカーネルグラフィックスドライバーは、Rustベースという特徴に加え、OpenGL 4.6とVulkan 1.3の適合性まで達成し、標準サポートの幅を広げた
- OpenGL 4.0の中核であるテッセレーションは、Apple GPUのハードウェア機能だけでは標準を満たすのが難しく、MicrosoftのリファレンステッセレータをOpenCL Cへ移植してGPU上で実行する方式で対応した
- M2 MacのVulkanデモでは、OpenCLベースのテッセレーションが265fpsを記録し、ソフトウェア専用実装の1fps未満より大幅に高速だったが、ハードウェアテッセレータの820fpsには及ばなかった
- AAAゲームの実行では、DirectX・Windows・x86・4KBページ環境を、Linux・Arm64・16KBページベースのApple Siliconに適合させる必要があり、そのため複数の変換レイヤーと仮想マシン構成が併用されている
- Portal、The Witcher 3、Cyberpunk 2077といったゲームが実際に動作したが、メモリ要件とray tracing対応範囲は依然として重要な制約として残っている
OpenGL 4.6に到達したApple GPUドライバー
- Apple M1/M2 GPU向けのカーネルグラフィックスドライバーはRustで書かれており、複数のグラフィックス標準に対する適合性を達成している
- Alyssa RosenzweigはX.Org Developers Conference 2024で、ドライバーの状況と対応可能なゲームを更新した
- 前年のXDCではドライバーはOpenGL ES 3.1適合性を達成しており、その後OpenGL 4.6適合性にまで到達した
- OpenGL 4.0に必要なテッセレーション)は、シーンのディテールを動的に増減させる技法である
Apple GPUハードウェアテッセレータの限界
- Apple GPUにはハードウェアテッセレータがあるが、OpenGL標準実装に必要な機能が欠けており、ドライバーはそのまま利用できない
- ハードウェアはpoint modeとisolineをサポートしていないようで、この2つの機能はエミュレーション可能である
- より大きな問題はtransform feedbackとgeometry shaderである
- ハードウェアはどちらもサポートしない
- ドライバーはこれらをcompute shaderでエミュレーションする
- ハードウェアテッセレータとエミュレーションでテッセレーションアルゴリズムが異なるため、invarianceの失敗を引き起こす可能性があり、この組み合わせは避ける必要がある
- AppleはOpenGL 4.1をサポートしているが適合性は備えておらず、ハードウェアがサポートしない機能はソフトウェアで置き換えている
- RosenzweigはMetalを実装するわけではないため、そのような方式は取らないと述べた
OpenCL Cへ移植したリファレンステッセレータ
- ドライバーはMicrosoftが10年以上前に公開したリファレンステッセレータを活用している
- 元々は、ハードウェアベンダーがテッセレーション導入時に実装すべき動作を示すためのコードである
- 約2000行のC++コードで、単一のpatchをテッセレーションする
- GPUドライバー上で2000行のC++をそのまま実行できないため、このコードをOpenCL Cへ移植した
- OpenCL Cは通常のCPU向けCに非常に近いが、GPU向けの制約と拡張がある
- 目標はコードを完全に理解することではなく、移植中に動作を壊さないことだった
- CPUテッセレータは一度に1つのpatchしか処理しないが、シーンには10,000個のpatchが存在しうる
- GPUの大規模な並列性を活用し、複数スレッドがテッセレーションを実行する
- 並列処理中の出力バッファ割り当てはGPUのatomic命令で管理する
- テッセレータの出力は、GPUが要求するpacked data structure形式のdraw命令として描画しなければならない
- 通常、CのドライバーコードではGenXML toolが生成した関数がこれを処理する
- テッセレータはOpenCLのおかげでCコード形式なので、生成された関数をGPU上で実行されるコードに組み込める
テッセレーション性能
- OpenCLベースのテッセレーションは、M2 MacでVulkanデモのterrain tessellationを実行するために使われている
- 性能比較は次のとおり
- ソフトウェア専用のterrain tessellation: 1fps未満
- OpenCLベースのテッセレーション: 265fps
- ハードウェアテッセレータを接続して測定した値: 820fps
- RosenzweigはOpenCL方式の性能を「悪くない」と評価しており、実際のゲームではボトルネックになる可能性は低いと見ている
- ドライバー性能にはまだ改善の余地がある
Vulkan 1.3とHoneykrisp
- Honeykrisp M1/M2 GPUドライバーはVulkan 1.3適合性を達成した
- 出発点はNVK Vulkan driver for NVIDIA GPUsをコピーし、OpenGL 4.6ドライバーと組み合わせた形だった
- 約1か月で適合性テストスイートを通過し始めた
- その時点は発表時点から6か月前だった
- その後、次の機能が追加された
- geometry shader
- tessellation shader
- transform feedback
- shader object
- 現在のドライバーは、複数のDirectXバージョンに必要なすべての機能をサポートしている
AAAゲーム実行のための変換レイヤー
- Apple Silicon環境でAAAゲームを実行するには、複数の環境差を同時に扱う必要がある
- ゲームの対象環境: DirectX、Windows、x86 CPU、4KBページ
- 実際の対象ハードウェア: Linux、Arm64、16KBページベースのApple Silicon
- DirectXからVulkanへの変換と、WindowsからLinuxへの実行はそれぞれDXVKとWineが担う
- x86からArm64への変換には、FEX-EmuやBox64のような既存の選択肢がある
- 最大の障害はページサイズの違いである
- FEX-Emuは4KBページを要求する
- Box64には16KBページを使うハックがあるが、Wineでは動作せず、ここでは役に立たない
- macOSはx86エミュレーションに4KBページを使えるが、非常に侵襲的なカーネルサポートが必要である
- Asahi Linuxはすでにメインラインカーネルに向けた約1000個のパッチを抱えており、Linuxメモリマネージャを書き直すアプローチは現実的ではない
4KBゲストカーネルVM構成
- Linuxは異なるプロセス間での異種ページサイズをサポートしないが、異なるカーネル間では可能であり、これは仮想化で処理される
- KVMゲストカーネルはホストカーネルと異なるページサイズを持てる
- FEX-Emu、Wine、DXVK、Honeykrisp、Steam、ゲーム全体を4KBゲストカーネルを実行する仮想マシンに入れる構成が使われている
- CPUオーバーヘッドはハードウェア仮想化により低いと予想され、実際の負荷は周辺機器側にある
- Honeykrispはホストカーネルではなく、ゲスト内でvirtgpu native contextsを通じて動作する
- 最終的なGPU command bufferを作る処理はゲスト内で行われる
- 各Vulkan呼び出しが仮想マシン境界をまたぐのではなく、完成したcommand bufferがホストへ渡される
- ホスト側のVirGL rendererがそれをGPUへ渡す
- Rosenzweigは、この方式は100%ネイティブ速度ではないが、90%を確実に超えると述べた
- CPUとGPUのオーバーヘッドは並列に実行されるため、コストは相互に加算されない
実際に動作したゲームと公開状況
- この構成では実際に複数のゲームが動作している
- Portal
- Portal 2
- Castle Crashers
- The Witcher 3
- Fallout 4
- Control
- Ghostrunner
- Cyberpunk 2077
- 関連コンポーネントは、発表当日の10月10日に公開された
- Fedora Asahi Remixユーザーは、すぐに更新してそれらのコンポーネントを入手できる
- 発表中のSteam起動は、仮想マシンとx86エミュレーションのため時間がかかり、その後ControlはM1 MAXシステムで45fpsで動作した
メモリとray tracingの制約
- 8GB RAMのMacでも一部のゲームは動作可能である
- Rosenzweigはカンファレンス中に8GBシステムでCastle Crashersをプレイした
- Portalも8GBシステムで動作する
- 高度なゲームタイトルは、16GB以上のシステムでのみ動作する可能性が高い
- Rosenzweigは、時間の経過とともに必要なリソースが減ることを期待している
- ray tracing対応は高い優先順位ではない
- Controlではこの機能を利用できる
- Appleハードウェアでray tracingをサポートするのはM3以降のみである
- 現在のドライバーはM1およびM2 GPU向けである
- Rosenzweigは近いうちにM3対応作業を始める予定である
1件のコメント
Hacker News の意見
M1/M2 対応を最後まで完成させようとする献身ぶりは本当に尊敬に値する
ピカピカの新しいレイトレーシングのおもちゃが出た途端に捨てられるプロジェクトがあまりにも多いが、こういう作業はドキュメント不足のハードウェアのせいで苦痛を伴う一方、動いたときの見返りは大きい
私の M1 もこのプロジェクトと Alyssa の OpenGL+ES 作業が理由で買ったもので、Asahi Linux しか起動していない
こうしたデバイスは長く使えるように作られており、Apple 自身と Linux コミュニティによる長期サポートは称賛に値する
オープンソースなので Apple も見ている可能性が高く、記事ではチップに欠けている機能を回避する作業にも触れていた
20年以上コーディングしてきたが、キャリアで最も幸せだった瞬間と最も落ち込んだ瞬間は、どちらもたった4か月参加したハードウェアプロジェクトから生まれた
4KB と 16KB のページサイズ差を解決するためにすべてを仮想マシン上で動かす Alyssa のやり方は、賢いハックである一方、潜在的な性能ボトルネックのようにも感じる
こうした回避策が長期的に何を意味するのか気になる
閉じたエコシステムとして設計されたプロプライエタリなハードウェアの隙間を埋める複雑さが、利益を上回る地点に達しているのではないか
M1 MAX でオープンソースドライバにより Control が 45fps で動くのは励みになるが、コミュニティが閉じたシステムをさらに開くために大きなリソースを投入し続けるべきなのか、それともよりオープンなハードウェア標準を推進すべきなのか疑問だ
Apple はテッセレーションシェーダーのような標準機能を難しくする GPU の制約や非標準のページサイズによって、開発者に不要な障害を作っており、こうした閉じたエコシステムはオープンソース貢献者を苦しめるだけでなく、すべてのユーザーに利益をもたらすはずのイノベーションも抑え込んでいる
それが閉鎖的なビジネスモデルを支えているのは明らかで、実際 Apple には非常にうまく機能している
優れたハードウェアを作っており、最近のソフトウェアがやや不安定だとしても、普通のユーザーはハードウェアとソフトウェアの組み合わせから概して良い体験を得ている
したがって Apple が今のようにハードウェアを設計しているからといって、開発者に「不要な障害」を置いているわけではなく、単に自社の必要に合わせたハードウェア設計に集中しているだけだ
それに、ハードウェアが優れていなければ、Apple が意図しない形で使おうとする関心もここまで大きくはならなかったはずだ
標準を無視してより良い車輪を再発明することと、互換性を阻むために意図的に標準から外れることには、かなり大きな違いがある
標準の動作を維持するためにリソースを使っていないのか、標準から外れるために積極的にリソースを使っているのかが核心で、前者なら個人的には責めることではないと思う
このエコシステムの中で Apple が主に気にするのは、ネイティブアプリ互換性と似た水準の AI 推論体験だろうが、どちらも時には共同の取り組みで解決されているように見える
それ以外については可能な限りロックダウンするほうを好み、コミュニティは残念ながら優れたオープンな取り組みよりも全体的な魅力に引かれがちだ
両方やればいい
最初は、Alyssa は Valve で働きながら Mac の Linux 上で Steam が動くよう支援すべきだと言おうとしたが、すでにそうしているようだ [1]
[1] https://en.wikipedia.org/wiki/Alyssa_Rosenzweig#Career
Valve がここで何を計画しているのか、かなり興味深い疑問が生まれる
難しいだろうが、Mac で Steam/Proton を動かすのは Valve にとって非常に理にかなっており、人々がゲームのために Mac で Linux を起動するようになれば、Apple はおそらくかなり苛立つだろう
Alyssa R と Asahi Lina の仕事は素晴らしい
ただしドライバコードに慣れていないと、この内容の大半は本当に難解で、ハードウェア側にはあまりに特異な部分が多いので、こうしたコードをもっとずっと簡単に書けるようになればいいのにと思う
魔女の衣装のようなオールドスクールな遊び心もかなり楽しく見た
これができる既知のハードウェアがあるのか気になる
検索してみたが、PowerPoint 関連のブログスパムの中で望む結果を見つけるのは難しく、Google の AI も役に立たなかった
ハードウェアに欠けているものがこれほど多く、これほど多くの部分がエミュレーションされているという事実に驚いた人はほかにもいるだろうか
事実上、すべてエミュレーションと見なせる
GPU メーカーがドライバをオープンソースで公開しようとしない理由の一つも、秘密のソースのかなりの部分が大規模並列計算アーキテクチャ上のドライバソフトウェアで起きているからだ
ジオメトリシェーダーはそもそも標準化されるべきではなかった失敗だと広く見なされており、Metal はまったくサポートしたこともないため、macOS の古い OpenGL コードでしか出てこないはずで、Apple がこれをハードウェアでサポートしないことを責めるのは難しい
https://x.com/pointinpolygon/status/1270695113967181827
Alyssa はすごい
GPU 関連の取り組みについての最初の記事を覚えているが、その後、彼女がまだ17歳だと知って頭が爆発しそうな気分になった
誰であれそんなことを成し遂げたこと自体が驚きなのに、まして10代がやったというのは本当に衝撃的だ
最新の OpenGL と Vulkan を Apple Silicon に持ってくることが、いずれにせよエミュレーション層なしには不可能なのだとしたら、理論上は Linux 向けのネイティブ Metal APIを作れるのだろうか
それとも Metal は macOS SDK に深く組み込まれすぎているのだろうか
MoltenVK も Alyssa が発表で述べていたのと同じ問題を解こうとしている [1、issue の最後のコメントは Alyssa のもの]
[1] https://github.com/KhronosGroup/MoltenVK/issues/1524
これが実質的に Alyssa Rosenzweig の発表の結論だった
Apple は内部ドキュメントを把握しているので、より優れた低レベル実装を作るには最も有利な立場にいる
今の主な障害は、Metal への移植だけが公式にサポートされた経路だという頑固な姿勢だ
Valve が Apple のサポートなしに AAA ゲームを Mac で動かす魔女の秘術のような方法を引き出せば、面白い展開になるだろうし、Apple が自社プラットフォーム上で追い込まれたくないなら、アプローチを見直させることになるかもしれない
Linux 向けの DirectX 実装もあるし、Proton もそのように動作している
ただ、その API を Vulkan の上のレイヤーとして作るのか、MoltenVK や dxvk のように完全にクライアント側で処理するのか、それとも Mesa により深く統合するのかが問題だ
最初に始めるには前者のほうが確実に簡単そうだ
こういうタイトルの記事を見ると、「サポートを終了して acqui-hire されます」みたいな内容だろうと期待するように訓練されてしまった
Alyssa Rosenzweig は Turing Award を受ける資格がある
こういう /SubscriberLink/ リンクはいつも気になっていた
共有するのは非倫理的なのだろうか
個人メール、プロジェクトのメーリングリストのメッセージ、ブログ記事はいずれも適切で、購読者獲得の試みを迂回する手段として使わない限り、共有されることを歓迎しているという
ただし、サイトと執筆者、編集者を運営していく必要があるので、あまり過度に広めないでほしいと丁寧に頼んでいて、その財源は私の理解では購読料だけだ
LWN の購読料はかなり手の届く水準で、Linux と関連トピックについて最高の深掘り技術報道を支えている
LWN とは関係なく、満足している購読者にすぎないが、LWN の記事から得た知識は自分のキャリア上の成功にも一部貢献したと思っている
人々が購読するには、まず LWN の存在を知る必要がある
FAQ を見ればよい: https://lwn.net/op/FAQ.lwn#slinks
LWN のペイウォールは独特で、すべてのコンテンツが1週間後に無料公開される
購読者リンクは、余裕があれば購読を促すためにあるものだ
間違っているかもしれないが、以前は有料だったコンテンツを、おそらく記事単位で公開するための資金が付いているように読める
実際にそうなのか知っている人がいるのか気になる