6 ms·

MGL – OpenGL 4.6 on Metal

133 points by coffeeaddict1 4y ago

sylware 4y ago
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.
- toun 4y ago
  > 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 ..
  - Rhedox 4y ago
    > CSGO has a builtin DX to OpenGL translation layer. They're not using Proton or DXVK, it's Linux native OpenGL. It's D3D9 to OpenGL, and it's open source and called ToGL. On Linux you can also opt in to use DXVK by using a launch parameter.
  - seba_dos1 4y ago
    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.
    - sylware 4y ago
      It has been the case on elf/linux, and for a while now, csgo has been running flawlessly for a while on vulkan.
- flohofwoe 4y ago
  It's very likely not for games, but for porting other types of 3D applications. OpenGL hasn't been a popular API for game development since around the late 90's.
samus 4y ago
Zink + MoltenVK can do that too in a pinch, no?
- IceWreck 4y ago
  I have no exp in this area but wouldnt we loose a lot of performance by having two shims. Application -> OpenGL -> Zinc -> Vulkan -> MoltenVK -> Metal -> Hardware
  - bumblebritches5 4y ago
  - uluyol 4y ago
    Not necessarily, especially when you factor in limited (human) resources in. Zink has outperformed native GL drivers even though it introduces an extra layer through vulkan. Ideal world, we'd have direct GL to metal or hardware, but implementing a GL driver is a big effort.
    - samus 4y ago
      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.
    - badsectoracula 4y ago
      > 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.
pavlov 4y ago
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.
- saagarjha 4y ago
  Am I remembering correctly in that it doesn’t support modern OpenGL features, just the really old stuff that the old implementation did?
  - tinus_hn 4y ago
    Yes, that’s because it’s deprecated and that’s why you get all these warnings.
    - Rhedox 4y ago
      It's not just about warnings, Apple only supports OpenGL 4.1 which was released in 2011.
      - waynecochran 4y ago
        OpenGL 4 is not the “really old stuff”
        vetinari 4y ago
        Between 4.1 and 4.6, it changed a lot. Apple never supported extensions for AZDO, for example.
        Rhedox 4y ago
        It's missing features that D3D11 had in 2009. Compute shaders in particular are a huge feature that GL4.1 doesn't have.
  - pavlov 4y ago
    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.
skohan 4y ago
Related: MoltenVK is now compliant with Vulkan 1.2. https://www.phoronix.com/news/MoltenVK-1.2-Vulkan-Apple https://www.phoronix.com/news/MoltenVK-1.2-Vulkan-Apple
- SXX 4y ago
  Does it now have all features that DXVK need to function? There are no details on their repository: https://github.com/KhronosGroup/MoltenVK/issues/203 https://github.com/KhronosGroup/MoltenVK/issues/203
  - Rhedox 4y ago
    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.
    - skohan 4y ago
      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.
      - Rhedox 4y ago
        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.
mkl95 4y ago
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.
- jokoon 4y ago
  Well as you long as developers are being paid big money to rewrite things... The software industry doesn't make a lot of sense.
  - mkl95 4y ago
    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
divingdragon 4y ago
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.)
Rhedox 4y ago
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.
w0mbat 4y ago
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.
hit8run 4y ago
Nice to see that someone does apples job here… plain stupid for devs that they don’t support OpenGL.
- bitwize 4y ago
  Apple is doing what every platform should do: deprecate OpenGL completely. Use DirectX, or whatever low-level API your platform provides.
  - xrobledo84 4y ago
    K
  - badsectoracula 4y ago
    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.
    - bitwize 4y ago
      > OpenGL is easy to use Direct3D is far easier to use. > provides a lot of functionality 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.)
kvark 4y ago
> 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 :)

133 points by coffeeaddict1 4y ago

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.

toun 4y ago
> 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 ..
- Rhedox 4y ago
  > CSGO has a builtin DX to OpenGL translation layer. They're not using Proton or DXVK, it's Linux native OpenGL. It's D3D9 to OpenGL, and it's open source and called ToGL. On Linux you can also opt in to use DXVK by using a launch parameter.
- seba_dos1 4y ago
  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.
  - sylware 4y ago
    It has been the case on elf/linux, and for a while now, csgo has been running flawlessly for a while on vulkan.
flohofwoe 4y ago
It's very likely not for games, but for porting other types of 3D applications. OpenGL hasn't been a popular API for game development since around the late 90's.

samus 4y ago

Zink + MoltenVK can do that too in a pinch, no?

IceWreck 4y ago
I have no exp in this area but wouldnt we loose a lot of performance by having two shims. Application -> OpenGL -> Zinc -> Vulkan -> MoltenVK -> Metal -> Hardware
- bumblebritches5 4y ago
- uluyol 4y ago
  Not necessarily, especially when you factor in limited (human) resources in. Zink has outperformed native GL drivers even though it introduces an extra layer through vulkan. Ideal world, we'd have direct GL to metal or hardware, but implementing a GL driver is a big effort.
  - samus 4y ago
    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.
  - badsectoracula 4y ago
    > 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.

pavlov 4y ago

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.

saagarjha 4y ago
Am I remembering correctly in that it doesn’t support modern OpenGL features, just the really old stuff that the old implementation did?
- tinus_hn 4y ago
  Yes, that’s because it’s deprecated and that’s why you get all these warnings.
  - Rhedox 4y ago
    It's not just about warnings, Apple only supports OpenGL 4.1 which was released in 2011.
    - waynecochran 4y ago
      OpenGL 4 is not the “really old stuff”
      - vetinari 4y ago
        Between 4.1 and 4.6, it changed a lot. Apple never supported extensions for AZDO, for example.
      - Rhedox 4y ago
        It's missing features that D3D11 had in 2009. Compute shaders in particular are a huge feature that GL4.1 doesn't have.
- pavlov 4y ago
  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.

skohan 4y ago

Related: MoltenVK is now compliant with Vulkan 1.2. https://www.phoronix.com/news/MoltenVK-1.2-Vulkan-Apple https://www.phoronix.com/news/MoltenVK-1.2-Vulkan-Apple

SXX 4y ago
Does it now have all features that DXVK need to function? There are no details on their repository: https://github.com/KhronosGroup/MoltenVK/issues/203 https://github.com/KhronosGroup/MoltenVK/issues/203
- Rhedox 4y ago
  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.
  - skohan 4y ago
    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.
    - Rhedox 4y ago
      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.

mkl95 4y ago

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.

jokoon 4y ago
Well as you long as developers are being paid big money to rewrite things... The software industry doesn't make a lot of sense.
- mkl95 4y ago
  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

divingdragon 4y ago

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.)

Rhedox 4y ago

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.

w0mbat 4y ago

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.

hit8run 4y ago

Nice to see that someone does apples job here… plain stupid for devs that they don’t support OpenGL.

bitwize 4y ago
Apple is doing what every platform should do: deprecate OpenGL completely. Use DirectX, or whatever low-level API your platform provides.
- xrobledo84 4y ago
  K
- badsectoracula 4y ago
  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.
  - bitwize 4y ago
    > OpenGL is easy to use Direct3D is far easier to use. > provides a lot of functionality 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.)

kvark 4y ago

> 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 :)