Right now, if you want to use a GPU, you have to do it through graphics APIs like DirectX or Vulkan. These APIs are meant to be hardware-independent, but more often than not, they are tied to a specific platform (like DirectX for Windows, or Metal for iOS and macOS). The only modern graphics API which was designed to be cross-platform is Vulkan and even it is not supported by every platform. Both iOS and macOS don't support it (you have to use MoltenVK, but that's an API wrapper, not a driver implementation) and I'm assuming that neither PlayStation nor Xbox have support for it.
It seems like we have solved the problem of hardware independence, but we've imposed the (artificial) problem of platform dependence. The hardware is doing the same thing no matter if it's in a Windows system or an Apple system. Wouldn't it be better if each GPU vendor provided their own graphics API?
So, my question is: Why don't we have hardware-specific graphics APIs instead of platform-specific ones?
Here's my reasoning for it...
More work for engine programmers
Let's say you are a game company and you want to make a game using your own game engine. And let's say you want to ship your game on PC and consoles. This means you want to support Windows, Xbox, and PlayStation. macOS and Linux aren't really a concern because not that many people game on them. The graphics APIs for Windows are DirectX and Vulkan (not counting OpenGL), for Xbox its DirectX (DX12 Ultimate technically is the same for Windows and Xbox), and for PlayStation, it's GNM (Sony's own proprietary graphics API). This means that if you wanted to write a rendering engine with as little effort as possible, you would, at the very least, have to support DirectX 12 and GNM.
This doesn't seem that bad until you consider the fact that this is only the bare minimum. Many game engines also support Vulkan on Windows, not to mention that if you want to port your game to Mac or the Nintendo Switch you'll have to support even more APIs.
Additionally, if you are writing a high-end rendering engine and you want to get the most out of your GPU, you'll need to do architecture-specific optimizations to shaders, which means having multiple variations of each shader, FOR EACH graphics API. You could write a shader translator so that you only need to write your shaders once, but then you get into other problems.
More work for driver implementers
On the other side, we have drivers. You have to support OpenGL, DirectX 11, DirectX 12, and Vulkan (all of these are just for Windows). If you provide hardware to Apple you also have to support Metal (although, Apple seem to be making their own hardware now so maybe they're not a concern anymore) and if you provide hardware for consoles, you also have to support their proprietary API. This becomes even worse when you consider the fact that drivers for mobile GPUs (e.g. for laptops and phones) and discrete GPUs are different.
I don't think hardware vendors write a completely different driver for each API+platform+GPU combination, that would be insane! I'm guessing that drivers have their own internal API, or something similar, and each graphics API implementation is just wrapping around that internal API. However, this still leads to a massive amount of software, which ultimately means more bugs and more money spent on more developers.
The (possibly) ideal solution
I think it makes much more sense for hardware vendors to provide their own APIs. These APIs are tailor-made for their own GPUs. If your new GPUs behave differently than the older ones, you can just change the API to better fit the new GPUs instead of giving programmers hacky workarounds for existing APIs. I also think that these APIs should let programmers write in GPU assembly. Of course, I don't think programmers will write in GPU assembly most of the time, however, it gives them more freedom to do architecture-specific optimizations.
One big problem with current graphics APIs is that they are hardware-independent. Why is that a problem? Because it means that everybody has to conform to the same interface. This isn't always bad. A well-designed API can be general enough that it suits everyone's needs, while also not being too restrictive. However, doing this means collaborating with multiple hardware manufacturers, which can take a lot of time. For example, look at how long it took for raytracing to land in Vulkan. The first raytracing cards came out near the end of 2018 and while raytracing was supported in Vulkan soon after, it was only through an NVIDIA-exclusive extension. The official, cross-vendor extension didn't come until 2020.
Granted, I don't think current graphics APIs should be removed entirely. I think that the responsibility of implementing them should fall in the hands of the people who design/provide them, like Microsoft, Apple, or the Khronos Group, and not in the hands of hardware vendors. Instead of having custom implementations for each API in the driver, APIs like DirectX will be implemented at the application level using the publicly-available hardware-specific APIs provided by GPU vendors. This way, programmers who don't care a lot about performance or cutting-edge features, will still be able to use the current APIs.
The end (Finally!)
This seems like something someone working on graphics APIs would have thought of and since it seems like this approach is much better than the current one, I can't think of a reason why it hasn't happened yet. I expect that there must be a pretty good reason why this isn't the way we do things other than just "we've always done things this way so why change it now", I just can't think of it!
Edit: After reading the responses, I think I may have explained some things a bit poorly. In particular, I'm not suggesting that we remove all abstractions and have APIs that are extremely low level. They should still live in user-land and take advantage of things like sharing resources, scheduling, and TDR. What I'm suggesting is APIs similar to Vulkan or DirectX in terms of abstraction, but that are tied to specific hardware, not a specific platform. Anyway, thank you for the responses!