[Mesa-dev] [PATCH 05/10] i965: Introduce a "memory zone" concept on BO allocation.

[Scott D Phillips]

Kenneth Graunke <kenneth at whitecape.org> writes:

> We're planning to start managing the PPGTT in userspace in the near
> future, rather than relying on the kernel to assign addresses.  While
> most buffers can go anywhere, some need to be restricted to within 4GB
> of a base address.
>
> This commit adds a "memory zone" parameter to the BO allocation
> functions, which lets the caller specify which base address the BO will
> be associated with, or BRW_MEMZONE_OTHER for the full 48-bit VMA.

As an aside, in anv I implemented OTHER to be something more like ANY,
where it allocates from either the high or low vma ranges. That's only
relevant though because I apply a size restriction to the 'high'
range. There's no such restriction here, so no need to have high
allocations try the low range if they fail.

Reviewed-by: Scott D Phillips <scott.d.phillips at intel.com>

> ---
>  src/mesa/drivers/dri/i965/brw_blorp.c         |  3 +-
>  src/mesa/drivers/dri/i965/brw_bufmgr.c        | 20 ++++++----
>  src/mesa/drivers/dri/i965/brw_bufmgr.h        | 40 ++++++++++++++++++-
>  src/mesa/drivers/dri/i965/brw_context.h       |  1 +
>  .../drivers/dri/i965/brw_performance_query.c  |  5 ++-
>  src/mesa/drivers/dri/i965/brw_pipe_control.c  |  3 +-
>  src/mesa/drivers/dri/i965/brw_program.c       |  8 ++--
>  src/mesa/drivers/dri/i965/brw_program_cache.c |  6 ++-
>  src/mesa/drivers/dri/i965/brw_queryobj.c      |  8 ++--
>  src/mesa/drivers/dri/i965/gen6_queryobj.c     |  3 +-
>  src/mesa/drivers/dri/i965/gen6_sol.c          |  6 ++-
>  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 15 ++++---
>  .../drivers/dri/i965/intel_buffer_objects.c   |  8 ++--
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c |  7 +++-
>  src/mesa/drivers/dri/i965/intel_screen.c      |  8 ++--
>  src/mesa/drivers/dri/i965/intel_upload.c      |  3 +-
>  16 files changed, 107 insertions(+), 37 deletions(-)
>
> For what it's worth, I have a prototype that has separate memzones
> for Instruction Base Address, Surface State Base Address, Dynamic State
> Base Address, and "other" for the rest of the VMA.  It's worked out very
> nicely, so I feel pretty confident that this is a good approach.