Timothy Lochner

That's where i'm at and i like it a lot. The system gives me a command list to fill out and descriptor tables for anything i asked for. Everything is in the correct state, just do the work. Plenty more benefits to be had, but it's already really enjoyable to work with.

It feels like the obvious right way to go, but i think it's early in the wave yet.

How do you specify the graph? Our system (have had for many years) generates a list of render commands, then we can build dependency graph in rendering back-end (per frame) if necessary. Have always found retained graph code clunky to work with.

Something we're trying is having render passes specify all their dependencies up front - resources needed, dependencies on other pass resources, etc. Then there's a "compile" step that processes those dependencies and orders passes accordingly, inserts barriers, etc.

The idea being that graphics settings could change and affect the graph, but that it would only require a one-time "recompile" on the next frame. All of this happening on the front-end rather than at the back post-submission. Pie in the sky and all that though, not proven yet.

I've had similar thinking. One thing too, I don't like that a node of commands can be so diverse. It temps you to have one node that does an UpdateResource command right before a Draw command. Ideally, they're different nodes, easier to sort into queues.

Basically, finding the right abstraction that is easy up front and lightened the load on the back end.

I have a feeling this is going to depend a lot on engine architecture, details of the target rendering load, and engine team member opinions.