Mastodawn

@dotstdy more like D3D9, because at least D3D11has a small number of immutable state group objects while this new extension seems to go back to a GL-like state soup.

It's like 'one step forward, two steps back' ;)

@dotstdy e.g. dropping the rigid 'all-in-one' PSO model is good, ability to directly bind shaders, also good. But I'm not a fan of the huge list of dynamic state functions which does indeed feel like it's OpenGL all over again :D

Aras Pranckevičius Apr 4, 2023

@floooh @dotstdy next up: a GDC talk on “approaching zero driver overhead in Vulkan” :)

@aras @floooh I'm not really sure what a good model is for that kind of thing though, since almost all that state is actually dynamic. I dunno, do we just write an API where you specify the format of draw calls on the user side? :') Pass a bit field for all the dynamic state you want in your draw packet and then pass that to the driver, packed in a struct?

@dotstdy @aras could work like samplers, very small, very cheap objects which could essentially be reduced to a bit field behind a handle, and set such a state group with a single call.

@dotstdy @aras ...in the beginning I was actually hoping that PSOs are exactly that (essentially just driver-specific render-state bitfields). I didn't quite get the importance of shaders as part of the PSO state, just saw it as the logical next step of merging D3D11's state objects (but interestingly, nobody ever complained about D3D11's state objects?)

@dotstdy @aras ...also one thing I don't quite get in that new Vulkan extension: I thought that at least the blend state is needed upfront for shader compilaton, but it's listed as dynamic state. Does that mean that we're back to shader patching on some platforms? Or is this extension for new GPUs only where blend state is separate from shaders? It's quite confusing tbh.

(edited)

@floooh @aras it's only for GPUs that reasonably support all the state being dynamic. The proposal doc has a section for "what if my hardware really really needs to do do a linking step"

@floooh @aras i think binding the state to objects is really bad because you need to then manage the lifetime of those objects. Pool them, recycle them, delete them at the right times. Just painful busywork. (like with sampler objects, though there's generally few of those, thankfully)

Neil Henning Apr 4, 2023

@dotstdy @floooh @aras right but market pressure will require this to just ship everywhere even if shader patching comes back. That’s the outcome of this (unless somehow 5 years ago the HW vendors that need linking already decided to move away from that requirement…)

@neilhenning @floooh @aras i don't really know the extent of hardware that requires a significant linking step, patching the shader should be totally fine (as it has been in the past anyway) provided it's not awful. It's only mobile GPUs that are going to have big trouble, right?

@neilhenning @floooh @aras ultimately I don't really see any alternative because shaders are not going to get simpler and more monolithic. Next up we should be able to have callable shaders instead of binding them manually! :)

@neilhenning @floooh @aras it's pretty wild that there's a bit in the proposal like "we recommend hardware vendors to move away from models that require linking" though... :')

Neil Henning Apr 4, 2023

@dotstdy @floooh @aras yeah that seems like it was written by the ISVs 😂🤣😇