Timothy Lochner

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.

We also generate rendering commands, but each command is submitted with a dependency list. So you can declare nodes up front, then fill their commands out of order (ideal for MT engines). The dependency graph is just whatever the dependencies were submitted as.

I actually like the idea of a retained graph, but it requires more work to set up, IMO, and I’m not yet sure about any benefits. Not retained makes it have an “ingui feel” and that’s quite liberating.

I keep getting stuck on the edge cases: what if the graphics settings change? What if you go into a different rendering mode? Generating everything every frame works well.

We generate our command lists in parallel, then submit them in-order to the back-end that does some re-ordering/shuffling/instancing based on the back-end and then goes wide again to submit. Dependencies are explicit, but sometimes a lot of data to sort through.