[PATCH] wined3d: Do not request device local memory if we also want it to be host visible.
Zebediah Figura (she/her)
zfigura at codeweavers.com
Thu Jul 29 09:52:41 CDT 2021
On 7/29/21 9:41 AM, Henri Verbeet wrote:
> On Thu, 29 Jul 2021 at 16:38, Jan Sikorski <jsikorski at codeweavers.com> wrote:
>>> On 29 Jul 2021, at 16:24, Henri Verbeet <hverbeet at gmail.com> wrote:
>>> On Thu, 29 Jul 2021 at 13:52, Jan Sikorski <jsikorski at codeweavers.com> wrote:
>>>> @@ -1410,12 +1410,12 @@ static BOOL wined3d_buffer_vk_create_buffer_object(struct wined3d_buffer_vk *buf
>>>> FIXME("Ignoring some bind flags %#x.\n", bind_flags);
>>>> memory_type = 0;
>>>> - if (!(resource->usage & WINED3DUSAGE_DYNAMIC))
>>>> - memory_type |= VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT;
>>>> if (resource->access & WINED3D_RESOURCE_ACCESS_MAP_R)
>>>> memory_type |= VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT | VK_MEMORY_PROPERTY_HOST_CACHED_BIT;
>>>> else if (resource->access & WINED3D_RESOURCE_ACCESS_MAP_W)
>>>> memory_type |= VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT;
>>>> + else if (!(resource->usage & WINED3DUSAGE_DYNAMIC))
>>>> + memory_type |= VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT;
>>> If I understand correctly, we'd get here for DEFAULT resources with
>>> CPU read/write access. I wonder if there would be any advantage in
>>> using DEVICE_LOCAL | HOST_VISIBLE on GPUs that do in fact support that
>>> memory type, perhaps using a scheme similar to vkd3d's
>> We could just try to allocate it and retry without DEVICE_LOCAL if it fails. That would also work in case this type is supported but out of space.
> Yeah, that should work.
In my case I have a heap with DEVICE_LOCAL | HOST_VISIBLE, but not (as
is requested) DEVICE_LOCAL | HOST_VISIBLE | HOST_CACHED. If we're
talking about DEFAULT resources, would it make sense to drop HOST_CACHED
rather than DEVICE_LOCAL?
More information about the wine-devel