[Mesa-dev] RFC/intel: Separate batch buffers from dynamic state

[Paul Berry]

Currently the i965 driver uses a single buffer object to hold both batch
buffer commands and dynamic state data structures (which are pointed to by
batch buffer commands).  We use a "stack and heap model", where the former
are allocated from the front end of the bo and the latter are allocated
from the back end.

I'd like us to consider splitting dynamic state to its own separate buffer
object.  It seems to me that it would carry advantages both in performance
and code simplicity:

- The dynamic state bo would need recycling much less frequently, because
(a) it could be made much larger than the batch buffer bo, and (b) a batch
buffer flush would not necessitate re-emitting dynamic state.  Since a lot
of our CPU time is spent emitting state, this could potentially improve
performance.

- When we did need to recycle the dynamic state bo, we could do so without
needlessly flushing the batch buffer.

- On systems that support hardware contexts, when we flush the batch
buffer, we wouldn't need to re-emit as many batch buffer commands (since
dynamic state wouldn't have moved relative to the dynamic state base
address), saving further CPU time.

- On systems that support hardware contexts, we wouldn't need to use a
"space available" heuristic to ensure that enough batch buffer space was
available before starting to emit the state for a draw call.  Instead we
could just emit commands until the batch buffer is full, flush it, start
the next batch off with a STATE_BASE_ADDRESS command, and pick up where we
left off.  This would make the state emission logic less fragile (since we
wouldn't need to remember to update the heuristic when adding features to
the driver).

What do you think?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130506/ea73e084/attachment-0001.html>