<div dir="ltr"><div><div><div><div><div>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.<br>
<br></div>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:<br><br></div><div>- 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.<br>
<br></div><div>- When we did need to recycle the dynamic state bo, we could do so without needlessly flushing the batch buffer.<br></div><div><br></div>- 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.<br>
</div><br></div>- 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).<br>
<br></div><div>What do you think?<br></div></div>