Comment by dvdkon
9 days ago
I don't see the problem. There have been lower-level APIs in the graphics stack for a long time (e.g. Mesa's Gallium), only now they are standardised and people are actually choosing to use them. It's not like higher-level APIs don't exist now, OpenGL is still supported on reasonable platforms and WebGPU has been usable from native code for some time.
As for true portability of those low-level APIs, you've basically got Apple to blame (and game console manufacturers, but I don't think anyone expected them to cooperate).
> you've basically got Apple to blame
Yeah, that's the thing that really irks me. WebGPU could have been just a light wrapper over Vulkan like WebGL is (or was, it's complicated now) for OpenGL. But apple has been on a dumb war with Khronos for the last decade which has made everything more difficult.
So now we have n+1 low level standards for GPU programming not because we needed them, but because 1 major player is obstinate.
That would be a problem indeed if Metal wouldn't be a much better designed API than Vulkan. As it stands, Vulkan would do good to 'steal' a few ideas from Metal to make the Vulkan API more convenient to use without sacrificing too much performance.
Or you could build on top of Vulkan and add the convenience features into middleware.
Being simpler is an advantage. It means that 3rd party GPU drivers can more simply implement the interface correctly.
3 replies →
Your last paragraph is fairly revisionist to me.
How is Apple solely to blame when there are multiple parties involved ? They went to Khronos to turn AMD’s mantle into a true unified next gen APi. Khronos and NVIDIA shot them down to further AZDO OpenGL. Therefore Metal came to be and then DX12 followed and then Vulkan when Khronos realized they had to move that way.
But even if you exclude Metal, what about Microsoft and D3D? Also similarly non-portable. Yet it’s the primary API in use for non-console graphics. You rarely see people complaining about the portability of DX for some reason…
And then in an extremely distant last place is Vulkan. Very few graphics apps actually use Vulkan directly.
Have you tried writing any of the graphics APIs?
People don't complain about DX portability because Windows has first-party support for Vulkan and OpenGL, unlike macOS. Also, since the XBox also uses DirectX, you get two birds with one stone. And third, you aren't forced to use Microsoft hardware to develop for DirectX (these days, you don't even have to use Windows.)
Basically, people are mad that you need to buy Apple hardware, use Apple software (macOS), Apple tooling (Xcode), just to develop graphics code for iOS and macOS. At least you don't also need to use Apple language (Swift) to use Metal, though I don't have any first-hand experience with their C++ bindings so I can't judge if it's a painful experience or not.
Windows has third party support for Vulkan and OpenGL. It is NOT first party.
It's definitely more convenient than Mac because it is provided by the driver and so you can almost always guarantee they exist, but Microsoft themselves do not provide them. On Mac, for Vulkan you can use MoltenVK which is also third party, and bundle it in the app, though definitely less convenient and less fully featured.
Regarding Xbox, that's a bit of an odd point because you might as well include iOS as a platform at that point which is a bigger gaming platform than Xbox. At least iOS uses the same Metal as Mac, while Xbox does vary in some ways from Windows. Granted, iOS gaming is much more casual oriented but there are some AAA games as well.
Regarding Swift, Metal has always been ObjC first not swift first. The C++ bindings are just for convenience, but you've never been bound to Swift even before they existed. Regarding Xcode, that's only to get the toolchain or if you need instrumentation. You don't need to use Xcode to actually develop things, this is no more a burden than needing Visual Studio on Windows.
Windows doesn't have first party support for OpenGL and Vulkan.
It has a plugglable driver system, leftover from the Windows NT/OpenGL 1.1 days called ICD, that driver vendors use to add their OpenGL and Vulkan drivers.
https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
In some subsystems like UWP, or Windows on ARM, ICDs aren't supported, and OpenGL/Vulkan have to be mapped on top of DirectX.
https://devblogs.microsoft.com/directx/announcing-the-opencl...
3 replies →
To correct some misconceptions for readers:
Operating systems do not implement graphics APIs for GPUs. These are created by the GPU manufacturer themselves (AMD, Nvidia, etc.). This includes DirectX drivers, both user-space and kernel-space drivers.
Graphics APIs like DirectX and Vulkan are better thought of as (1) a formal specification for GPU behavior, combined with (2) a small runtime. The actual DX/VK drivers are thin shims around a GPU manufacturer's own driver API.
For AMD, the DirectX / Vulkan / OpenGL graphics drivers share a common layer called "PAL" which AMD has open sourced: <https://github.com/GPUOpen-Drivers/pal>
Apple really isn't that different here: they leave the graphics manufacturers to implement their own drivers. Unfortunately, Apple is the sole graphics manufacturer for their OS, and they've chosen to only implement Metal drivers for their GPUs (and a legacy OpenGL driver too).
It's not that big of a deal though, because Vulkan is supported on macOS through the MetalVK project, which wrap the Vulkan API around the Metal API. And projects like vkd3d wrap the DirectX 12 API around the Vulkan API, which is then wrapped around the Metal API. This is how you're able to run Windows games on Mac via the Game Porting Toolkit or CrossOver, btw.
3 replies →