Developers should put their money where there mouths are and use an API not backed by Microsoft or be at their mercy of their whims ...
Developers are bumbling in the dark, releasing stutter infested games, unable to properly manage RAM and VRAM, and even unable to push performance harder.
As a long time gamer, DX12 represented the single most cause of problems for modern PC gaming in history, we have multiple dedicated thread for the mess DX12 causes alone, we have multiple developers testifying that coding for DX12 is bad, we have a former member of the DX12 board testifying here on the forums that they did major mistakes with DX12. It's baffling. Your claimed future is non existent.
And here it's confirmed by Khronos themselves:
Many of these assumptions have since proven to be unrealistic.
The entire premise is screwed up hard. Here Khronos explains why (in summary Vulkan/DX12 constrain gaming dynamism).
On the application side, many developers considering or implementing Vulkan and similar APIs found them unable to efficiently support important use cases which were easily supportable in earlier APIs. This has not been simply a matter of developers being stuck in an old way of thinking or unwilling to "rein in" an unnecessarily large number of state combinations, but a reflection of the reality that the natural design patterns of the most demanding class of applications which use graphics APIs — video games — are inherently and deeply dependent on the very "dynamism" that pipelines set out to constrain.
And here Khronos admits it all in one paragraph, they simply admit that problems Vulkan and DX12 sough to solve, are transferred to the game instead of the driver, without giving developers the necessary knowhow and tools to solve it (unlike the driver which handled it gracefully), thus directly causing the stutter problem (shader compilation, the very topic of this thread).
As a result, renderers with a choice of API have largely chosen to avoid Vulkan and its "pipelined" contemporaries, while those without a choice have largely just devised workarounds to make these new APIs behave like the old ones — usually in the form of the now nearly ubiquitous hash-n-cache pattern. These applications set various pieces of "pipeline" state independently, then hash it all at draw time and use the hash as a key into an application-managed pipeline cache, reusing an existing pipeline if it exists or creating and caching a new one if it does not. In effect, the messy and inefficient parts of GL drivers that pipelines sought to eliminate have simply moved into applications, except without the benefits of implementation specific knowledge which might have reduced their complexity or improved their performance.
They also admit what we've all suspected from the beginning: DX12/Vulkan
DO NOT reduce CPU overhead, but actually directly
INCREASE it.
On the driver side, pipelines have provided some of their desired benefits for some implementations, but for others they have largely just shifted draw time overhead to pipeline bind time (while in some cases still not entirely eliminating the draw time overhead in the first place). Implementations where nearly all "pipeline" state is internally dynamic are forced to either redundantly re-bind all of this state each time a pipeline is bound, or to track what state has changed from pipeline to pipeline — either of which creates considerable overhead on CPU-constrained platforms.
Worse yet, these "low level" APIs (quottion marks are Khronos's not mine), actually limited certain GPU archs from accessing their full potential.
For certain implementations, the pipeline abstraction has also locked away a significant amount of the flexibility supported by their hardware, thereby paradoxically leaving many of their capabilities inaccessible in the newer and ostensibly "low level" API, though still accessible through older, high level ones. In effect, this is a return to the old problem of the graphics API artificially constraining applications from accessing the full capabilities of the GPU, only on a different axis.
Even consoles didn't fare well with these "low level" APIs. We finally heard it from an official source, that these API caused havok among games, their benefits were overshadowed by their mistaken assumptions and terrible execution. I expect Microsoft to follow the lead of Khronos (they already announced some updates coming to DX12 soon).
The Vulkan API Specification and related tools. Contribute to KhronosGroup/Vulkan-Docs development by creating an account on GitHub.
github.com
