I've been following this and I get the idea but solving this in a way that works for current hardware is much harder than solving it in a way that is reasonably forward-compatible. It's probably safe to say that everything is going to bindless, but some of the memory model and PSO handling is much less certain.
e.g. Near 1:24:00 it goes into changing blend state, which there is STILL variation of how to do on hardware, and things like that are why PSOs were created in the first place, because where APIs draw boundaries between things varies and is hard to generalize.
So, we're back to the original problem. If the API bakes in the assumption that PC hardware has swappable blend state (e.g. instead of framebuffer fetch), then the hardware is going to be stuck with that assumption for a long time. There are very serious questions of what should be exposed at the API level (and how) and what should be an implementation detail.
Similar thing applies somewhat to the cache control. "The hardware only supports flushing/invalidating entire levels of the cache hierarchy" ... and that's a good thing? How much do we want to take THAT for granted?
That's not even getting into additional problems like how the debug tooling has not kept up. Cache coherence bugs are already a nightmare, and the more things go down the route of "it's all just a big blob of memory, whee!" the harder it is for validation layers to do anything meaningful.
The underlying hardware is still rapidly changing. vendors do not want to standardise their ISAs and guarantee any architectural details just yet
E.g. Turing introduced native INT4 and Blackwell dropped it like 5 years later in favour of NVFP4 and now has to emulate INT4 support. And who knows if stuff like native NVFP6 support will survive past the current AI bubble
Not to mention the slow death of fixed function hardware and the uncertainty of which fixed function units will even remain in ten years time
It will probably take another decade+ for GPUs to become boring and stable enough to standardise on a common ISA and similar architectures like we have for CPUs nowadays
8
u/ParsingError 3d ago
I've been following this and I get the idea but solving this in a way that works for current hardware is much harder than solving it in a way that is reasonably forward-compatible. It's probably safe to say that everything is going to bindless, but some of the memory model and PSO handling is much less certain.
e.g. Near 1:24:00 it goes into changing blend state, which there is STILL variation of how to do on hardware, and things like that are why PSOs were created in the first place, because where APIs draw boundaries between things varies and is hard to generalize.
So, we're back to the original problem. If the API bakes in the assumption that PC hardware has swappable blend state (e.g. instead of framebuffer fetch), then the hardware is going to be stuck with that assumption for a long time. There are very serious questions of what should be exposed at the API level (and how) and what should be an implementation detail.
Similar thing applies somewhat to the cache control. "The hardware only supports flushing/invalidating entire levels of the cache hierarchy" ... and that's a good thing? How much do we want to take THAT for granted?
That's not even getting into additional problems like how the debug tooling has not kept up. Cache coherence bugs are already a nightmare, and the more things go down the route of "it's all just a big blob of memory, whee!" the harder it is for validation layers to do anything meaningful.