Hacker News new | ask | show | jobs
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.

1 comments

I think you missed the main point of my argument -- you, the game developer, aren't programming the hardware directly or through the kernel -- you are using a common abstraction in a competing set of abstractions that don't require their vendors to beg for crumbs from the likes of NVidia because the dependency only goes the other way -- NVidia publishes an "exokernel driver" that merely exposes the capabilities of the hardware without assumptions about how to best use it. Fundamentally it's not even needed beyond a _specification_ since the hardware is fundamentally exposed through ports and addressable memory mapping(s), but since Nvidia does closed-source and closed-hardware the latter is not going to happen so kernel driver it is. You, the game developer, don't use it directly, you rely on middleware (like Vulkan) and/or middleware on top of that middleware and so on -- until you are left with an API you are comfortable using.

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