LunarG Exploring Vulkan To Metal Translation With Mesa

[phoronix]

Phoronix: LunarG Exploring Vulkan To Metal Translation With Mesa

While there is the open-source MoltenVK project that implements the Vulkan API atop Apple's Metal graphics drivers on iOS/macOS, the 3D graphics consulting firm LunarG is exploring the possibility of implementing Vulkan to Metal translation using Mesa...

https://www.phoronix.com/news/LunarG-Vulkan-Metal

[Alexmitter]

Converting Vulkan to Metal is like converting OpenGL 4.6 to GLES 2.0. And the only reason someone would even be insane enough to attempt that is if a company really tries their hardest to make it impossible to establish industry standard API drivers on their hardware.

[oiaohm]

Converting Vulkan to Metal is like converting OpenGL 4.6 to GLES 2.0. And the only reason someone would even be insane enough to attempt that is if a company really tries their hardest to make it impossible to establish industry standard API drivers on their hardware.

https://github.com/KhronosGroup/MoltenVK

Remember we already have MoltenVK by the KhronosGroup and we have Microsoft Dozen driver for Vulkan/opengl/gles to Direct X. So in some ways mesa3d coming the only middle layer would be useful on saving developer time.

Big issue is Metal is object c. This is a weakness of Opengl and Vulkan and Direct X that if you are coding in Object C that the interfaces are not that compatible. Apple problem is kind of deeper than one thinks.

https://en.wikipedia.org/wiki/Objective-C

Yes a lot of people forget that MacOS default programming interfaces are object c and fail to see that opps OpenGL and Vulkan and Direct X are designed around C and C++ so we have a incompatibly. Yes KhronosGroup don't define how Opengl/Vulkan interfaces should be in Object C. And of course Microsoft does not do direct X interface for object c.

This is a case you need two to tango. Apple OS being heavily Object C does cause issues.

https://www.geeksforgeeks.org/memory-management-in-objective-c/

There is something to learn here. Before rust we have objective c with a different memory management system to C and C++.

Of course there is a simple problem here how to you hook up the operations that happening on the GPU part that link to memory management back to the CPU part. I can see rust having in future issues with Vulkan and Opengl and Direct X in the same ways apple has hit with there OSs where there is not a proper connection.

This is something to be aware when throwing that industry standard API around as an answer. Sometimes it pays to ask is this so call industry standard defective in some way so causing the party/parties refusing to use it some major problem?

Yes the case of Opengl/Vulkan and Direct X they operate in ways not compatible with Objective C memory management. This should put up scary alarm bells because this issue equally applies to rust, go.... basically all programing languages that do attempt have more security memory management than C and C++.

Some ways working out how to put Vulkan on Macos with objective C interfaces could be useful particularly if how to interface with languages with better managed memory is solved in the process. Yes Vulkan being objective c compatible then maybe Apple would implement it. Also application developers on apple OS have coded dominantly in objective C so Apple cannot go hey everyone just change to C/C++ now and have a nice response from their application developers.

Yes there is a two to tango problem here. Being aware of what the problem is in this case says we have a bigger problem with Vulkan and Opengl we do need to deal with at some point. Yes the problem of how to correctly use Vulkan and Opengl with programming languages and runtimes with more advanced memory management and have this memory management function correctly.

[luno]

Converting Vulkan to Metal is like converting OpenGL 4.6 to GLES 2.0. And the only reason someone would even be insane enough to attempt that is if a company really tries their hardest to make it impossible to establish industry standard API drivers on their hardware.

Metal is currently best api though, it is simpler and sane than both dx12 and vulkan which are mess

[luno]

isn't someone from Autodesk also working on something similar some weeks ago

[Dukenukemx]

Metal is currently best api though, it is simpler and sane than both dx12 and vulkan which are mess

If Apple implemented Vulkan into MacOS, I'd bet nobody would ever touch Metal. The real hot mess is that Apple requires developers to learn an API that is not used on any other platform but Apple's, which accounts for very little besides iOS.

[Alexmitter]

