- macOS 向け OBS Studio 32.0.0 から、Apple Metal ベースのレンダラーバックエンドが実験的に追加され、従来の OpenGL と比べて性能と効率の向上を目指している
- Metal は 低オーバーヘッドと現代的な GPU アーキテクチャの反映のために設計された API であり、OBS はこれをサポートするために GPU との相互作用の方法を根本的に見直した
- OBS の既存レンダラーは Direct3D 中心の構造に合わせて作られていたため、Metal バックエンドではシェーダー変換やリソース管理などで 大規模な互換対応が行われた
- とくに HLSL シェーダーを MSL にリアルタイム変換し、Direct3D の
map/unmap 動作を Metal 内部でシミュレーションする複雑な実装が含まれる
- Metal バックエンドはまだ 「実験的」段階だが、OpenGL より高速な性能と Swift ベースの安全なコード構造、EDR プレビュー対応などにより、macOS 開発環境の改善に向けた重要な転換点となっている
Metal レンダラー導入の概要
- OBS Studio 32.0.0 から、macOS で Metal グラフィックス API ベースのレンダラーを実験的に提供
- 従来の OpenGL バックエンドの代替として、性能と効率性の向上を目標とする
- Metal は GPU との相互作用の方法を根本から変える現代的な API であり、OBS はこれに合わせて内部構造を調整した
- Metal バックエンドは 「Experimental」 と表示されており、いくつかの既知の問題と制限がある
- OpenGL レンダラーは引き続きデフォルトとして維持され、ユーザーは Metal 版を自分で試せる
- Metal に経験のある開発者からの フィードバックおよび Pull Request への参加を推奨
Metal の背景と設計思想
- Apple は 2014 年に iPhone 向けとして Metal を初公開し、2015 年に Mac へ拡張した
- 当時の Metal は Intel、AMD、NVIDIA GPU のすべてをサポートした最初期の次世代グラフィックス API の 1 つだった
- Metal は AMD の Mantle と既存の OpenGL・Direct3D の概念を組み合わせつつ、レガシー要素を取り除いて新たに設計された
- Objective-C と Swift ベースの APIとして、iOS・macOS 開発者になじみやすい構造を提供
- Xcode 内で シェーダーデバッグや GPU 分析機能を統合的にサポート
API 設計の違いと OBS レンダラーの適応
- 従来の OpenGL・Direct3D は リソース管理と同期を API が自動処理していたが、
Metal などの現代的 API では開発者が直接管理しなければならない
- 新しい API は GPU を 並列コマンドキューベースの処理装置として扱い、パイプライン状態を不変オブジェクトとして管理する
- OBS の既存レンダラーは Direct3D 方式に合わせて設計されていたため、
Metal 対応のために バックエンドレベルで互換レイヤーを実装した
OBS レンダラーの構造と Metal 互換の問題
- OBS はプラットフォームごとに Direct3D (Windows)、OpenGL (Linux/macOS) バックエンドを使用
- レンダラーコアは API 非依存だが、一部に Direct3D 中心の前提が存在する
- 主な制約事項
- シェーダーが HLSL ベースで書かれているため、実行時に変換が必要
- グローバル変数の使用、逐次実行の前提、Direct3D 式のテクスチャ処理 など
- プレビュー描画が DXGI の「discard model」に依存
シェーダー変換 (Transpiling Shaders)
- OBS のエフェクトファイルは HLSL で記述されており、各 API に合わせて変換される
- Metal 対応のために HLSL → MSL 変換器が追加された
- 主な違い
- MSL では 入出力構造体を分離する必要があり、グローバル変数をサポートしない
- すべての uniform データは GPU バッファとして渡され、関数引数として明示的に渡す必要がある
- 関数呼び出し時の 型一致とシグネチャ検証が厳格
- 変換器はランタイムでシェーダーコードを 部分的に書き換え、MSL の規則に合わせる
- 例として、HLSL の
uniform 変数を MSL の constant buffer に変換
int3 → uint2 + uint 変換などの 型変換ロジックを自動挿入
Direct3D 動作のシミュレーション
- OBS レンダラーは Direct3D の
map/unmap 動作を前提に設計されている
- Metal はこのような自動同期を提供しないため、バックエンド側で直接実装した
- Metal バックエンドでの処理方式
- 書き込み時には GPU バッファを作成し、CPU メモリと 直接共有する
unmap 時には GPU ブリット (blit) 命令を予約し、テクスチャへコピーする- 読み取り時にも GPU バッファを共有するが、明示的な同期で競合を防ぐ
- 結果として、Direct3D の リソース追跡および同期機能を Metal 内部で再現している
プレビュー描画の問題と暫定対応
- macOS の Metal Layer は DXGI と異なり、アプリが任意にフレームを表示することはできない
- システムが ProMotion と低電力モードに応じてフレームレートを制御する
- OBS は独自のレンダーループと macOS の表示周期が一致せず、プレビュー遅延が発生した
- 暫定的な解決策
- OBS がまず 仮想テクスチャにレンダリングし、別スレッドがそれを 画面 Surface にコピーする
- この過程で GPU 同期が必要となり、フレーム不一致の可能性がある
- macOS 14 以降では ウィンドウごとの独立タイマーにより、さらに課題が増える見込み
現代グラフィックス API の隠れたコスト
- Metal バックエンドの開発には 数か月にわたる研究と設計の反復が必要だった
- OpenGL→Vulkan、D3D11→D3D12 への移行時に性能低下が起こる理由を実証している
- 現代的な API では、ドライバーが行っていた作業を アプリケーションが直接担う必要がある
- GPU の動作原理とコマンド依存関係への 深い理解が必要
- Metal バックエンドは一部のオーバーヘッドを再導入したが、次のような利点がある
- OpenGL と同等かそれ以上の性能
- シェーダー・テクスチャデバッグなどの強力な解析機能
- Swift ベースの安全なコード構造
- EDR プレビュー対応により高品質な映像処理が可能
- Xcode 統合の解析機能により macOS 版 OBS の保守効率が向上し、
今後 Metal をデフォルトレンダラーへ切り替えるための開発者フィードバックを求めている
1件のコメント
Hacker Newsのコメント
本当に良い記事だった。シェーダー処理方式の説明がとても印象的だった
サードパーティ製プラグインのシェーダーを複数のバックエンドで動かすには本当にああした工程が必要なのか、それとも後方互換性の維持のためにそうなっているのか気になった
外部開発者に「すべてのシェーダー言語でそれぞれ書いてくれ」と求めるのはコアチームにとっては簡単でも、現実的には望ましくない
みんな非効率だとは思っているが、現実的に代替手段がない
記事タイトルが要点を隠している
「OBS Studioが新しいレンダラーを導入: Metal採用の過程」くらいに変えるべきだ
これは明らかにAppleがVulkanではなく自社エコシステム保護用のAPIを作った代償を示している
OBS Studioは2020年3月、バージョン25.0でVulkan対応を追加した。もう5年半が経つ
組み込み環境では依然としてOpenGL ESが中心だ
私はこのテーマの専門家ではない。読んだ内容の5%くらいしか理解できなかったが、こういう技術的な細部を説明する記事がもっと増えてほしい
単なる発表文はマーケティングのように感じる
個人的には今後のVST3対応の方が楽しみだが、今回の話題も歓迎したい
Rockchip SoCでハードウェアエンコーディングを設定するよりずっと簡単だ
MetalがDirect3Dのオブジェクト指向アプローチを一歩進めて、Objective-CとSwiftの「おしゃべりな」API設計を組み合わせたという説明が興味深かった
OSレベルの3DグラフィックスAPIがここまで動的言語ベースで作られうることに驚いた
これは
objc_msgSend()の最適化のおかげだと思うVulkan/Metal/DirectX 12は個別呼び出しの代わりにコマンドバッファへ複数の命令を詰めて渡す
2000年代初頭にはDirect3DをC#で使う本があり、GC言語でも高性能グラフィックスが可能だという認識を変えた
要点は、事前確保したバッファを参照するバッチ処理構造によってランタイムオーバーヘッドを最小化することだ
Cocoa以降は大半が制限されたC++サブセット（例: IOKit）で書かれている
私は現代のGPU APIが、もっと単純な何かへ向かう過渡的な段階であってほしいと思う
OpenGLには愛憎入り混じった感情があるが、新しいAPI群を使った後ではむしろOpenGLの単純さが恋しくなった
Metalが旧型のIntel Macでも性能を改善するのか、それともMシリーズ専用の最適化なのか気になる
ただしMetal 3自体は依然として複数のIntel Macでもサポートされているので、なぜ制限したのかは疑問だ
Mac Miniで配信用マシンを組もうと考えていた
今回の性能向上で十分現実的になるのか気になる
2Dアーケードゲームや開発画面程度なら問題ない
最新のAAAゲームならキャプチャカードでPC画面を取り込む方がよい
2017年ごろはmacOSでの配信は厳しかったが、今ならMシリーズで十分だ
今回の改善で効率がさらに高まることを期待している
Appleには、Metalの外部での成功事例を増やすためにもっと多くのリソースを投入してほしい
MetalはApple内部を除けば、まだ大きな成功を収めていない