[HN Gopher] MGL - OpenGL 4.6 on Metal
___________________________________________________________________
MGL - OpenGL 4.6 on Metal
Author : coffeeaddict1
Score : 120 points
Date : 2022-10-29 11:27 UTC (11 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| sylware wrote:
| 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.
| flohofwoe wrote:
| 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.
| toun wrote:
| > 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 ..
| seba_dos1 wrote:
| 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 wrote:
| It has been the case on elf/linux, and for a while now,
| csgo has been running flawlessly for a while on vulkan.
| Rhedox wrote:
| > 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.
| Rhedox wrote:
| 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.
| mkl95 wrote:
| 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 wrote:
| 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 wrote:
| 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
| w0mbat wrote:
| 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.
| divingdragon wrote:
| 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.)
| samus wrote:
| Zink + MoltenVK can do that too in a pinch, no?
| IceWreck wrote:
| 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
| uluyol wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| bumblebritches5 wrote:
| samus wrote:
| 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.
| pavlov wrote:
| 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.
| [deleted]
| w0mbat wrote:
| Yes the nagging is annoying. I finally added this to my prefix
| header. #define GL_SILENCE_DEPRECATION 1
| ranger_danger wrote:
| VSync under OpenGL is also currently broken on OSX. It broke in
| 12.0, then was fixed in 12.1, and is now broken again in 13.0.
|
| https://github.com/glfw/glfw/issues/1990
| saagarjha wrote:
| Am I remembering correctly in that it doesn't support modern
| OpenGL features, just the really old stuff that the old
| implementation did?
| flohofwoe wrote:
| It's GL 4.1 Core Profile (which was specced in 2010), in
| "OpenGL years" that's still pretty new ;)
| bl0b wrote:
| Yeah.. no compute shaders though, among other things
| tinus_hn wrote:
| Yes, that's because it's deprecated and that's why you get
| all these warnings.
| Rhedox wrote:
| It's not just about warnings, Apple only supports OpenGL
| 4.1 which was released in 2011.
| waynecochran wrote:
| OpenGL 4 is not the "really old stuff"
| Rhedox wrote:
| It's missing features that D3D11 had in 2009.
|
| Compute shaders in particular are a huge feature that
| GL4.1 doesn't have.
| vetinari wrote:
| Between 4.1 and 4.6, it changed a lot.
|
| Apple never supported extensions for AZDO, for example.
| pavlov wrote:
| 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.
| waynecochran wrote:
| No... I used to do a lot of OpenGL programming and AppKit
| supported a fairly modern version... Apple deprecated it and
| it has really sucked for me.
| Rhedox wrote:
| 4.1 is not a fairly modern version. That was released in
| 2011 and doesn't even have compute shaders which D3D11 had
| in 2009.
| pavlov wrote:
| So what? There are plenty of applications that just
| render graphics and don't need compute shaders.
| hit8run wrote:
| Nice to see that someone does apples job here... plain stupid for
| devs that they don't support OpenGL.
| bitwize wrote:
| Apple is doing what every platform should do: deprecate OpenGL
| completely. Use DirectX, or whatever low-level API your
| platform provides.
| badsectoracula wrote:
| 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 wrote:
| > 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.)
| xrobledo84 wrote:
| K
| kvark wrote:
| > 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 :)
| skohan wrote:
| Related: MoltenVK is now compliant with Vulkan 1.2.
|
| https://www.phoronix.com/news/MoltenVK-1.2-Vulkan-Apple
| SXX wrote:
| 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
| Rhedox wrote:
| 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 wrote:
| 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 wrote:
| 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.
| [deleted]
___________________________________________________________________
(page generated 2022-10-29 23:01 UTC)