On Tue, May 7, 2013 at 4:24 AM, Eric Anholt <e...@anholt.net> wrote: > 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. 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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > -- o...@lunarg.com _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
