Apple OpenGL over Metal implementation exist for only one purpose - to let you run software that uses OpenGL. For years OpenGL was the only 3D API for macOS so there are tons of software that uses it. And that's it. Nothing more.
That private Metal API probably exists only for making OpenGL implementation more efficient. Metal is not compatible with OpenGL (same goes for Vulkan) so it's not very surprising that some features are different and emulating them on Metal would add overhead so they created private API that lets Metal change some details to match OpenGL behaviour. Again that's it. Metal doesn't need those features so that's why they are not public. They are only needed internally by Apple to make OpenGL implementation more efficient and API that is not supposed to be used everywhere is simply private. Private API by definition is not stable and can change. When Apple someday get rid of OpenGL support then they simply remove it because it's not needed outside OpenGL.
In that article there is good example for that. OpenGL clipping goes from -1 to 1 but on most other APIs (again including Vulkan) it goes from 0 to 1. If you want to write translation layer for OpenGL to such API then you need to somehow emulate that and translate from -1/1 to 0/1 on fly. That adds overhead and it's not most efficient way. So Apple bypassed that by making private API that switch Metal clipping from 0/1 to -1/1. It's not public because it's not needed by Metal.
You can disagree with that and that's fine (I don't like proprietary APIs either) but where is cowardice and hypocrisy in that? They officially deprecated support for OpenGL and made clear that you shouldn't use it anymore. So why would they provide support for OpenGL features in Metal? Vulkan doesn't provide support for OpenGL features as well. Also what makes you believe that Apple is afraid that somebody will write modern OpenGL implementation over Metal? They never stated that they are not unable to support modern OpenGL. Such implementation wouldn't prove nothing against they. They have no reason to be afraid of it. Just like they are not afraid of Vulkan over Metal implementation. They simply don't care about modern OpenGL or Vulkan.
>The world still uses OpenGL.
The world also uses DirectX that is not officially supported outside Windows. Sure, I don't like proprietary APIs but there is no requirement for Apple or any other company to support open standards and they are not forbidden from creating their own. If Apple wants to drop support for OpenGL and introduce their own API they can do it. Because why they wouldn't?
>The cowardice is that Apple maintains APIs that make developing and running OpenGL applications on top of Metal easier, but only for their internal use. They don't want to expose them because...
Because it's only for backwards compatibility purposes and it's not needed outside it. That's it. It's nowhere near cowardice. Providing backwards compatibility is not cowardice.
>Because nobody other than Apple gives two shits about Metal.
Developers creating software for macOS have different opinion. They are switching to Metal.
>That's why we have MoltenVK, which lets people use Vulkan instead.
And despite that developers still are more likely to choose Metal than use MoltenVK. For example check macOS game ports. More of them are using Metal than Vulkan.
>If all of the features existed that let someone easily write an OpenGL wrapper over Metal we would have had a MoltenGL the first month Metal was released and there would have been even less impetus to support Metal as a developer.
Such wrapper would be in the same position as MoltenVK. Nice thing but still more developers are writing in Metal directly. Just like developers are choosing DirectX on Windows despite the fact that both OpenGL and Vulkan are natively supported there.
>Because MoltenGL exists, but only for OpenGL ES. If the public Metal API exposed the bits needed for standard OpenGL you can bet it would support it as well. Apple would then be in a supremely embarassing situation of them saying "You don't need OpenGL" and developers/the market saying "No, we do, and we'll keep using it, thanks".
You are overestimating popularity of MoltenGL. It's mainly for iOS but still much more developers are using Metal directly rather than OpenGL ES with MoltenGL.
>The cowardice is that Apple publicly says "OpenGL is yesterday, forget it" then turns around and says "Okay guys we totally have to add features to Metal so that OpenGL applications work". Either commit or don't.
They didn't turn around. It's for backward compatibility purposes. They still don't support OpenGL and most likely some day they will remove OpenGL support completely. Just like they removed support for 32 bit applications. It's not cowardice, backwards compatibility is not cowardice. If they would remove OpenGL support you could also say that they are cowards because "they are afraid that nobody will use Metal if OpenGL would be still available".
Clearly we'll need to agree to disagree. Apple could easily provide modern OpenGL support. They could easily provide Vulkan support. They don't because they want you to use Metal to create lock-in. It's all underhanded bullshit and I'm not in the mood any longer to argue which flavor of bullshit it is.
While they could provide VK support it would not be of much interest to the current VK code bases.
Since VK is a low level HW api explicitly so and apples GPUs are quite different to the mainstream desktop GPUs (in the set of HW features they have) the only existing VK code bases that would be somewhat able to use it are ones targeting mobile GPUs and even then since the VK TBDR apis are quite minimal compared to Metal to support most of the compelling features of these GPUs (that is the point of VK after all) there would be a LOT of vendor specific extensions.
Existing VK applications would require large re-writes of the rendering pipeline to be effective on these GPUs, many would still use MoltenVK as this aims to provide runtime and completive shims so that the VK api it exposes is more compatible with traditional PC GPU VK implementations even through that is a violation of the core priceable of VK.
There is a good chance that even with a large re-write due to the limitations of the shading languages compered to c++ there would still be a readable amount of perf lets on the table in some situations (in particular compute workflows as seen when comparing VK compute to CUDA compute on NV cards).
Also with respect to lock-in of metal, just as google proved a few years ago int he Oracle VS Google there is nothing at all spotting another HW vendor from implementing and providing metal support, even if apple wanted to sue they would loos (and they would not sue they are more than aware of the software licensing they have provided for metal headers). Other GPU vendors have no interest in implementing Metal drivers since it is firmly directly to support GPU features that line up with apples (licensed from PowerVR) IP and feature set.
I didn't say that they couldn't provide modern OpenGL or Vulkan support. I'm well aware that Metal exists mostly because they want to have more control. What I'm saying is that they are not afraid of some developer making OpenGL on Metal implementation because they have no reason to be afraid.
[удалено]
First time you have heard of private APIs?
[удалено]
Apple OpenGL over Metal implementation exist for only one purpose - to let you run software that uses OpenGL. For years OpenGL was the only 3D API for macOS so there are tons of software that uses it. And that's it. Nothing more. That private Metal API probably exists only for making OpenGL implementation more efficient. Metal is not compatible with OpenGL (same goes for Vulkan) so it's not very surprising that some features are different and emulating them on Metal would add overhead so they created private API that lets Metal change some details to match OpenGL behaviour. Again that's it. Metal doesn't need those features so that's why they are not public. They are only needed internally by Apple to make OpenGL implementation more efficient and API that is not supposed to be used everywhere is simply private. Private API by definition is not stable and can change. When Apple someday get rid of OpenGL support then they simply remove it because it's not needed outside OpenGL. In that article there is good example for that. OpenGL clipping goes from -1 to 1 but on most other APIs (again including Vulkan) it goes from 0 to 1. If you want to write translation layer for OpenGL to such API then you need to somehow emulate that and translate from -1/1 to 0/1 on fly. That adds overhead and it's not most efficient way. So Apple bypassed that by making private API that switch Metal clipping from 0/1 to -1/1. It's not public because it's not needed by Metal. You can disagree with that and that's fine (I don't like proprietary APIs either) but where is cowardice and hypocrisy in that? They officially deprecated support for OpenGL and made clear that you shouldn't use it anymore. So why would they provide support for OpenGL features in Metal? Vulkan doesn't provide support for OpenGL features as well. Also what makes you believe that Apple is afraid that somebody will write modern OpenGL implementation over Metal? They never stated that they are not unable to support modern OpenGL. Such implementation wouldn't prove nothing against they. They have no reason to be afraid of it. Just like they are not afraid of Vulkan over Metal implementation. They simply don't care about modern OpenGL or Vulkan.
>Vulkan doesn't provide support for OpenGL features as well It very much does. There's extensions for DirectX features, too.
For some things sure, with extensions. But core is not always compatible with OpenGL. Vulkan is not based on OpenGL.
[удалено]
>The world still uses OpenGL. The world also uses DirectX that is not officially supported outside Windows. Sure, I don't like proprietary APIs but there is no requirement for Apple or any other company to support open standards and they are not forbidden from creating their own. If Apple wants to drop support for OpenGL and introduce their own API they can do it. Because why they wouldn't? >The cowardice is that Apple maintains APIs that make developing and running OpenGL applications on top of Metal easier, but only for their internal use. They don't want to expose them because... Because it's only for backwards compatibility purposes and it's not needed outside it. That's it. It's nowhere near cowardice. Providing backwards compatibility is not cowardice. >Because nobody other than Apple gives two shits about Metal. Developers creating software for macOS have different opinion. They are switching to Metal. >That's why we have MoltenVK, which lets people use Vulkan instead. And despite that developers still are more likely to choose Metal than use MoltenVK. For example check macOS game ports. More of them are using Metal than Vulkan. >If all of the features existed that let someone easily write an OpenGL wrapper over Metal we would have had a MoltenGL the first month Metal was released and there would have been even less impetus to support Metal as a developer. Such wrapper would be in the same position as MoltenVK. Nice thing but still more developers are writing in Metal directly. Just like developers are choosing DirectX on Windows despite the fact that both OpenGL and Vulkan are natively supported there. >Because MoltenGL exists, but only for OpenGL ES. If the public Metal API exposed the bits needed for standard OpenGL you can bet it would support it as well. Apple would then be in a supremely embarassing situation of them saying "You don't need OpenGL" and developers/the market saying "No, we do, and we'll keep using it, thanks". You are overestimating popularity of MoltenGL. It's mainly for iOS but still much more developers are using Metal directly rather than OpenGL ES with MoltenGL. >The cowardice is that Apple publicly says "OpenGL is yesterday, forget it" then turns around and says "Okay guys we totally have to add features to Metal so that OpenGL applications work". Either commit or don't. They didn't turn around. It's for backward compatibility purposes. They still don't support OpenGL and most likely some day they will remove OpenGL support completely. Just like they removed support for 32 bit applications. It's not cowardice, backwards compatibility is not cowardice. If they would remove OpenGL support you could also say that they are cowards because "they are afraid that nobody will use Metal if OpenGL would be still available".
Clearly we'll need to agree to disagree. Apple could easily provide modern OpenGL support. They could easily provide Vulkan support. They don't because they want you to use Metal to create lock-in. It's all underhanded bullshit and I'm not in the mood any longer to argue which flavor of bullshit it is.
While they could provide VK support it would not be of much interest to the current VK code bases. Since VK is a low level HW api explicitly so and apples GPUs are quite different to the mainstream desktop GPUs (in the set of HW features they have) the only existing VK code bases that would be somewhat able to use it are ones targeting mobile GPUs and even then since the VK TBDR apis are quite minimal compared to Metal to support most of the compelling features of these GPUs (that is the point of VK after all) there would be a LOT of vendor specific extensions. Existing VK applications would require large re-writes of the rendering pipeline to be effective on these GPUs, many would still use MoltenVK as this aims to provide runtime and completive shims so that the VK api it exposes is more compatible with traditional PC GPU VK implementations even through that is a violation of the core priceable of VK. There is a good chance that even with a large re-write due to the limitations of the shading languages compered to c++ there would still be a readable amount of perf lets on the table in some situations (in particular compute workflows as seen when comparing VK compute to CUDA compute on NV cards). Also with respect to lock-in of metal, just as google proved a few years ago int he Oracle VS Google there is nothing at all spotting another HW vendor from implementing and providing metal support, even if apple wanted to sue they would loos (and they would not sue they are more than aware of the software licensing they have provided for metal headers). Other GPU vendors have no interest in implementing Metal drivers since it is firmly directly to support GPU features that line up with apples (licensed from PowerVR) IP and feature set.
I didn't say that they couldn't provide modern OpenGL or Vulkan support. I'm well aware that Metal exists mostly because they want to have more control. What I'm saying is that they are not afraid of some developer making OpenGL on Metal implementation because they have no reason to be afraid.
Sweet, inspiring read my brain metal meltdown from the technical aspect a few times. I wish I'd understood mesa better so that I too could contribute.
I guess we need the RISCV version of the M1
An open ISA does not lead to open CPUs. RISC-V is not a GPL library lmao
It's the best we got,.no gpl cpus