問題タブ [metal]

異なる均一パラメータを持つ異なるオブジェクト間で金属ピクセル シェーダと頂点シェーダを再利用する際に問題が発生しています。コマンドバッファを間違って使用していることと関係があると思います。

金属アプリケーションを実行すると、ジオメトリは正しく描画されますが、最終呼び出しのユニフォームのみが

renderCommand setFragmentBuffer:uniform_info offset:0 atIndex:UNIFORM_INFO_BUFFER_INDEX];

ピクセルシェーダーにデータを書き込むようです。

ここでレンダリング ループをカット アンド ペースト (および編集) しました。異なるユニフォームが渡された単一のレンダー パスでピクセル シェーダーを複数回再利用する方法の例を探しています。

必要に応じてピクセル シェーダーを投稿することもできますが、一度に 1 つのオブジェクトのみをレンダリングするようにコーディングした場合、シェーダーは正しく機能します。

非常に遅く、より高速に実行する必要がある作業中の金属アプリケーションがあります。問題は、作成している MTLCommandBuffer オブジェクトが多すぎることだと思います。

非常に多くの MTLCommandBuffer オブジェクトを作成する理由は、ピクセル シェーダーに異なる均一な値を送信する必要があるためです。以下の問題を説明するために、コードのスニピットを貼り付けました。

上記のコードは期待どおりに描画されますが、非常に遅いです。オブジェクトごとに MTLCommandBuffer を作成するよりも、ピクセル シェーダーの評価を強制するより良い方法があるためだと思います。

1 つのシェーダー パスに必要なサイズよりもはるかに大きなバッファーを単純に割り当て、単純にオフセットを使用して 1 つのレンダリング コマンド エンコーダーで複数の呼び出しをキューに入れ、それらを実行することを検討しました。この方法はかなり異例のようです。オブジェクトごとにカスタム データをメタルに適した方法で送信する必要があるという問題を確実に解決したいと考えています。

呼び出しごとのカスタム ユニフォーム データを使用して、同じピクセル/頂点シェーダーの複数のパスを使用してレンダリングする最速の方法は何ですか?

私は現在、Metalを使用して大規模な iOS 8 アプリをコーディングしています。重要な例がないため、非常に苛立たしいことが証明されており、実際には (設計上) DirectX や OpenGL ES (どちらも私が知っている) とは少し異なります。

現在、単一の頂点/インデックス バッファーを使用し、シェーダーで派手なことを行うチュートリアルしか見つけることができません。頂点が異なる複数のオブジェクトとシェーダー ユニフォームを同じフレームに描画する方法を知りたいです。

Xcode およびデバイスで iOS 8.3 SDK にアップグレードした後。金属に関係するアプリケーションが正しく動作しません。Metal は、obj ファイルの視覚化と GPU コンピューティングに使用されます。アプリケーションが数秒間停止してからクラッシュしました。Xcode コンソールに、以前は表示されなかった "Metal GPU Frame Capture Enabled" が表示されることに気付きました。これは問題の原因ですか？もしそうなら、iOS 8.3 でこの機能をオフにする方法はありますか?

CPU と GPU の両方で (iOS8 Metal 計算パイプラインを使用して) それぞれ 50 文字の 1.000.000 行 (50 mil char マップ) を検索する単純な char 検索アルゴリズムを実装することにより、簡単な実験を行いました。

CPU 実装は単純なループを使用し、Metal 実装は各カーネルに 1 行の処理を与えます (以下のソース コード)。

驚いたことに、Metal の実装は、単純な線形 CPU (1 つのコアを使用する場合) よりも平均で 2 ～ 3 倍遅く、2 つのコア (それぞれがデータベースの半分を検索する場合) を使用する場合は 3 ～ 4 倍遅くなります。グループごとに異なるスレッド (16、32、64、128、512) で実験しましたが、それでも非常によく似た結果が得られました。

iphone 6：

Metal シェーダーがアクセス メモリの 90% 以上を消費していることがわかります (以下を参照)。

それを最適化するために何ができますか？

インターネットには (標準の Apple プログラミング ガイド以外に) 多くの情報源がなく、Metal フレームワークに固有のメモリ アクセスの内部とトレードオフに関する詳細を提供しているため、洞察をいただければ幸いです。

金属実装の詳細:

ホストコードの要点: https://gist.github.com/lukaszmargielewski/0a3b16d4661dd7d7e00d

カーネル (シェーダー) コード: https://gist.github.com/lukaszmargielewski/6b64d06d2d106d110126

GPU フレーム キャプチャ プロファイリングの結果:

Metal を使用して多面体をレンダリングしています。newBufferWithBytes() を使用して頂点がわずか 1680 バイトのデータで構成される正二十面体エンティティをレンダリングしようとすると、問題が発生します。その後、アプリ全体が停止し、CPU と GPU の両方のフレームがゼロになり、Metal ビューのフリーズを除いてすべてが正常に戻りました。

Node のサブクラスとして、通常の多面体を実装しています。

OpenGLでこれを取得しました（短縮コード）

上記のコードは私のエンジンで完全に機能しています。しかし、Metal API に移植することを決めたとき、いくつかの問題が発生しました。インデックス データを使用してモデルの半分をレンダリングするだけで、メッシュにはグループがなく、単純なメッシュです。しかし、頂点データ ( drawPrimitives ) を使用してレンダリングしようとすると、正常にレンダリングされます。

メッシュの初期化とレンダリングに使用している Metal コードは次のとおりです。

この最小限のメタル シェーダー ペアは、頂点の色属性に基づいて、補間されたシンプルなグラデーションを画面にレンダリングします (頂点の四角形/三角形が指定されている場合)。

…次の頂点を持つ:

ここまでは順調ですね。よく知られているグラデーションの三角形/四角形をレンダリングします。
ほとんどすべての GPU HelloWorld チュートリアルで見られるものです。

ただし、補間された頂点の色を取得する代わりに、画面上のフラグメントの位置に基づいて色を計算するフラグメント シェーダーが必要です。画面いっぱいの頂点のクワッドを受け取り、フラグメント シェーダーのみを使用して実際の色を計算します。

私の理解では、頂点の位置はfloat4、最初の 3 つの要素が 3d ベクトルで、4 番目の要素が に設定されてい1.0ます。

では、頂点の位置をフラグメント シェーダーの色として単純に再解釈するように上記を変更するのは簡単だと思いました。

…次の頂点を持つ:

しかし、x 軸と x 軸のグラデーションred=0.0ではなく、均一な色 (黄色) の画面がレンダリングされていることに非常に驚きました。red=1.0green=0.0green=1.0

(予想されるレンダリング出力と実際のレンダリング出力)

はinterpolated.position、各フラグメントに対して同じ値を生成しているようです。

ここで何が間違っていますか？

_{Ps: (このダミー フラグメント ロジックは、頂点補間を使用して簡単に実現できましたが、実際のフラグメント ロジックでは実現できませんでした。)}