Timothy Lochner

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.

FWIW i create the command lists wide too. A command list per node (per pass)=1 threaded job per. Some nodes get squished into whatever larger ones are around (a single compute shader dispatch, or a resource copy!). Still need to solve going wide on a single render pass though.

I designed all my commands to support going wide, by allocating them ahead of time you can then just fill wide. Man, for some reason I thought nobody would be interested in how I do it. Maybe I should write a blog post? Need something longer form than twitter.