Kenneth Graunke <kenn...@whitecape.org> writes: > If EXEC_OBJECT_PINNED is set, we don't want to emit any relocations. > We simply want to add the BO to the validation list, and possibly mark > it as writeable. The new brw_use_pinned_bo() interface does just that. > > To avoid having to make every caller consider both the relocation and > softpin cases, we make emit_reloc() call brw_use_pinned_bo() when given > a softpinned buffer. > > We also can't grow buffers that are softpinned - the mechanism places a > larger BO at the same offset as the original, which requires moving BOs > around in the VMA. With softpin, we only allocate enough VMA for the > original size of the BO. > --- > src/mesa/drivers/dri/i965/intel_batchbuffer.c | 40 +++++++++++++++++-- > src/mesa/drivers/dri/i965/intel_batchbuffer.h | 4 ++ > 2 files changed, 40 insertions(+), 4 deletions(-) > > Overallocating is gross, but I have to make incremental progress somehow. > For batch buffers, the ultimate plan is to switch from growing to batch > chaining (just create another batch and MI_BATCH_BUFFER_START to GOTO > the new batch and carry on). We can do that on Gen8+. It's easier to > do that in the softpin world - otherwise, we'd need a third set of > relocation lists, which gets messier. > > For state buffers, the plan is to set Dynamic State Base Address to a > fixed 4GB region of the VMA, then just use intel_upload.c to make > however many buffers we need, allocated out of that memzone. Being able > to fix BO addresses within 4GB of the base address eliminates the need > to force all state to be in a single BO, and gives us a lot more > flexibility with less magic required. > > But again...can't convert everything overnight, especially when having > to care about older hardware and ancient kernels.
The plan of changing overallocation to chaining in a future patch sounds good to me. A nice enhancement at some point might be a INTEL_DEBUG=wasted-memory where we print out how much memory we're wasting due to overallocation, either here or by bucketing. I don't quite understand Chris's comment so this isn't meant to be an assertion that I think what he's saying isn't an issue, but fwiw: Reviewed-by: Scott D Phillips <scott.d.phill...@intel.com> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
