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

[Chia-I Wu]

On Tue, May 7, 2013 at 4:24 AM, Eric Anholt <eric at anholt.net> wrote:
> 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.
I was looking into the same thing today for GEN6 and later.  It seems
the only states that require relocs are SURFACE_STATEs, and they can
still live in the batch bo while the other dynamic states are moved to
a separate state bo.

>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>



--
olv at LunarG.com