On Mon, May 7, 2018 at 9:24 AM, Scott D Phillips <scott.d.phill...@intel.com
> wrote:
> Jason Ekstrand <ja...@jlekstrand.net> writes:
>
> > On Wed, May 2, 2018 at 9:01 AM, Scott D Phillips <
> scott.d.phill...@intel.com
> >> wrote:
> >
> >> These will be used to assign virtual addresses to soft pinned
> >> buffers in a later patch.
> >> ---
> >> src/intel/vulkan/anv_device.c | 75 ++++++++++++++++++++++++++++++
> >> ++++++++++++
> >> src/intel/vulkan/anv_private.h | 11 +++++++
> >> 2 files changed, 86 insertions(+)
> >>
> >> diff --git a/src/intel/vulkan/anv_device.c
> b/src/intel/vulkan/anv_device.c
> >> index c0cec175826..d3d9c779d62 100644
> >> --- a/src/intel/vulkan/anv_device.c
> >> +++ b/src/intel/vulkan/anv_device.c
>
> ..snip..
>
> >> @@ -1887,6 +1909,59 @@ VkResult anv_DeviceWaitIdle(
> >> return anv_device_submit_simple_batch(device, &batch);
> >> }
> >>
> >> +bool
> >> +anv_vma_alloc(struct anv_device *device, struct anv_bo *bo)
> >> +{
> >> + if (!(bo->flags & EXEC_OBJECT_PINNED))
> >> + return true;
> >>
> >
> > When are things not pinned?
>
> At this point in the series nothing will be pinned. The state pools will
> be pinnned in patch 6 and everything else will be in patch 9. It's not
> safe to take this check away after patch 9 though, we'll still be
> supporting old gens where nothing is pinned.
>
Ok, makes sense.
> >> +
> >> + pthread_mutex_lock(&device->vma_mutex);
> >> +
> >> + bo->offset = 0;
> >> +
> >> + if (bo->flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS &&
> >> + device->vma_hi_available >= bo->size) {
> >> + uint64_t addr = util_vma_heap_alloc(&device->vma_hi, bo->size,
> >> 4096);
> >> + if (addr) {
> >> + bo->offset = canonical_address(addr);
> >> + device->vma_hi_available -= bo->size;
> >> + }
> >> + }
> >> +
> >> + if (bo->offset == 0 && device->vma_lo_available >= bo->size) {
> >> + uint64_t addr = util_vma_heap_alloc(&device->vma_lo, bo->size,
> >> 4096);
> >> + if (addr) {
> >> + bo->offset = canonical_address(addr);
> >> + device->vma_lo_available -= bo->size;
> >> + }
> >> + }
> >>
> >
> > I'm not sure how I feel about using EXEC_OBJECT_SUPPORTS_48B_ADDRESS for
> > this. I think it certainly works but it's not what I had pictured.
>
> What's the concern? It seems like this is exactly what
> SUPPORTS_48B_ADDRESS means, this object can cope with being anywhere in
> the address space.
>
I had an idea in my head that maybe the device would have an array of heaps
and the heaps would have pointers to the allocators or something like
that. Really, it's mostly cosmetic not at all a big deal. I'm happy to do
some experimenting of my own after this all lands.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
