Paul Berry <stereotype...@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.
pgpLBdIDbBn8v.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
