問題タブ [metal]

大量の数値配列を計算する場合、Metal は Accelerate フレームワークよりも高速である可能性があると主張する記事があります。

Metal のシェーダー言語のドキュメントを見た後、倍精度浮動小数点数または 64 ビット整数の配列がサポートされていないことに気付きました。私は何かを見落としていますか？Metal は 64 ビット A7 プロセッサ用に設計されていると思いましたか?

MTLBufferMetal カーネルのスレッドグループ間で書き込みを同期したいと考えています。atomic_uintタイプとatomic_fetch_add_explicit機能を使用しようとしました。これはうまくいくはずですが、私の問題は、CPU 側で値を解釈する方法がわからないことです。異なるスレッド グループから同じバッファーへの書き込みを同期するために使用できるロック メカニズムを使用したいと思います。アトミック型にバインドされていないそのようなメカニズムまたはその他の回避策はありますか?

iOS 5.1.1 から iOS 8 を対象とするアプリを開発しています。これは、arm64、armv7、および armv7s を含むユニバーサル バイナリです。現在、arm64 は iOS 7 以降 (サポートされているデバイス) でロードされますが、iOS 8 でのみロードするように強制したいと思います (つまり、iOS 7 を armv7s のロードに戻します)。

動機:効率的な理由から、iOS 8 固有の機能の条件付きコンパイルが必要です。iOS 8 でレンダリング バックエンド全体を OpenGL ES から Metal に切り替えていますが、この 2 つの間の動的ディスパッチに料金を支払いたくありません。バックエンドは一連の C 関数であるため、API を動的に選択するには、すべてに対して関数ポインターの追加レイヤーが必要になります。arm64 が iOS 8 のみの場合、Metal を使用して条件付きでコンパイルできます#ifdef __arm64__。

私がうまくいくと思うこと：「iOS Deployment Target」の下にarm64の条件付きビルド設定を追加しています。ビルド ログを確認し-miphoneos-version-min=8.0たところ、arm64 ビルド用に追加されていることがわかりました。iOS 8 と arm64 で正常に動作します。iOS 7 と arm64 の場合、2 つの結果が考えられます。1) iOS 7 は 64 ビット バイナリを確認し、サポートされていないものとして破棄し、armv7s のロードに進みます。2) 64 ビット バイナリを読み込もうとしてクラッシュします。問題は、私の唯一の 64 ビット デバイスが iOS 8 を実行しているため、テストできないことです。

私の質問は、これが機能するかどうか (おそらく誰かが以前にこれを試したことがあるかどうか)、または問題に対する別の解決策があるかどうかです。

参照用の条件付きビルド設定のスクリーンショット:

Metal API を使用して、Apple A7 GPU で多数の非常に小さな 2D クワッドをできるだけ高速にレンダリングしようとしています。GPU のトライアングル スループットの数値を調べて (たとえば、こちら)、Apple がキーノート デモ中に画面上に 1M を超えるトライアングルを引用していることから、60 fps でフレームあたり 500,000 のようなクワッドをレンダリングできると期待しています。それらのすべてが (z バッファーによって隠されずに画面上で) 表示され、小さい (ラスタライザーにとってはトリッキー) ことを考えると、おそらく少し少ないので、これは GPU が非常によく最適化されているユースケースではない可能性があります。おそらく、Apple のデモは 30fps で実行されていたので、最大 200,000 が実行可能であるとしましょう。確か10万…ですよね？

ただし、私のテスト アプリでは、最大値はわずか 20,000 です。それ以上であり、iPad Air ではフレームレートが 60 を下回りました。100,000 クワッドの場合、14 fps、つまり 2.8M 三角形/秒のスループットで実行されます (AnandTech の記事で引用されている 68.1M の画面上の三角形と比較してください!)。

単純なフラグメント シェーダーを使用してクワッドを 1 ピクセル小さくしても、パフォーマンスは向上しません。したがって、これは頂点バウンドであると想定でき、Xcode の GPU レポートは一致します ("Tiler" は 100% です)。頂点シェーダーも簡単で、わずかなスケーリングと変換計算を行うだけなので、ボトルネックは固定機能ステージであると想定しています...?

