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

[Eric Anholt]

Paul Berry <stereotype441 at gmail.com> writes:

> 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?

It would need some sort of plan for how to deal with making
drm_intel_bufmgr_check_aperture work correctly and efficiently when a
reloced-to BO gets new relocs, which is the reason everything is in one
BO currently.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130506/5a5c1958/attachment.pgp>