> I didn't build this for conformance I just wanted to program OpenGL on the MacOS platform
That's a bit of a red sign. It may work on your machine for your application. Conformance tests are a great mechanism to understand how it's going to work for other applications you haven't tested. Hooking up OpenGL CTS on macOS shouldn't be too hard - we got the Vulkan CTS running there a while ago.
Practically speaking, this project is interesting. While generally I'd recommend looking at Vulkan instead of OpenGL 4xxx (as opposed to, say OpenGL ES 3.1), in this case Vulkan -> Metal is much more involved than OpenGL -> Metal. The low level abstractions of Vulkan just don't play that well. For example, MoltenVK doesn't really record any command buffers before you submit(), and that's an abstraction failure. So OpenGL -> Metal is an interesting way to have portable code with a more flexible (better?) abstraction, assuming you can make it work :)
OpenGL is huge. It's probably a better idea to use the shared code in Mesa and write a Gallium to Metal driver. That's how Zink (GL on Vulkan) and Microsofts GLonD3D12 work.
No. The current development version of DXVK requires support for Vulkan 1.3
There are missing features for older versions too:
- bufferRobustness2
- geometry shaders
- transform feedback
- tessellation is super but very slow and problematic
Geometry shaders and transform feedback are terrible features that most GPU vendors would like to get rid of because they don't map well to modern hardware. But games do use them and everyone who isn't Apple has to maintain backwards compatibility.
So it's unlikely that those will ever get supported in Metal. You could probably emulate them with varying levels of compatibility/conformance which might be good enough for a lot of games.
Couldn't you theoretically have a version of DXVK which would just not support geometry shaders, or emulate them (maybe with a performance penalty) in a compute shader?
It might not support every game, but proton isn't 100% either on Linux.
Crossover ships a version of DXVK without geometry shaders and transform feedback.
That unfortunately breaks games using UE4 and Unity. And causes issues with distorted and invisible enemies in Witcher 3. And missing effects in Overwatch.
You get the idea, those feature are unfortunately pretty common.
How does this compare to ANGLE or the MetalANGLE fork, assuming I have some renderer code that already works on both OpenGL 3.2 core profile and OpenGL ES 3.0? (We are already using ANGLE on Windows with the D3D11 backend and might consider using something similar to stop relying on the "deprecated" native OpenGL implementation on macOS.)
It’s annoying that Apple already has an implementation of OpenGL on Metal, but they don’t share the source and they also put up a lot of deprecation warning noise to discourage you from using it.
It’s fine for practically all existing applications. There’s no real reason why Apple should deprecate it instead of opening the source and letting pro apps that rely on OpenGL continue to use this wrapper. The community could implement newer API features, and then everyone just links and includes the version of OpenGL on Metal that they want.
Wrappers are used by the majority of apps anyway, for example WebGL. Apple doesn’t get to say: “We want your JavaScript apps to use our API instead, and we’ll make the development experience subpar if you’re using WebGL.” — they shouldn’t have that kind of power over C apps either.
Cool. I like (!= love) modern OpenGL and use it every now and then. I don't currently use any Apple product or service, but I have been forced to a couple of times, and I find their bully approach to deprecating stuff very annoying.
I would take big money to rewrite some OpenGL to Vulkan or whatever. Right now the easiest way to make big money would be writing some crypto garbage, which aligns with your last sentence. The industry is weird
The readme doesn't say if this works on iOS, which would be an upgrade from Apple's OpenGL ES implementation.
OpenGL ES works great on curent iOS hardware/software but the Simulator support is broken with newer iOS images. In the Simulator, GL ES is now unusably slow, buggy, crashy.
I have an app store Mac/iOS app which is written twice, but the two versions share lots of source, including all the GL rendering code, which is complicated. My strategy has just been to silence the GL deprecations and carry on, as it's not worth the time to rewrite the renderer in Metal, and the performance is great on modern GPUs. I just do cosmetic updates to the UI code as needed.
The mapping of Vulkan to Metal should be fairly direct and efficient, since the architecture of these APIs is very similar. The question is whether there are any important edge cases or bugs that need addressing, or whether the Zink + MoltenVK combination is just missing some optimization work.
> Zink has outperformed native GL drivers even though it introduces an extra layer through vulkan.
That is not the case here (Radeon RX 5700 XT, Linux), Zink is consistently slower than the "native" OpenGL. A quick test with Dhewm3 ("modernized" version of the Doom 3 engine) has the native driver running 1.5 times faster than Zink and with an engine of mine the native driver is ~4 times faster.
I don't have many games to benchmark on but in general Zink tends to be slower than a native driver, but depending on the hardware and game the difference might not be noticeable in practice (without an FPS counter). In the future when hardware is faster than today it might not make much of a practical difference even in benchmarks.
Especially since a lot of work has been put into Zink already. Zink is basically the general case of migrating an OpenGL game engine to a lower-level Vulkan-style API.
Well, OpenGL still works on macOS. It's deprecated, but there's no word on any plans to remove it. I wouldn't be surprised if it sticks around in its current, deprecated form for a long time. It's an older version of OpenGL (4.1), but Khronos has stopped making new OpenGL versions, so it won't grow more outdated over time.
That'd be stupid, OpenGL is easy to use, very useful, provides a lot of functionality and in practical terms it is still the most widely available API across platforms (even if not all platforms give you the exact same functionality but that was always the case with OpenGL anyway).
I for one am not interested in writing the same graphics code across multiple OSes and OpenGL provides a perfectly fine API for my needs.
In a haphazard, difficult-to-use way that lags the state of the art. Because Microsoft controls DirectX, they can look at what the GPU manufacturers are doing, draw up an API spec for the advanced stuff and the GPU manufacturers would hew to that spec. OpenGL is designed by committee, a committee largely staffed by ancient CAD software vendors who insist on backward compatibility and it holds the API standard back. There's a janky extension system in place to allow GPU vendors to add functionality -- in proprietary, mutually incompatible ways that require the developer to write multiple code paths per unit of extension functionality.
Plus there's GPU debugging support integrated into Visual Studio. OpenGL doesn't have nearly the tooling that DirectX does.
Honestly, OpenGL should have been
abandoned, and DirectX made the standard, 25 years ago. The only reason it wasn't was John Carmack, for the past 15 years even he's conceded that DirectX is the better API.
> I for one am not interested in writing the same graphics code across multiple OSes
Use a game engine. It's got back ends for DX, Vulkan, Metal, even OpenGL (although that may change).
If you must code to some 3D API, use DirectX. Natively supported on Windows, supported via DXVK on Linux and DXVK+MoltenVK on Apple (though Microsoft is working on native DX for Apple hardware, probably translating straight from DX to Metal.)
I disagree completely, i can whip out a quick tool for a bunch of tasks much faster using some adhoc OpenGL code than anything related to Direct3D. Direct3D might be easier in some scenarios like writing some rendering backend that you can then ignore and only use it via a layer (but then the same applies to any API, including Vulkan), but i find OpenGL way easier to work with directly than any other API.
> In a haphazard, difficult-to-use way that lags the state of the art.
Haphazard is subjective. I find OpenGL easy to use. As for the "state of the art", it isn't something i often even care to think about.
The only thing i found missing with OpenGL is raytracing support, though that is a very low priority for me right now (i don't even have a GPU with hardware RT) and even if i decide to implement it, i'll most likely use Vulkan-OpenGL interop just for raytracing than rewrite everything in Vulkan.
> Because Microsoft controls DirectX, they can look at what the GPU manufacturers are doing, draw up an API spec for the advanced stuff and the GPU manufacturers would hew to that spec.
Microsoft controlling DirectX is a negative in my view.
> OpenGL is designed by committee, a committee largely staffed by ancient CAD software vendors who insist on backward compatibility and it holds the API standard back.
That backwards compatibility is actually a fantastically great feature of OpenGL - it means code i wrote and worked years ago, still works, so i can focus on other things!
If i ever find part of the code doesn't work good enough (e.g. i need to do something in a different way) then i can only change that part - and it'll really be up to my decision to do so, not forced upon me.
> There's a janky extension system in place to allow GPU vendors to add functionality -- in proprietary, mutually incompatible ways that require the developer to write multiple code paths per unit of extension functionality.
Most useful stuff is in ARB and even when you write multiple code paths it is still easier and requires less code than having to code against some layer with different APIs at the back end for each OS or whatever.
> Use a game engine. It's got back ends for DX, Vulkan, Metal, even OpenGL (although that may change).
There is a chasmatic difference between a game engine and a graphics API (also the rendering code in most game engines is really only a small percentage of the entire engine even if it takes all the marketing focus). OpenGL is great in that it is high level enough to allow ease of use but not high level enough to force any framework-like functionality on you - you are free to design your renderer as you like.
Also because it is a standardized API there aren't random programmers waking up some morning and deciding that the design for their library/engine/framework/whatever could be done a bit """"better"""" and then going forward to break the API, making everyone who depends on it waste time getting up to date with their whims. `glClear` will always be there and do what it is supposed to do without someone thinking that it'll be a better idea to -e.g.- have separate `xxClearColor`, `xxClearDepth`, `xxClearStencil` in a vain and pointless refactor to avoid checking bit checks because that is slow (or whatever useless micromicrooptimization they come up with).
> If you must code to some 3D API, use DirectX.
DirectX is supported only on Windows (DXVK, etc are just hacks to play games whose developers do not want to make good Linux ports and cannot be relied on), controlled by Microsoft who likes to break the API in substantial ways every major version (older versions still work but you can't mix new and old functionality like OpenGL's extension system allows) and much harder to use compared to OpenGL.
I have very, very, rarely opengl only games. Most are vulkan.
Latest unity engine with their new universal 3D pipeline seemed to do it for good.
unreal engine 4/5 don't even have opengl anymore as far as I know.
Godot4 engine has a vulkan backend, but it seems it needs more testing.
I play on native elf/linux.
Then, games which run on rottenfruitOSes without an engine with a native metal backend "just need" to ship with the vulkan->metal translater (molten something).
As far as I know, this is how CSGO runs on vulkan: valve did package the game with the DX(11?12?)->vulkan translater.
> As far as I know, this is how CSGO runs on vulkan: valve did package the game with the DX(11?12?)->vulkan translater.
CSGO has a builtin DX to OpenGL translation layer. They're not using Proton or DXVK, it's Linux native OpenGL. Hopefuly we get Source 2 and native Vulkan sooner than later ..
As far as I'm aware, the updated versions of Source games made for Steam Deck release are in fact using DXVK instead of their old ToGL. Not sure if that includes CS:GO though.
That's a bit of a red sign. It may work on your machine for your application. Conformance tests are a great mechanism to understand how it's going to work for other applications you haven't tested. Hooking up OpenGL CTS on macOS shouldn't be too hard - we got the Vulkan CTS running there a while ago.
Practically speaking, this project is interesting. While generally I'd recommend looking at Vulkan instead of OpenGL 4xxx (as opposed to, say OpenGL ES 3.1), in this case Vulkan -> Metal is much more involved than OpenGL -> Metal. The low level abstractions of Vulkan just don't play that well. For example, MoltenVK doesn't really record any command buffers before you submit(), and that's an abstraction failure. So OpenGL -> Metal is an interesting way to have portable code with a more flexible (better?) abstraction, assuming you can make it work :)