Timothy Lochner

I’m a render graph fan. The ability to statically analyze graphics work and do per backend & per platform optimization, and also handle tedious error prone things (resource transitions!) is really cool.

Was on a project where we used a tender graph to automate transitions. The incredible thing was that it was not a lot of work to automate, but reduced tons of complexity around transitions in user code.

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.