On Fri, May 19, 2017 at 10:53:12AM -0700, Jason Ekstrand wrote:
> On Thu, May 18, 2017 at 2:01 PM, Jason Ekstrand <ja...@jlekstrand.net>
> wrote:
>
> > ---
> > src/intel/vulkan/anv_device.c | 42 ++++++++++++++++++++++++++++++
> > ++++++------
> > 1 file changed, 36 insertions(+), 6 deletions(-)
> >
> > diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> > index 6ea8dfe..8eed7f3 100644
> > --- a/src/intel/vulkan/anv_device.c
> > +++ b/src/intel/vulkan/anv_device.c
> > @@ -112,12 +112,42 @@ anv_physical_device_init_heaps(struct
> > anv_physical_device *device, int fd)
> > if (result != VK_SUCCESS)
> > return result;
> >
> > - device->memory.heap_count = 1;
> > - device->memory.heaps[0] = (struct anv_memory_heap) {
> > - .size = heap_size,
> > - .flags = VK_MEMORY_HEAP_DEVICE_LOCAL_BIT,
> > - .supports_48bit_addresses = device->supports_48bit_addresses,
> > - };
> > + if (heap_size <= 3ull * (1ull << 30)) {
> > + /* In this case, everything fits nicely into the 32-bit address
> > space,
> > + * so there's no need for supporting 48bit addresses on
> > clinet-allocated
> > + * memory objects.
> > + */
> > + device->memory.heap_count = 1;
> > + device->memory.heaps[0] = (struct anv_memory_heap) {
> > + .size = heap_size,
> > + .flags = VK_MEMORY_HEAP_DEVICE_LOCAL_BIT,
> > + .supports_48bit_addresses = false,
> > + };
> > + } else {
> > + /* Not everything will fit nicely into a 32-bit address space. In
> > this
> > + * case we need a 64-bit heap. Advertise a small 32-bit heap and a
> > + * larger 48-bit heap. If we're in this case, then we have a total
> > heap
> > + * size larger than 3GiB which most likely means they have 8 GiB of
> > + * video memory and so carving off 2 GiB for the 32-bit heap should
> > be
> > + * reasonable.
> > + */
> > + const uint32_t heap_size_32bit = 2ull * (1ull << 30);
> >
>
> FYI: I keep waflling on whether the 32-bit carve-out should be 2 GiB or 1
> GiB. No one should need more than 1 GiB for vertex buffers and it means
> that, on my laptop, the space is split roughly in half (2 GiB and ~3 GiB)
> which is a bit awkward. I'm kind-of inclined to decrease it. Opinions?
>
>
I'm not sure what a good size is either. It may be helpful if we ran
some games to see how they behaved with different values.
> > + const uint32_t heap_size_48bit = heap_size - heap_size_32bit;
> > +
> > + assert(device->supports_48bit_addresses);
> > +
> > + device->memory.heap_count = 2;
> > + device->memory.heaps[0] = (struct anv_memory_heap) {
> > + .size = heap_size_48bit,
> > + .flags = VK_MEMORY_HEAP_DEVICE_LOCAL_BIT,
> > + .supports_48bit_addresses = true,
> > + };
> > + device->memory.heaps[1] = (struct anv_memory_heap) {
> > + .size = heap_size_32bit,
> > + .flags = VK_MEMORY_HEAP_DEVICE_LOCAL_BIT,
> > + .supports_48bit_addresses = false,
> > + };
> > + }
> >
> > uint32_t type_count = 0;
> > for (uint32_t heap = 0; heap < device->memory.heap_count; heap++) {
> > --
> > 2.5.0.400.gff86faf
> >
> >
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
