GDC DirectX tutorial...Stateless Renderer

The last few proprietary renderer's that I've worked on have completely abstracted away the underlying API to the point where draw-calls are stateless - it seems to be a fairly common design decision. IMO, having the rendering API act like a giant state machine is not a good idea -- stateless APIs are soooo much cleaner (and yes, are much easier to parallelise).

Your draw functions end up taking a sequence of state/draw pairs, something like:struct RenderInstance
{//not at all real code. Efficiently implementing this is complicated.
vector< varying<StateChange> > stateBlock;
varying<DrawCall> draw;
}
void ExecuteRenderInstances( const vector<RenderInstance>& );The actual rendering pipeline (e.g. a multi-stage deferred renderer) is built as a layer on top of this level of abstraction. Whether the lower level is stateless or a state-machine, this higher level pipeline is still structured in the same way...
Can you give an example of how you think multi-stage pipelines conflict with a low-level stateless API?

Can you give an example of how you think multi-stage pipelines conflict with a low-level stateless API?

I certainly can't. Especially when you consider that you can treat lights as simply another renderable object that gets passed in with its state all encapsulated in a single packet (which is what the Civ5 guys call their stateless chunks). They also don't correspond to a single draw call, but can be several draw calls per packet. Their setup is also not a 1 to 1 correspondence between a packet and a command list in all cases.

The Firaxis/Civ5 talk and the DICE BF3 talk were the two most interesting talks at the DX11 summit. The DA2 talk was... meh imo, and the other talks (except for perhaps the second one in the morning) were pretty straightforward with little interesting information.

Hodgman, Example:

1. Draw Scene

2 Draw lights with scene as input.

3. Blend and postprocess

how is this stateless when the lighting stage requires the scene to be finished?

Your explanation seems to be a bit different than my understanding.

Can you give a examples of why this is complicated to implement? eg it is hard because of x?

I really want to implement this kind of renderer.

Thanks guys!

Can Someone clarify this for me?

It seems that a packet could maybe contain all opaque surface calls, and then all lights, based on what I am getting from the above answers. But even that isnt correct because one packet must follow the other.

Each packet encapsulates the entire state required to render said packet. As such, each packet is stateless (as it does not depend on the existence of any prior state). Furthermore, because they're stateless they can be submitted in any order.

The actual underlying renderer may sort and prioritize packets as it chooses, and they even mentioned that they did that for batching purposes.

okay whoa, my mind is blown... so you have your renderer, and the packeting architecture sits on top of it? now this is making sense... yikes, sounds like a lot of work.