Metal is currently best api though, it is simpler and sane than both dx12 and vulkan which are mess

"GLES 2.0 Metal is currently best api though, it is simpler and sane than both OpenGL 4.6 and DirectX 11 which are mess"

Metal is a joke, just like GLES 2.0. No one can argue that GLES 2.0 isnt simpler, but that is not a good thing.

[shmerl]

Metal is currently best api though, it is simpler and sane than both dx12 and vulkan which are mess

It's simpler than simple enough, so it's not "best". The only reason it exist is because Apple are NIH and lock-in freaks.

[davidbepo]

why the hell would you do that

[oiaohm]

If Apple implemented Vulkan into MacOS, I'd bet nobody would ever touch Metal..

There is a problem here. Why is there not a dominate use of MoltenVK on MacOS so this claim makes no sense.

https://github.com/KhronosGroup/MoltenVK

There is a reason people are using Metal because they could have chosen to use MultenVK for a very long time and they don't..

https://www.baeldung.com/linux/xcode

https://github.com/darlinghq/darling

Also the cost of mac OS development is not the amount the video claimed. Yes using darling to build MacOS binaries on Linux using xcode commandline/sdk then use your Mac OS owners/users as you crash test dummies is cheap developer option. Yes you can see the finger prints of this in many so called Triple AAA games released natively on MacOS and IOS. Yes MacOS and iOS users small market share they can be crash test dummies.

Yes one of the things that has kept darling project development alive is the legal means to build MacOS/ios binaries without apple hardware.

To have a signing key for signed Windows executable is also over 100 dollars so the signing key charge of Apple is not that bad.

Interesting point is darling use to not work under Windows WSL1 but since dropping the kernel module requirement darling works under WSL1 and WSL2. So yes you can build MacOS binaries using xcode commandline/sdk legally on Windows and Linux using Darling. Testing that the application works right for end users you cannot do that with Darling.

"GLES 2.0 Metal is currently best api though, it is simpler and sane than both OpenGL 4.6 and DirectX 11 which are mess"

Metal is a joke, just like GLES 2.0. No one can argue that GLES 2.0 isnt simpler, but that is not a good thing.

You need to stop this idea of linking Metal to GLES 2.0. Vulkan predecessor is AMD Mantle . If you take Metal 1 core and compare to to Mantle you see that Metal is AMD Mantle ported to support Objective C.

I do disagree with the Best claim. For a new developer having better memory management when using Metal with Objective C to limit issues like memory leaks does have some advantage.

Yes I can understand those use to coding with Objective C thinking that Opengl, Vulkan, Direct X are a mess because you don't have the better memory management.

Please read MoltenVK and note that Metal has the functionality of Vulkan 1.2 this is well above GLES 2.0 in functionality.

It's simpler than simple enough, so it's not "best". The only reason it exist is because Apple are NIH and lock-in freaks.

shmerl this is excuse not to sit down and look and say is there something good about this bit of software and throw the baby out with the bathwater.

The advantage of metal and I would say the only advantage is for new developer better integration with Objective C memory management results in less ways for those developers to make coding errors. The issues that make connecting Opengl, Vulkan and Direct X to Objective C memory management also make it hard to connect these items to Rust, Go, Java, .Net .... memory management. Yes anything with more advance memory management than C or C++ has a problem.

I really do wish Metal was just a joke. Problem is Metal is example of a problem that appears in other places. Yes most people don't notice the reason why people claim metal is simpler to develop with. If you question Metal using developers who like it the answer is the Objective C language integration resulting in simpler path to not having memory leaks and other issues like it.

Please note this Objective C problem with memory management integration issues with API designed for C/C++is also turning up with Rust in the Linux kernel and other places. No one has really worked out how to make a more advanced/safer memory management play nice with C/C++ memory management.

Like or not there is a problem here and its not just restricted to apple products. What you guys have been doing is basically sweeping a real problem under the rug. Yes you hear just is the Linux kernel rust developers or just Apple or just .Net or just Java and it all the same problem of how do you make conflicting memory management designs play nice with each other and function correctly on both sides..