M1で互換性のあるOpenGL 4.6サポート

OpenGL 4.6 および OpenGL® ES 3.2 サポート

• M1は長らくOpenGL 4.1のみをサポートしていたが、現在はOpenGL® 4.6およびOpenGL® ES 3.2を完全にサポートしている。
• 最新のM1/M2シリーズ向けドライバのためにFedoraをインストールすればよい。
• すでにインストール済みの場合は、単に dnf upgrade --refresh コマンドでアップグレードできる。
• 既存ベンダーの非標準な4.1ドライバとは異なり、これらのオープンソースLinuxドライバは最新のOpenGLバージョンに合わせて認証されており、Blender、Ryujinx、CitraのようなモダンなOpenGLワークロードとの幅広い互換性を約束する。

ドライバ認証と標準サポート

• 認証済みの4.6/3.2ドライバは、正確性を保証するために100,000件以上のテストに合格する必要がある。
• 公式に認証されたドライバ一覧に、OpenGL 4.6およびES 3.2が新たに含まれた。
• ベンダーは依然としてモダンなOpenGLのようなグラフィックス標準をサポートしていないが、この会社はサポートしている。
• この会社は、相互運用可能なオープン標準への愛着を公に表明し、ユーザーと開発者が特別なポートなしに望む場所でアプリケーションを実行できる自由を提供したいとしている。

OpenGL 4.6の新機能

• OpenGL 4.6は4.1と比べて数十の必須機能を追加している:
  • Robustness（堅牢性）
  • SPIR-V
  • Clip control
  • Cull distance
  • Compute shaders
  • Upgraded transform feedback

M1とグラフィックス標準の互換性問題

• M1はOpenGL ES 3.1より新しいグラフィックス標準にはあまり適していない。
• Vulkanは一部の機能をオプション化しているが、DirectXやOpenGL向けのレイヤーには必要な機能が欠けている。
• M1では、OpenGL 4.1の機能セットを超える既存ソリューションが存在しない。

4.1の壁を越える方法

• ハードウェアサポートなしで新機能を実装するには、新しい方法が必要になる。
• ジオメトリシェーダー、テッセレーション、トランスフォームフィードバックはコンピュートシェーダーで置き換えられる。
• Cull distanceは変換された補間値で置き換えられる。
• Clip controlは頂点シェーダーのエピローグで置き換えられる。

堅牢性の課題

• 伝統的にGPUは安全性より生の性能を優先してきた。
• Webブラウザのようなアプリケーションでは、このようなトレードオフは望ましくない。
• 堅牢性機能は、シェーダーでバッファ範囲外アクセスが発生した場合にアプリケーションで定義された動作を選べるようにすることで、性能をわずかに犠牲にしつつ攻撃面を減らせる。

バッファ堅牢性

• 他のAPIでは、堅牢性が有効なときにバッファ範囲外ロードが何を返すかの定義が異なる。
• OpenGLでは、範囲外ロードはバッファの最後の要素を返す。
• 堅牢性のための追加演算はシェーダーのプリアンブルへ移されるため、メインシェーダーにはコストがかからない。

画像堅牢性

• 画像堅牢性では、範囲外の画像ロードが0を返すことが求められる。
• M1 GPUでは、ミップされた画像ロードが失敗する単一のテストがある。
• 堅牢性のための回避策としては、無効なレベルでロードしないか、推測的にロードしたうえで比較および選択演算を使う方法がある。

GN⁺の意見

• この記事は、M1デバイスで最新のOpenGL標準をサポートする重要な進展を扱っている。これはLinuxユーザーや開発者に、より広い互換性と性能向上をもたらすだろう。
• OpenGL 4.6の新機能は、グラフィックスアプリケーションの性能と堅牢性を大きく向上させる可能性があり、特にゲーム開発や高性能コンピューティング分野で重要である。
• この記事は、オープンソースドライバが商用ソリューションと比べて、いかに優れた標準準拠と互換性を提供できるかを示す好例である。

[GN⁺]

Hacker Newsのコメント

• Alyssa Rosenzweigはコミュニティに継続的に貢献している人物で、彼女のブログ記事を読むと、現代のグラフィックスハードウェアの内部について知らなかったことを学べる。このような努力は、言葉より実力が重要であることを証明しており、ブログを読むだけでも多くのことを考えさせられる。重要なメッセージは最後の文ではなく2番目の文にあり、読者はウサギの穴に落ちてビット操作の世界を楽しむことになる。
• M1チップはOpenGL ES 3.1より新しいグラフィックス標準にはあまり適しておらず、Vulkanでは一部の機能を選択的に使えるものの、DirectXやOpenGL向けのレイヤリングに必要な機能が欠けている。M1ではOpenGL 4.1の機能セットを超える解決策はないように見える。このことによる性能への影響、特にmacOSのMetalと比べてどうなのかが気になる。
• グラフィックスプログラミングで、境界外アクセスをトラップからランダムデータの返却へ切り替えることを「ロバスト」と呼ぶのは面白いと思う。
• いつかAppleはOpenGL 3.3 coreを廃止し、その結果みんなもそれを捨てることになるかもしれない。一般にはOpenGLのほうがVulkanより使いやすいと言われるが、複雑すぎると経験の浅い開発者にとってGPU活用の障壁になり得て、それによって一部のインディーゲーム開発者を落胆させるかもしれない。UnityやUnrealを使うのが一般的だが、最初からゲームを作ることは奇異に見られる。オープンソースのゲーム開発の現状は、ときに非常に絶望的に感じられ、次世代グラフィックスAPIの登場は状況をさらに難しくしている。
• これはM1チップ向けFedoraに関する話であり、macOSでこれを実現できたら驚くべきことだろう。これを達成するためにどんな作業が必要なのか気になる。
• なぜ最初からVulkanをターゲットにしないのか気になる。最近ではVulkanのほうがより重要な対象に見えるし、すでにOpenGL実装も存在する。
• 4.1の壁をどう突破するのか。ハードウェア支援なしで新機能を実装するには新しい方法が必要だ。ジオメトリシェーダー、テッセレーション、トランスフォームフィードバックはコンピュートシェーダーで、cull distanceは変換済みの補間値で、clip controlは頂点シェーダーのエピローグで実装される。こうした作業がM1 GPUコード内でどこまで行われているのか、また他の機能を使った機能実装がどの程度再利用できるのかが気になる。
• またひとつおすすめしたい記事で、もっと知識と忍耐があれば文脈の中でよりよく理解したいと思う別の記事でもある。それでもAlyssaの文章は楽しく読める。
• 3DゲームにOpenGLが使われた唯一の理由が、90年代のQuake IIのためにJohn Carmackがそれに執着していたからだという事実は、なんとも狂っている。