Lazarus
Programming => Graphics and Multimedia => OpenGL => Topic started by: ChrisR on August 22, 2018, 04:09:07 pm
-
I have created a few Lazarus projects that can be compiled for Apple's new Metal API.
https://github.com/neurolabusc/Metal-Demos
Most of these projects can also be compiled to support OpenGL 3.3 Core - providing support for Windows, Linux and older Macs. By keeping a thin layer for either OpenGL or Metal, one can retain most of Lazarus' "write once, compile everywhere" magic.
The documentation is sparse, but both the main page and the line project include some useful information
https://github.com/neurolabusc/Metal-Demos/tree/master/lines
The Metal support uses Ryan Joseph's lazmetalcontrol
https://github.com/genericptr/Metal-Framework
My examples all use Lazarus. However, Ryan's repository also includes some examples of how to use Metal directly from freepascal without Lazarus.
Ryan deserves incredible credit - has framework provides a great a very simple way to use this powerful but complex API.
-
Hi Chris,
Thanks for your demos with Metal API on macOS!
Can you check MeshProj project with Lazarus 2.0.6?
We have the following error during compilation on macOS High Sierra:
glcocoanscontext(506,45) Error: identifier idents no member "KeyEvent"
glcocoanscontext(512,45) Error: identifier idents no member "KeyEvent"
glcocoanscontext(518,45) Error: identifier idents no member "KeyEvent"
Project: Metal-Demos-master/mesh/MeshProj.lpi
-
I've added this overlooked macOS gem to the Wiki: https://wiki.freepascal.org/Metal_Framework
-
Thanks, one correction:
"to use Metal you will need macOS 10.12 (Sierra)"
Metal was introduced in macOS 10.11 (El Capitan).
-
The Lazarus 2.0.6 release for MacOS contained a regression for OpenGL support.
https://bugs.freepascal.org/view.php?id=35797
GLCocoaNSContext.pas now requires "cocoa_extra" in uses section. You can either edit your copy or get a new copy from trunk
https://github.com/graemeg/lazarus/tree/upstream/components/opengl
Alternatively, you can use Lazarus trunk rather than 2.0.6.
-
Thanks, one correction:
"to use Metal you will need macOS 10.12 (Sierra)"
Metal was introduced in macOS 10.11 (El Capitan).
Thanks, fixed!
-
Chris,
Thanks! I'll try next week.
-
Hi,
Can you help me - rendering to texture in Metal not working.
I attach a simple test project.
It must show a rectangle, but only shows clear color (blueish). Rendering directly to screen works. If you turn off {$define Rendertarget} in MyMetal.pas, you'll see a rectangle.
-
C arrays are indexed from 0, just like dynamic Pascal arrays.
colorAttach:=RndPass.colorAttachmentAtIndex(1);
->
colorAttach:=RndPass.colorAttachmentAtIndex(0);
-
Hi Chris,
Many thanks for your reply! I'll check tomorrow and will write about results.
-
Now rendering to a texture works fine. Thanks again. Stupid mistake :)
-
Do I understand rightly, that this Metal framework for Lazarus automatically uses Metal 2 on Mojave/Catalina?
-
Hi,
Please help me. I use offscreen rendering to a texture and then save a picture into a bitmap. It works only when I resize once the main window with a mouse cursor.
I don't use MTKView and just create only MTLDevice for offscreen rendering.
A simple test project is attached. Compile and run it. rt.bmp file will be created/updated automatically. Once you resize the main window, bitmap will contain a colored gradient rectangle (OK). But why offscreen rendering is linked with a size of the main window?
-
I believe your issue is that your view is bound to the Form view, and will only be functional when the form has a context (e.g. context not ready at FormCreate, but is at FormResize):
ViewGPU1.Parent:=Form1;
ViewGPU1.Align:=alClient;
You might want to look at this demo:
https://developer.apple.com/documentation/metal/customizing_render_pass_setup?language=objc
-
Hi Chris,
Thanks for your advice! I'll check that article.
-
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.
-
My example is very simple, but it seems that Metal is very complicated API in comparison with Direct3D.
compared to DX12 or earlier?
-
I will grateful for any help or advice with offscreen rendering in Metal. This topic may help other members to learn Metal.
-
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.
-
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.
-
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.
-
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.
-
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."
-
Благодарю! Я это долго искал!
Thanks.
-
Есть ли решение для Carbon?
translate: Is there a solution for Carbon?
-
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