<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, May 7, 2018 at 9:24 AM, Scott D Phillips <span dir="ltr"><<a href="mailto:scott.d.phillips@intel.com" target="_blank">scott.d.phillips@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> writes:<br>
<br>
> On Wed, May 2, 2018 at 9:01 AM, Scott D Phillips <<a href="mailto:scott.d.phillips@intel.com">scott.d.phillips@intel.com</a><br>
>> wrote:<br>
><br>
>> These will be used to assign virtual addresses to soft pinned<br>
>> buffers in a later patch.<br>
>> ---<br>
>>  src/intel/vulkan/anv_device.c  | 75 ++++++++++++++++++++++++++++++<br>
>> ++++++++++++<br>
>>  src/intel/vulkan/anv_private.h | 11 +++++++<br>
>>  2 files changed, 86 insertions(+)<br>
>><br>
>> diff --git a/src/intel/vulkan/anv_device.<wbr>c b/src/intel/vulkan/anv_device.<wbr>c<br>
>> index c0cec175826..d3d9c779d62 100644<br>
>> --- a/src/intel/vulkan/anv_device.<wbr>c<br>
>> +++ b/src/intel/vulkan/anv_device.<wbr>c<br>
<br>
</span>..snip..<br>
<span class=""><br>
>> @@ -1887,6 +1909,59 @@ VkResult anv_DeviceWaitIdle(<br>
>>     return anv_device_submit_simple_<wbr>batch(device, &batch);<br>
>>  }<br>
>><br>
>> +bool<br>
>> +anv_vma_alloc(struct anv_device *device, struct anv_bo *bo)<br>
>> +{<br>
>> +   if (!(bo->flags & EXEC_OBJECT_PINNED))<br>
>> +      return true;<br>
>><br>
><br>
> When are things not pinned?<br>
<br>
</span>At this point in the series nothing will be pinned. The state pools will<br>
be pinnned in patch 6 and everything else will be in patch 9. It's not<br>
safe to take this check away after patch 9 though, we'll still be<br>
supporting old gens where nothing is pinned.<br><div><div class="h5"></div></div></blockquote><div><br></div><div>Ok, makes sense.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
>> +<br>
>> +   pthread_mutex_lock(&device-><wbr>vma_mutex);<br>
>> +<br>
>> +   bo->offset = 0;<br>
>> +<br>
>> +   if (bo->flags & EXEC_OBJECT_SUPPORTS_48B_<wbr>ADDRESS &&<br>
>> +       device->vma_hi_available >= bo->size) {<br>
>> +      uint64_t addr = util_vma_heap_alloc(&device-><wbr>vma_hi, bo->size,<br>
>> 4096);<br>
>> +      if (addr) {<br>
>> +         bo->offset = canonical_address(addr);<br>
>> +         device->vma_hi_available -= bo->size;<br>
>> +      }<br>
>> +   }<br>
>> +<br>
>> +   if (bo->offset == 0 && device->vma_lo_available >= bo->size) {<br>
>> +      uint64_t addr = util_vma_heap_alloc(&device-><wbr>vma_lo, bo->size,<br>
>> 4096);<br>
>> +      if (addr) {<br>
>> +         bo->offset = canonical_address(addr);<br>
>> +         device->vma_lo_available -= bo->size;<br>
>> +      }<br>
>> +   }<br>
>><br>
><br>
> I'm not sure how I feel about using EXEC_OBJECT_SUPPORTS_48B_<wbr>ADDRESS for<br>
> this.  I think it certainly works but it's not what I had pictured.<br>
<br>
</div></div>What's the concern? It seems like this is exactly what<br>
SUPPORTS_48B_ADDRESS means, this object can cope with being anywhere in<br>
the address space.<br>
</blockquote></div><br></div><div class="gmail_extra">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.<br></div></div>