OpenGL ES 適合性認証を受けた初の M1 GPU ドライバー
(rosenzweig.io)- M1・M2 系 GPU で OpenGL ES 3.1 アプリケーションを標準どおり実行できる Linux 向けドライバーが提供された
- Asahi Linux のリバースエンジニアリングに基づく無料・オープンソースドライバーは、M1・M2 グラフィックスハードウェア上で Khronos 適合性テストに合格した唯一の OpenGL ES 3.1 実装
- 認証は公式テストの合格と Khronos への提出、30日間のレビュー期間を経て行われ、M1、M1 Pro/Max/Ultra、M2、M2 Pro/Max の項目が登録された
- OpenGL ES 3.1 は、6月の実験的な OpenGL ES 3.0・OpenGL 3.1 対応を更新し、コンピュートシェーダーと画像アトミック操作を追加する
- M1 には画像アトミック操作専用命令がないためアドレス計算で回避していたが、その後 ビットインターリーブ命令を見つけ、10個の命令を1個に削減した
M1・M2 向け OpenGL ES 3.1 適合性認証
- M1・M2 系 GPU 向けの OpenGL ES 3.1 適合性認証済みドライバーが提供された
- OpenGL ES 3.1 アプリケーションと互換性がある
- Linux をインストールして利用できる
- 既存の Asahi Linux ユーザーは、ディストリビューション別のアップグレードコマンドで最新ドライバーを入手できる
- Fedora:
dnf upgrade - Arch:
pacman -Syu
- Fedora:
- リバースエンジニアリングに基づく無料・オープンソースのグラフィックスドライバーは asahi/mesa で公開されている
- このドライバーは、M1・M2 系グラフィックスハードウェアにおける世界で唯一の OpenGL ES 3.1 適合性認証実装
- 数万件のテストに合格し、正確性を証明した
- 業界標準団体の認定を受けている
Khronos の手続きと登録されたチップ系列
- 適合性認証を受けるには、実装が公式の 適合性テストスイートに合格する必要がある
- テストスイートは仕様の全機能を検証するよう設計されている
- テスト結果は標準化団体 Khronos に提出される
- 30日間のレビュー期間中に問題がなければ、適合性認証実装となる
- Khronos のウェブサイトには、次のドライバーが適合性認証実装として登録されている
- 今回の成果は OpenGL ES だけにとどまらない
- M1 向けグラフィックス標準全体で初の 適合性認証実装にあたる
メーカー製ドライバーと標準 API の隔たり
- メーカーの M1 ドライバーは、Vulkan、OpenGL、OpenGL ES を含むどの標準グラフィックス API でも 適合性認証を受けていない
- Linux を使わない M1・M2 環境では、標準ベースのアプリケーションが動作する保証はない
- Vulkan の事例では、MoltenVK がプロプライエタリドライバー上に Vulkan の一部をレイヤー化している
- そのプロプライエタリドライバーには中核機能が欠けている
- 正当な Vulkan アプリケーションが壊れる可能性がある
- M1・M2 コンピューターを Linux に切り替えていない開発者とユーザーの双方にとって障害となる
- Asahi Linux ドライバー開発は、標準ソフトウェアが M1 専用のハックや移植なしに動作することを目指している
- プロプライエタリドライバー、プロプライエタリ API、標準実装の拒否に満足していない
- 仕様に沿った オープン標準実装をエコシステムの望ましい方向と見ている
OpenGL ES 3.1 の主な追加機能
- OpenGL ES 3.1 は、6月に提供された実験的な OpenGL ES 3.0 および OpenGL 3.1 対応を更新する
- 主な追加機能は コンピュートシェーダー
- グラフィックスアプリケーション内で一般計算を高速化するために主に使われる
- 3D ゲームは物理シミュレーションをコンピュートシェーダーで実行できる
- シミュレーション結果をレンダリングに直接使えば、GPU と CPU の物理シミュレーション間の同期によって生じる停止を減らせる
- その結果、ゲームをより高速に実行できる可能性がある
画像アトミック操作が必要な理由
- OpenGL ES の以前のバージョンは、アプリケーションが画面表示のために画像を読み取れるようにしていた
- ES 3.1 は、アプリケーションが通常コンピュートシェーダーで 画像へ書き込みできるようにする
- 画像処理アルゴリズムを固定機能の 3D パイプラインに合わせる制約が減る
- GPU は数千のスレッドを同時に実行する大規模並列構造
- 2つのスレッドが同じ位置に書き込むと、実行順序によって結果が変わる
- この状況が 競合状態
- アトミックなメモリアクセスは競合状態を扱う基本的な解決策
- メモリサブシステムの特殊ハードウェアが、選択された操作についてスレッド順序に関係なく一貫した結果を保証する
- 最新のグラフィックスハードウェアは加算など複数のアトミック操作をサポートする
- OpenGL ES 拡張 OES_shader_image_atomic は、画像ピクセルに対するアトミック操作を追加する
- この拡張は ES 3.2 で必須
- たとえばコンピュートシェーダーがピクセル
(10, 20)の値をアトミックに増加させられる
M1 で画像アトミック操作を実装した方法
- 他の GPU は画像アトミック操作専用命令を提供しており、ドライバー実装が単純になる
- M1 には 画像アトミック操作専用ハードウェア命令がない
- 非画像アトミック操作はある
- 非アトミック画像機能もある
- そのためピクセルにアトミック操作を直接行わず、ピクセルのメモリアドレスを計算したうえで、そのアドレスに通常のアトミック操作を実行する
- 画像が線形にメモリ配置されていれば、アドレス計算は単純
- Y 座標に1行あたりのバイト数である stride を掛ける
- X 座標にピクセルあたりのバイト数を掛ける
- 2つの値を足して、最初のピクセルを基準にしたバイトオフセットを求める
- 最初のピクセルのアドレスにオフセットを加えて最終アドレスを得る
- 実際の画像は通常、線形には配置されない
- 現代のグラフィックスハードウェアはキャッシュ効率を高めるために X・Y 座標をインターリーブする
- メモリ上のピクセル配置は行単位ではなく、螺旋に近い曲線に従う
ビットインターリーブ最適化と隠れた命令の探索
- X・Y 座標をインターリーブする際、1ビットずつマスクしてシフトする方式は非効率
- よく知られた ビット操作アルゴリズム は、ビットグループを混ぜることで問題を並列化する
- シェーダーコードでこのアルゴリズムを実装すると性能が向上する
- 実際には各座標の下位7ビット以下だけがインターリーブされる
- X・Y 座標を 32ビットレジスタの下位・上位 16ビットに入れ、32ビット命令で同時に処理できる
- 命令数を半分に減らせる
- GPU の shift-and-add 結合命令も活用する
- これらの手法を組み合わせると、M1 GPU アセンブリの10個の命令でインターリーブを実行できた
- その後、専用の ビットインターリーブ命令の可能性を検討した
- PowerVR には
shflシャッフル命令がある - M1 GPU には PowerVR 由来の要素があるため、類似命令が存在する可能性を検討した
- プロプライエタリコンパイラがテストシェーダーのコンパイル時にその命令を使わなかったため、コンパイル結果の観察だけではリバースエンジニアリングが難しかった
- PowerVR には
推測と検証で確認したインターリーブ命令
- Dougall Johnson は、既知の命令エンコーディングをもとに候補を推定した
- ビット反転命令には操作を指定する2ビットフィールドがあり、値は
01- セットされたビット数を数える命令は
10 - 最初にセットされたビットを見つける命令は
11 - 既知の複雑なビット操作命令はこの3つの値を使う
- セットされたビット数を数える命令は
- 残る値
00は観測されていない未知の値- インターリーブ命令が存在するなら、ビット反転命令に似ているがオペコードが
00である可能性を検討した
- インターリーブ命令が存在するなら、ビット反転命令に似ているがオペコードが
- 3つの既知命令は入力ソースが1つだけだが、インターリーブ命令には2つのソースが必要
- M1 GPU 命令は通常、ソース位置を一貫してエンコードする
- 2ソース算術命令で第2ソースがある位置に空き領域があり、その位置を第2ソースと推定した
- 検証は、コンパイラを修正して乗算のような2ソース整数演算を、推定したインターリーブエンコーディングに置き換える方法で進められた
- コンピュートシェーダーでその演算を使用する
- テスト シェーダー は、可能な各入力について未知の命令がインターリーブ結果を返すか確認する
- 命令は2つの 16ビットソースを受け取るため、入力は約40億通りある
- M1 GPU はドライバーの新しいコンピュート対応により、全入力を1秒未満で確認した
- 最終的に、10命令のベクトル化アセンブリを 1個のインターリーブ命令に置き換えた
- この方式は高速で、適合性テストにも合格する
1件のコメント
Hacker News の意見
Apple が OpenUSD のレンダリング／アニメーション／CAD／3D シーン形式をめぐって nVidia、Adobe、Autodesk、Microsoft などと協力しているので、OpenGL・Vulkan 対応が改善するのか気になる
OpenUSD の核心が「どこでも一貫してレンダリングされる単一のファイル形式」だとすれば、Apple がより多くの 3D ソフトウェア企業を macOS に呼び込む手段として使う可能性がある
今後 Apple には、映画・ゲーム制作パイプラインで力を持つ既存の OpenGL/Vulkan 標準に従うか、逆に Metal をさらに強く推し進めて世界を Metal + macOS へ引っ張っていくか、二つの道がありそうだ
気持ちとしては前者を望むが、直感では Apple は後者を全力で推進しそうだし、Apple だけでなく nVidia、Autodesk、Adobe、Microsoft も自分たちが管理していない標準を好まない傾向がある
iMac と初期の OS X は USB、JPEG、MPEG、mp3、PostScript、内蔵 TCP/IP、.rtf のような標準を大きく打ち出し、Jobs もそれを強調していた
その後、崖っぷちから回復するにつれて再び「価値の追加」を始め、iPhone も当初は独占的でひどかった Flash や未成熟な「モバイル HTML」ではなく、HTML デバイスだと強調していた
今でも市場支配力が弱い領域では、H.264 や Matter/Thread のような自分たちが管理していない標準をサポートしている
ハードウェアとソフトウェアを強く結び付け、意図したユーザー体験を作るため、その体験が他者に左右されないよう、ある程度コントロール可能な標準を実装しようとする立場は理解できる
USB-C のように、まだ方向性が固まっていない業界標準も、先に動けば方向に影響を与えられるため Apple が採用することがある
Adobe、Autodesk、Blender などの大半は OS ごとに異なるバックエンドをすでにサポートしており、macOS では Metal も含まれる
OpenGL は古すぎるし、良いドライバを使うのも悪夢に近く、高性能なアプリケーションコードを書くことさえ難しいので、残念だとは思わない
ただ Metal を作るより Vulkan を推してくれればよかったとは思うが、Linux 以外では Vulkan は概して二級市民に近い。それでもターゲットにするにはかなり悪くない二級市民だ
ゲームや Steam 対応の観点では、多くのゲームは API 処理をエンジンに任せており、API を直接扱う余力のあるチームなら、非常に最先端の機能を使わない限り MoltenVK でも問題ない可能性が高い
生涯クロスプラットフォームのために OpenGL を多用してきたが、グローバルステート、使ってはいけない関数、落とし穴、巨大な拡張ヘッダー、難しいデバッグのせいで本当にひどい API だった。Vulkan は冗長だが、多くの面でむしろ簡単だ
ただ、今使っている Mac は USB-C ポートだけで、複数の周辺機器や大きなモニターに標準プロトコルで接続できている
全体として Apple は標準が十分ならオープン標準を好むように見える。USB2 では Lightning が担っていた多くのことができなかった時代には Lightning を作ったが、USB-C が出ると Mac と iPad にはすぐ取り入れ、iPhone では残念ながらぐずぐずしている
Asahi と Alyssa はリバースエンジニアリングの巨人であり、彼らの仕事は信じられないほどだ
Apple が彼らを採用しようとした、あるいはすでに試みたが断られた可能性が高いと思う
Apple より Valve のほうが、この能力を事業として活用する理由が大きいとも言える
普通、従業員は自分が生み出す利益に比べて報酬が低く、IT では特にそうだ
才能ある人は法人を設立して正当な価格でサービスを売るほうがよいが、一部の国では大企業が政府にロビー活動をして、こうした道を塞いでしまっている
アトミック演算のトリックがとても満足感のあるもので、PowerVR 系譜からスウィズル命令を推論したことも特に印象的だ
Apple のエンジニアたちもここから学ぶか、少なくともその賢さを高く評価すると思う
以前 Accolade で Sega Genesis のビデオハードウェアをリバースエンジニアリングした際、エンジニアたちが公開されていた Texas Instruments TMS9918 VDP 文書を出発点に、Genesis（Mega Drive）の 9918 派生 VDP を推論した出来事を思い出す
明確にしておくと、これは最初の適合認証済み Linux ドライバというだけではなく、もっと大きな意味がある
Apple 自身も OpenGL ES 3.1 に適合していないため、これはどの OS においても M シリーズ向けとして文字通り初めての適合認証済み OpenGL ES 3.1 ドライバだ
だからチームへの寄付を求める声が出ている
https://asahilinux.org/support/
そういう選択肢があるならどこでできるのか知りたいし、なければ後でそのリンクをそのまま使うつもりだ
今では推奨されなくなった macOS OpenGLアプリをデバッグしてみると、この問題は非常にはっきりする
抽象化レイヤーが実際のOpenGL状態を、以前のApple OpenGLデバッガが読み取れる形で公開していないため
OpenGLが内部的にMetal上で動作していなかった古いmacOSが入った旧型Macがない限り、標準のデバッガではmacOS上のOpenGLを事実上デバッグできない
デバッガかアプリがそのままクラッシュする
これは主にゲームには役立つが、ディープラーニングにはあまり役立たないように見える
Mac M1の最も魅力的な点は大容量メモリで、複数カードに分散できないため学習には微妙かもしれないが、Stable DiffusionやLLaMAのような大規模モデルの推論エンジンとしては良い
SYCLはKhronos Groupのベンダー中立な高水準プログラミングフレームワークだが、アプリケーション対応は限定的で、Intelの支援で徐々に良くなることを期待している
Vulkan Computeはコンピュートシェーダーで問題を迂回するが、アプリケーション対応状況はよく分からない
SYCLはOpenCLとOpenCLのSPIR-V拡張の上に実装できるが、強いベンダーロックインのため、この経路はIntelとMesa以外ではおおむね放棄されており、現在はROCm、HIP、CUDAのような各GPUベンダーAPI向けバックエンドとして実装されることが多い
Metalに同じ方式を適用するのは非常に難しいはずで、MesaにはIntelとAMDGPU向けのOpenCL+SPIR-V実験的サポートがあり、理論上はApple Siliconへ拡張できるが、現在Apple SiliconのOpenCLはまったくサポートされておらず、ロードマップ上にある程度だった
ディープラーニングを動かすには CUDA、ROCm、MPS のようなバックエンドが必要
大きなCUDAサーバーでPyTorchモデルを学習し、MacBook Airで推論を走らせるのは比較的簡単だった
ただしeilnが Apple Neural Engine ドライバを書いて、GPUではなく専用ハードウェアを使えるようにしており、今後linux-asahiにマージされる予定
Asahi Linaともう一人が最小限の資金で大企業に勝ったという表現は格好いいが、実際には勝ったというより、Appleが気にかけていなかったことに近い
Appleはそもそもその競争に参加していなかった
「最小限の資金で2人が大企業に勝った」という婉曲表現が良い
これはAppleにとって明らかに恥ずかしいことで、Appleは標準や準拠に関心がなく、人々が自分たちだけの閉じた庭に閉じ込められることを望んでいる
iOS開発者でなければ、とっくにAppleエコシステムを離れていたはず
ハードウェアは好きだし、80〜90年代のAppleのように創造性と人間中心を掲げていたブランドも好きだったが、今の会社はポリティカル・コレクトネスなマーケティング動画の裏で、強欲に腐っているように見える
前回のアップグレード時に代替を探したが、Appleから離れるには終わりのない妥協を受け入れる必要があった
iPhoneの代わりに素のAndroidと長期サポートを期待してPixelを見たが、バッテリー問題の話が絶えず、ソフトウェアの完成度やアプリエコシステム、安定性も障害になる
標準モデルの MacBook Air M1 のビルド品質、バッテリー、安定性に近いコスパの製品も見つけにくかった
iPadで漫画や雑誌も読んでいるが、タブレット市場は何年も代替が何なのか分からないし、Apple Watchは捨てられるかもしれないが、単にちゃんと動き、サードパーティ製アクセサリが豊富だ
もはや新しいROMを毎日焼いて試す時代は過ぎ、安定性と使いやすさではAppleに勝つのは難しそうで残念
みんなの仕事が安全でいられる唯一の理由は、その2人が誰なのかを誰も正確に突き止められないから
Appleは自社でシリコンを作り、プラットフォーム全体を構築したのに、他のOSを実行できるように残しておいたことが単なるミスだったとは考えにくい
サードパーティ開発のために意識的に扉を開けておいたのは明らかなのに、Appleを非難する雰囲気は残念だ
例えば継続的な Vulkan実装 を支援するには相当なリソースとリリーススケジュール上の負担が伴うので、ビジネス上の理由が必要になる
「恥を避けるため」では十分でない可能性が高い
コミュニティへの善意という論理はあり得るが、Appleを「ポリティカル・コレクトネスなマーケティング動画の裏で強欲に腐った会社」と呼ぶ人たちの好感を追いかけるとは思えない
適合性テストはオープンソースではなく、GitHubにある別の「conformance suite」はGoogleのdEQPベースであって、Khronos内部のテスト群ではない
実装にかなり大きなバグや穴があっても「標準互換認証」を受けられる
AppleはOpenGL 3.1のサポートだけを約束しており、M1向けOpenGLドライバも既存アプリが動き続けるようMetal上のエミュレーションレイヤーとして書き直したが、より新しいバージョンのOpenGLを実装するつもりはなく、その必要もない
Appleに対する批判は多く、Metal APIとツールをより良くする余地も大きいが、OpenGLを気にかけないのは、ここでは十分に合理的な判断だ
原文に「Apple」という単語が一度も出てこず、「メーカー」と「大企業」とだけ表現しているのが興味深い
意図的なら法的理由なのか気になる
関心はAppleではなく M1/M2アーキテクチャ でLinuxをきちんと動かすことであり、相手がMicrosoft、Amazon、Googleだったとしても同じように扱ったはず
このドライバの開発過程を見せるライブ配信を見るのは面白く、本当に驚くべき作業だった
これまで見た中でも最も驚くべき低レベルプログラミング作業の一つ