Metal Framework for MacOS

[Igor Kokarev]

Hi,

Offscreen rendering with Metal doesn't work correctly yet.

I've read Apple's article above, but it shows a different example and there is no exampe for pure offscreen rendering without any MTKView.

I attached a modified project. I removed any visual controls. Only offscreen rendering. When you click a button 1st time it creates rt.bmp with a black picture (wrong result), next click to button renders and creates correct image in rt.bmp

If I call twice:
RTTex.DrawTo;
RTTex.DrawTo;
it does NOT help, it works only when I use timer or click twice the button.

My example is very simple, but it seems that Metal is very complicated API in comparison with Direct3D.

[skalogryz]

My example is very simple, but it seems that Metal is very complicated API in comparison with Direct3D.

compared to DX12 or earlier?

[Igor Kokarev]

I will grateful for any help or advice with offscreen rendering in Metal. This topic may help other members to learn Metal.

[ChrisR]

Igor-
 1. Do you want too try the attached project. This seems to work, though it still requires accessing a form to determine the device context. Perhaps you can work on ways to simplify this.
 2. I agree that modern GPU APIs (Metal, OpenGL Core, Vulkan) all have a steeper learning curve than higher level APIs, like legacy OpenGL (which provided a lot of helper functions and fixed function pipelines that make development easier). The concept of modern lower-level APIs is that they give you far more control, and match the actual computations of GPUs more closely (using resources more efficiently). These low-level APIs are not friendly to hobbyists. I think that wrappers like Unity and other game engines are the modern way to access these APIs in a cross-platform way (targeting Metal on Apple hardware and DirectX/Vulkan on other devices). Since modern computers are so fast, even scripting languages like Python become nice solutions for many problems. Metal is good for mission critical solutions like games or computational intensive compute.

[Igor Kokarev]

Hi Chris,

Thank you very much for your example!

I wrote my code and now it works correctly. I attach the ZIP archive.

I have one comment. I still use an intermediate managed texture before copy rendertarget texture (private) to my buffer. And I use MTLBlitCommandEncoder and call copyFromTexture.

I see that you avoid using this step.

Should I use managed offscreen texture for rendering and then just copying it calling getBytes_bytesPerRow_fromRegion_mipmapLevel ?

P.S. Thanks for your thoughts about Metal/Vulkan. I share your opinion.

[Igor Kokarev]

Here is a final test project for offscreen rendering in Metal.

You can use a define UseManagedRT to avoid a second texture and use only one managed offscreen texture.

Important addition. For both variants you should call synchronizeResource (MTLBlitCommandEncoder) for a managed texture to copy data from GPU to system memory in this texture. And only then copy texture to your buffer.

Without calling synchronizeResource() offscreen rendering will NOT work on Macs with dedicated graphics (AMD).

P.S. Apple's documentation is terrible and doesn't explain many important things with offscreen rendering.

[ChrisR]

Igor, thanks for your sample code. You have discovered that Ryan's Metal screen capture code does not work for recent versions of Metal. Based on your work, I have suggested a patch for Ryans framework:
  https://github.com/genericptr/Metal-Framework/issues/2

Your code and explanation is clearer than Apple's documentation.

[Igor Kokarev]

Hi Chris,

I'm glad that your found a fix for Ryan's framework!

I attach a firmly final version of my test app for Metal offscreen rendering.

I added SynchronizeResource for two variants (with intermediate managed texture and when offscreen texture is managed).

We have 3 Macs. Two with integrated Intel graphics and a new iMac with dedicated AMD graphics.
Macs with Intel graphics work without call of SynchronizeResource and Mac with AMD graphics requires this function for the correct work. Of course, now we always call SynchronizeResource on any Mac.

It seems that textures on Intel graphics exists in one copy (in system memory which is also video memory). So could skip SynchronizeResource() because our texture always available in system memory. And on AMD graphics a managed texture exist in two copies - in dedicated (fast) video memory and in system memory.

As Apple's website says about SynchronizeResource: "Encodes a command to synchronize the contents of a managed resource from the GPU to the CPU."

[Seenkao]

Благодарю! Я это долго искал!

Thanks.

[Seenkao]

Есть ли решение для Carbon?

translate: Is there a solution for Carbon?

[ChrisR]

I do not think so. Any reason you want to stick with Carbon? Cocoa allows 64-bit, Carbon is deprecated. Lazarus support for Cocoa is very good, and in my opinion better than Carbon. If you need a feature for Cocoa support, why not create a bug request. You can even become a Patreon supporter of Dmitry's Cocoa features.
  https://www.patreon.com/skalogryz/posts