|
|
|
|
|
by MindSpunk
14 days ago
|
|
You could try and do this today, to an extent. You could skip Vulkan and talk to the kernel driver in your app directly. vulkan-1.dll is regular user-mode code, there's nothing special about it. Nobody does this because it's a colossal amount of work for a small pay off. Your code becomes completely un-portable. Exposing the hardware primitives directly is not an abstraction, so in reality all you end up having to do is implement your own Vulkan instead if you want to support more than 1 GPU. And your app won't work on new GPUs without shipping an update. If you want a common API to target all GPUs you get Vulkan again. GPU hardware is too diverse to go much lower than Vulkan without just moving the hardware abstraction into your app instead. |
|
Indeed, Vulkan is the step in the right direction because it largely follows the path I was outlining, but it's still got ways to go because it assumes things and mixes in abstractions of its own, but more importantly because through its mere existence and the way how it is positioned it occupies space where nothing else has room to exist. Point being that Vulkan still requires you to play by someone else's rules of how they thought the API should work, which is detrimental in principle to "exokernels". So this is about exokernels, not about going full retard and programming a 100 billion transistor GPU on your own to draw pixels.
In case I wasn't able to elaborate: Vulkan looks like the part, it's certainly a sign of the people who started with the likes of DirectX have learned about the dead-end model they thought would work and are now finally seeing the "light", and I am arguing that whatever abstracts the GPU should just pretend it's a generic massively parallel computation unit with addressable memory of multiple kinds and places and so on -- without assuming it's for "graphics" (which it is less about today than ever before, what with AI etc).