[dagmx]

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?

[hmry]

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.

[dagmx]

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.

[pjmlp]

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

[my123]

On Snapdragon X and later, native Vulkan and OpenCL UMDs are provided out of the box

GLon12 is still used for OpenGL however

[pjmlp]

Interesting to know, although by Qualcom, still not a Windows first party API.

[pjmlp]

And after a second look, they are built on top of DirectX anyway.

> Along with a kernel-mode display driver, graphics hardware vendors must also write a user-mode display driver (UMD) for their display adapters. The UMD is a dynamic-link library (DLL) that the Direct3D runtime loads.

https://learn.microsoft.com/en-us/windows-hardware/drivers/d...

[dlivingston]

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.

[pjmlp]

Except that the APIs that are first party, have great experiences on the vendor SDK, whereas the OEM ones are an hit and miss in regards to IDE integration and graphical debugging, and have zero high level frameworks to improve the dev experience.

And you don't install Khronos stuff on console devkits.

Although as usual, NVidia tends to be the exception.

[flohofwoe]

> and a legacy OpenGL driver too

FWIW, the OpenGL 'driver' on macOS and iOS is just an layer on top of Metal for many years now - e.g. same thing as ANGLE, DXVK or MoltenVk, just maintained directly by Apple.

The important difference both of D3D and Metal compared to Vulkan is that Vulkan lacks steering and vision (e.g. it's not a technical problem at all but a cultural/organizational).

Vulkan development looks like GPU vendors just come up with random Vulkan extensions which then from time to time are blessed by Khronos and elevated into the core API.

This "throwing shit at the wall and see what sticks" approach was already the biggest problem in GL (and my naive younger self thought that this obvious problem would be fixed with Vulkan - alas it turned out that this was the one thing that Khronos didn't change). This is really not how a 3D API should be designed.

[fc417fc802]

> Operating systems do not implement graphics APIs for GPUs.

Mesa has entered the chat. Granted that with the amount of functionality that's stuffed into opaque firmware blobs these days you can make a reasonable argument that a nontrivial portion of any API is ultimately implemented by the firmware authors.