背景情報として、インスタンスごとに 1 つのクワッド、つまりインスタンスごとに 4 つの頂点を使用して、単一のインスタンス化された描画呼び出しを使用してすべてのジオメトリをレンダリングしています。クワッドの位置は、頂点シェーダーのインスタンス ID によってインデックス付けされた別のバッファーから適用されます。他のいくつかの方法も試しました (すべての頂点が事前に変換されたインスタンス化されていない、インスタンス化された + インデックスが作成されたなど) が、役に立ちませんでした。複雑な頂点属性、バッファー/サーフェス形式、またはドライバー/GPU で遅いパスにヒットする可能性が高いと思われる他のものはありません (もちろん確信はありませんが)。ブレンディングはオフです。他のほとんどすべてはデフォルトの状態です (ビューポート、シザー、ztest、カリングなど)。

アプリケーションは Swift で書かれていますが、問題にならないことを願っています ;)

私が理解しようとしているのは、(「適切な」3D シーンとは対照的に) このようなクワッドをレンダリングするときに私が見ているパフォーマンスが期待されるかどうか、または宣伝されている三角形に近づくためにいくつかのより高度な技術が必要かどうかです。スループット。ここでの制限のボトルネックは何だと思われますか?

また、Metal よりも OpenGL の方が高速である理由を誰かが知っている場合 (私は試したことがなく、理由も思いつきません)、それも聞いてみたいと思います。

ありがとう

編集: シェーダー コードを追加します。

Metal Language も C++11 に基づいており、C++ は実績のあるパフォーマンス言語である完全に適合するように思われるため、Objective-C / Swift を完全にバイパスすることを検討しています。私は C++ の分野にとどまりたいと思っています。可能性はありますか？

コンピューティング API (iOS は ES 3.1 コンピューティング シェーダーをまだサポートしていないため) として Metal を使用し、OpenGL ES をグラフィックス API として使用して、いくつかの OpenCL サンプルを移植したいと考えています。アプリは、Metal と OpenGL ES API を同時に利用できます。また、相互運用性が達成された場合とその方法、つまり、Metal によって計算されるデータのバッファ オブジェクトの OpenGL マッピング..ありがとう..

私は 2D ゲームを構築しており、多くのオブジェクトでゲームUIViewをオーバーライドして描画するサブクラス内のプレイエリアを描画しています。私は iOS の経験があまりないので、これが正しい方法かどうか疑問に思っていました。drawRect:UIBezierPath*

だから私は私の質問だと思います どれくらいで十分ですか？UIBezierPathOpenGL または Metal の使用をいつ停止して開始する必要がありますか? これらを使用して の内部に描画できますか、UIViewそれとも画面を完全に制御できますか?

だから私はクロスプラットフォームのビデオゲームに取り組んでいます... したがって、Windows プラットフォームでは DirectX、Mac、Linux、Android プラットフォームでは OpenGL/ES、iOS プラットフォームでは Metal を使用できる必要があります。ライブラリを検索しましたが、何も見つかりませんでした。そのため、たとえば COLOR を Windows プラットフォームでは D3DColor に、iPhone プラットフォームでは UIColor に定義するように、マクロ制御される独自の typedef を作成することにしました。 、および他の GL 準拠プラットフォームの glColor4f。これは、iOS プラットフォームの関数が存在するヘッダー ファイル (CommonMetal.h) です。

これは obj-c ソース ファイル (CommonMetal.m) 内のコードです。

注: Metal は、これが Metal 準拠のプラットフォームであり、コードがプリコンパイル済みヘッダーに配置されていることを確認するために作成した定義済みマクロです。

プロジェクトをコンパイルしようとすると、ヘッダー ファイルの typedef 行を指すエラーが発生します。これは正確なエラーです：

.../CommonMetal.h:13:9: 不明な型名 'UIColor'

.../CommonMetal.h:14:9: 不明な型名 'GLKVector3'

.../CommonMetal.h:15:9: 不明な型名 'GLKVector4'

スタックオーバーフローに関する他の回答を読みましたが、追加しようとするたびに:

この質問/回答で説明されているエラーが表示されます。したがって、私が理解したことから、ファイルは obj-c ファイルではなく c++ ファイルであると考えられています。上記のリンクで提案されている回答を使用してみましたが、エラーは削除されましたが、UIColor が定義されていないなどの以前のエラーはまだ残っています。他の情報が必要な場合は、コメントを追加してください。その追加情報を確実に追加します。前もって感謝します。