On Fri, May 19, 2017 at 2:53 PM, Gustaw Smolarczyk <wielkie...@gmail.com>
wrote:
> 2017-05-18 23:01 GMT+02:00 Jason Ekstrand <ja...@jlekstrand.net>:
> > ---
> > 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
>
> Probably a typo: s/clinet/client/
>
Thanks.
> > + * 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);
> > + const uint32_t heap_size_48bit = heap_size - heap_size_32bit;
>
> Is it really a good idea for these variables to be only 32-bit?
> Especially the second one.
>
Ugh... Good catch. I've fixed both locally. Thanks!
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
