swift-developers-japan

Metalのシェーダーファイルをpodに含めた場合にアプリのビルド時にMetalシェーダのビルドが走らない…

9:15 AM

と思ったけど走っているっぽい bundleちゃんと指定すればmetallib取れそう

9:15 AM

let lib = try! device.makeDefaultLibrary(bundle: Bundle(for: type(of: self))) で取れた

3

レンダリング用のスレッドを作って描画するときにどうしても最後にdrawableを取得するためにMTLViewやCAMetalLayerを触ってしまってThread Sanitizerに怒られてしまう・・・。こういうときってどうするのがいいんだろう。

設計を詳しく見ないとなんともいえないですけど、

8:53 AM

安直には、 MTLViewに触る必要のある最後の処理だけ

8:53 AM

DispatchQueue.main.asyncで実行する感じになりそうです

8:54 AM

描画スレッドはフレームバッファなりへの書き込みまでを行う。

MetalだとcommandBufferでdrawableやレンダリング先のtextureが必要で、それをUIが返してくれる（(CAMetalLayer.nextDrawable()）のでOpenGLESで言うフレームバッファの書き込みまでにUIを触っちゃうんですよね…。そこだけメインスレッドでも良いんですけど、毎フレーム触っちゃうのは嫌だなぁと

9:06 AM

https://github.com/noppefoxwolf/Kitsunebi_Metal/blob/master/Kitsunebi_Metal/Classes/PlayerView.swift#L42

noppefoxwolf/Kitsunebi_Metal

Kitsunebi_Metal - [WIP] Kitsunebi using Metal.

metalLayer.nextDrawable() をメインスレッドで呼んで、

9:11 AM

engine.render(to: drawable, src: src, mask: mask)を描画スレッドで実行する？

9:12 AM

もしくは

9:12 AM

描画用のバッファは別に用意しておいて

9:12 AM

その絵の転送だけをメインスレッドで回すとか。

なるほど！描画用のバッファ別で用意するのが良さそうですね、各フレームのpresentationTimeを現実の時間と同期する箇所が必要なのでそこでdrawableを取って来て描画バッファから転送という流れが綺麗そうやって見ます、ありがとうございますー！

9:19 AM

あ、でも結局毎フレームUI触ってしまう事に変わらないか・・・ nextDrawableをスレッドセーフに取ってくる機構が必要だなぁ

チップセットによってGPU/CPUからも共有メモリ扱えるのかと思ったけど、OpenGLES使っているうちは転送必要なんですね https://developer.apple.com/jp/documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/Performance/Performance.html

GPUがタイルのレンダリングを終えると、そのピクセルデータを共有メモリに書き戻す必要があります。これを論理バッファの格納と言いますが、やはり負荷の高い処理です。描画するフレームごとに少なくとも1回はこの転送が必要です。

OpenGL ESアプリケーションのチューニング

iOSアプリケーションにOpenGL ESを採用して、高パフォーマンスのグラフィックを生成する手順を解説します。

5:05 AM

この辺りのCPU <-> GPU間の転送処理ってInstrumentsから見れるのかな

Metalをシミュレータで走らせるため、関連クラス使う前に全部#if arch(i386) || arch(x86_64)を付けないといけないかな

5:55 AM

走らせるではなく、コンパイルを通る

そうなります、Metalはi386/x86_64ではコンパイル出来ないので。

アプルさんせめてコンパルを通して欲しいな

DIとかで依存部分を隠すのが良いと思います。シミュレータではOpenGLESか、何も実行しないStubで何とかするとか、、 (edited)

なるほど、試してみます、ありがとうございます

1

あ、すいません。Metal/MetalKit自体はコンパイル通ります。 CVMetalTextureCacheとかCAMetalDrawableとかこの辺の事ですよね > 関連クラス (edited)

シミュレータのSKDではMetalKit入ってないので、MTKViewも見つかりません。Metalに入ってるものが大丈夫らしいです。

7:08 AM

https://www.invasivecode.com/weblog/metal-image-processing?doing_wp_cron=1533026631.2689108848571777343750

Metal: Blazing Fast Image Processing

Metal can process images in real-time applications. In this tutorial, you learn how to setup a Metal project and perform blazing fast image processing.

7:08 AM

前発見したいい記事です。

MetalKitは多分あるはずです、deviceが取得できないので実行はできませんがコンパイルは通るはずです。（自分の環境では通りました） /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/System/Library/Frameworks/MetalKit.framework CVMetalTextureが無いのは、CVMetalTexture.h自体は存在しているが、COREVIDEO_SUPPORTS_METALフラグでifdefされているからでした。どこかでフラグ書き換えてあげればとりあえずビルドは通るかもしれませんね… /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/System/Library/Frameworks/CoreVideo.framework/Headers/CVMetalTexture.h

1

とりあえずビルド通すなら#ifで自分で空のクラスとして定義するのもありかも。

CAMetalLayerはそもそもシミュレータSDKには無いっぽい、CVMetalTextureと扱い違うのか

https://gist.github.com/noppefoxwolf/8540f2a18a8a8268422947cbbddb1f93

metal_excluded.h

11:21 AM

手元のMetalプロジェクトで使ってそうなところ探して出してみた。他にもあるかも

CIFilterの結果をUIImageViewに描画するのと、シェーダー使ってGLESView/MTKViewに表示するのはコスト変わらないのでしょうか…？ CIFilterのデメリットとしてCIFilterから作ったCIImageをUIImageに変換する過程でCGImageにするからコストが大きいみたいに https://www.objc.io/issues/21-camera-and-photos/core-image-intro/#improving-performance-with-opengl には書いてあるけど、UIImage(ciimage:)使ったらそのコスト（多分）無いし実は変わらない…？ (edited)

An Introduction to Core Image · objc.io

objc.io publishes books on advanced techniques and practices for iOS and OS X development

変わらない気がしている

11:52 AM

UIImageってそれ自体はイメージバッファの実体を持っていなくて

11:52 AM

CGImageやCIImageが実体で

11:53 AM

描画のときに都合の良い方になっている気がする

11:57 AM

あ、あと、CoreGraphicsにおいても、下請けのバッファはCPUモードとGPUモードがある気がする。

CIImageはソースとフィルタ構造のレシピなので最終的にピクセル単位のデータ配列にはなると思うんだけど、多分UIImageViewはそれを直接GPUに展開して表示しますよねそうなるとOpenGLESのシェーダで実装するのと変わらないですね…

それ系でいうと

12:02 PM

リサイズされたときの挙動なんかが

12:02 PM

レシピで持ってるか、いちどピクセルバッファになるかで変わると思うんですけど

12:03 PM

UIImageってサイズ不定は表現できないのかな。

12:03 PM

CIImageが

12:03 PM

もしそのレシピをシェーダーコードに展開していたら

12:03 PM

自前でフィルタ処理を画像に複数回かけるよりも

12:03 PM

GPUでワンショットな処理になっていて、速いとかもあるのかも

あー、それはありそうです。仮に1フィルタ噛ませるにしても、最終的にリサイズが必要であれば2フィルタかかるって話ですよね。 CIFIlterは複数フィルタを寄せて一括で処理かけるみたいな話だった気がするので、書き方によっては自前より早そうです。

https://www.objc.io/issues/21-camera-and-photos/core-image-intro/

It is possible to create a UIImage directly from a CIImage, but this approach is fraught: if you try to display such an image in a UIImageView, its contentMode property will be ignored.

An Introduction to Core Image · objc.io

objc.io publishes books on advanced techniques and practices for iOS and OS X development

12:07 PM

だいぶ前の記事だからもう変わっているかもしれないですが。

Using an intermediate CGImage takes an extra step, but obviates this annoyance.

12:08 PM

CGImageを経由するとContentModeが正しく働くってことは、

12:08 PM

CGImageを経由しようとするとそこでピクセルバッファになってしまってる？

それはそうですね。

UIImageでContentModeが正しく動かないってことは、処理自体はなんか特別な速いやつになってそう

CIContext 次第だと思いますが、GPUのコンテキストで作ったものなら、そのままGPUで描画になりそうですね。

あ、そうか、CIContextを作るときに指定したりできるんですっけ。

今試してみたらcontentMode効いてますね、iPhoneXだからかも、5cとかでやらないと分からないな…

昔のバグかも。

12:14 PM

ありえんでかい画像を作ったら

12:15 PM

メモリ消費とGPUメモリ消費を観察して

12:15 PM

なんとなくわかるかもしれないですね

12:15 PM

GPUメモリ消費がわかるinstrumentsあったっけ

バグだとしても少なくともおもちさんの言う通り特別速いルートか何らか違うパイプラインで処理されてそうですね CGImageになっている時にCPUメモリ側にあったらCIImage to UIImageはオーバーヘッドありそうですね…！

12:24 PM

CPU -> GPU間のtransferが分かっても同義か多分最近のはMetalになっちゃっているので旧デバイス必要ですね…

12:27 PM

iPhone5cポチったので届いたら測ってみます

↑OpenGLESのInstrumentsがもう動かないので検証出来なかった…。

https://github.com/BradLarson/GPUImage3

BradLarson/GPUImage3

GPUImage 3 is a BSD-licensed Swift framework for GPU-accelerated video and image processing using Metal. - BradLarson/GPUImage3

3

10:54 AM

Metal製GPUImageが来た

こんばんは

‍

5:26 PM

名前はmetalになっていますが、グラフィック全般ここでokなんですかね？

あまり厳密じゃないんで、他に良さそうなチャネルがなければ書いてみて、他の方が良さそうなら誰かが案内してくれると思います

1

こんにちは。Metalではないですが、Core Image Kernel Languageで以下のコードがiOS11では動いていたのですが、iOS12上で実行したらエラーも吐かずに動かなくなってしまいます。(カメラからcaptureOutputでフィルターを掛けてUIImageViewに突っ込んでいるが、それが止まってしまう。 arrayの書き方は特に間違ってないと思うのですが...

vec2 blurCoordinates[9]; ... blurCoordinates[4] = destCoord(); ... // これは動かない(iOS11までは動いていた) vec4 centralColor = sample(inputImage, samplerTransform(inputImage, blurCoordinates[4])); // これは動く vec4 centralColor = sample(inputImage, samplerTransform(inputImage, destCoord()));

(edited)

こちら、CIKernelのapplyのroiCallbackでinsetを設定していたんですが、それを消したらうまく動くようになりました(謎

1

UIImageViewってCIImageの表示に最適化されてたんですね。 GLKViewとかMTKView使ったCIImageの表示は必要なかったのかな..

個人的にはその手のMetalで画像表示ビューなどの自作は意味がないと思ってます。

3:38 AM

理由はUIImageViewが対応しているからです。

3:38 AM

iOS自体がMacOSXをベースにしてるので、基本的な描画システム(CALayer)がCPUベースじゃなくGPUベースでできているはずで

3:39 AM

UIKitが提供してる範囲で目的が果たせるなら、パフォーマンスに関してはAppleに任せたほうが、GPU連携の裏の挙動も最適化されると思います。

そうですよね、今まで少し勘違いしてました

3:55 AM

ただ、以前がんばってPhotosの編集画面を覗いていた時に、クロップ時と編集プレビュー時でUIImageViewとGLKViewを使い分けていたのを見つけたことがあったのが少し気がかりです。これはiOS9だったかな..

1

なにかエフェクトがかかったりする箇所であれば、OpenGLのコードを書きたいのでGLKViewを使う理由が出てくると思いますが、ただ表示してるだけの箇所なら謎ですね

ああ、明るさとかのフィルターは行うViewだとは思います!

お、じゃあその処理をGLで実装してるんじゃないですかね〜

なるほど、

GL関係は全部deprecatedになってるからiOS12だとMetalに変わってるんですかねえ

また機会があれば頑張って覗いてみたいものです

1

ぬ、UIImageView <- CIImage contentModeが効かない?

8:40 AM

実機 iOS12は効いてる (edited)

8:41 AM

実機iOS11も大丈夫か... シミュレータだけかしら

前にこのスレでrintaroさんが話してたやつですかね CGImage経由すると問題ないとか (edited)

お、そんな問題が

MTLTextureのpixelFormatの変更をやったことがある人がいますか？ (edited)

metal関連したコードがiPhone8以後の機種がRender先のMLTextureのusageを.renderTargetに設定しないとXcode10.0がよくクラッシュになる。。。Xcode10.1にアップデットするとやっとこれが分かった。

MetalでMacOS上で動くshaderを弄ってみました。

4

Metal使いはじめて気づいたこと。自前のキューブなどのオブジェクトを複数描画したい場合は renderCommandEncoder?.setVertexBuffer() renderCommandEncoder?.drawPrimitives() をオブジェクト数分書けばいい。これが分からなくて半日ハマりました。 (edited)

3Dゲーム制作を開始しました。 (edited)

4

1