[hackrmn]

I last wrote 3-D rendering code using hardware in 2005 or so. It was DirectX 11 or 12, I don't recall. I thought it was quite a mountain to climb. For my part, I grew up _implementing_ rendering pipelines, so I always had this sour taste of needing to learn someone elses (Microsoft, in this case) idea of how to render 3-D scenes -- using their concepts, even if they were industry standard (shaders etc). Meaning that somewhere inside their APIs are fundamental abstracts I _do_ find, well, accepted terms. After all, I am not arguing against using integration in maths as being useful. There's practicalities.

What am I getting at?

Well, if you take the "no graphics API" to its logical conclusion, then we should strive to remove everything that is "graphics" from it altogether. Reading the article linked and the article the former links in turn ("No Graphics API"), there's still an ungodly mix of graphics rendering _specifics_ and I think these too will start rotting "sooner rather than later".

Having grown up on matrix operations and optimisations that often venture into territory where they _lose_ resemblance to outright _graphics_ pipeline they originally modeled, I am of the firm opinion the logical conclusion I am advocating for, is a sensible one.

To explain with an analogy -- I think we should adopt the "exokernel" approach to GPU hardware. That means just exposes the hardware constructs without trying to fit these into any form of a common denominator (between AMD, NVidia and Intel), and have software specific to each glossing over the abstractions.

Before you say "well, that's exactly what DirectX, Metal and even Vulkan, did!", the key difference is not the encapsulation itself, but its form, the "how" of it.

An exokernel, for instance, does not expose or provide a memory manager (referring to use of MMUs), or give you a `malloc`. It simply exposes the paging mechanism, and you take it from there. If you need a high-level API and/or cannot be bothered to page things in your little command line application -- a fair concern -- you rely on middleware, aka "libOS" in the original, MIT's terminology, a library by any other name -- to provide `malloc` so you don't have to cry over the bare-bones exokernel.

The point I am making is that as the exokernel software (and libraries that would complement it) just exposes the GPU hardware, there is more flexibility to how to use it without "cramming round shapes into square holes" -- a bane of graphics programming _and_ especially optimisation there, that has plagued the entire field since 3dfx' days. Library authors can wrangle API design without touching the hardware or working _around_ it, while hardware vendors can tune subsequent chips to generic computing -- it's the way it's going anyway, except that they won't have to coordinate closely with software writers -- the dependency will go strictly one way -- from library to "GPU exokernel" authors to hardware manufacturers, and never the other way around (ideally). Every link in the chain has more flexibility then.

Practically, we're talking about a generic massively parallel processing unit with tons of addressable memory of different latency (system RAM, on-board RAM, on-chip RAM / L0-level stuff) exposed with a zero-cost abstraction layer known as an "exokernel". DirectX / Vulkan etc compatibility implemented strictly in software over the "exokernel". Those who want their retained mode or whatever else that doesn't require them to deal with cache thrashing issues, can use that, while those who like to holistically optimise and/or Unity / Unreal Engine developers proper, can use the exokernel by writing libraries for it, or outright affect the exokernel itself as new hardware is put on the market.

Sorry for the wall of text. This is from someone who started with implementing solid-painted triangle and polygon rasterisation, then Phong and Gourad shading using an Intel 386...

P.S. This isn't AI slop (although you're obviously free to feel it reads like one), I just like to use the em-dash.

[MindSpunk]

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.

[hackrmn]

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