[PATCH] wined3d: Do not request device local memory if we also want it to be host visible.
Some implementations do not support this combination.
Signed-off-by: Jan Sikorski jsikorski@codeweavers.com --- dlls/wined3d/buffer.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/dlls/wined3d/buffer.c b/dlls/wined3d/buffer.c index 4c5e2054fe0..4420885b15f 100644 --- a/dlls/wined3d/buffer.c +++ b/dlls/wined3d/buffer.c @@ -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 (!(wined3d_context_vk_create_bo(context_vk, resource->size, usage, memory_type, &buffer_vk->bo))) {
On Thu, 29 Jul 2021 at 13:52, Jan Sikorski jsikorski@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;
- 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 vkd3d_select_memory_type().
On 29 Jul 2021, at 16:24, Henri Verbeet hverbeet@gmail.com wrote:
On Thu, 29 Jul 2021 at 13:52, Jan Sikorski jsikorski@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;
- 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 vkd3d_select_memory_type().
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.
- Jan
On Thu, 29 Jul 2021 at 16:38, Jan Sikorski jsikorski@codeweavers.com wrote:
On 29 Jul 2021, at 16:24, Henri Verbeet hverbeet@gmail.com wrote: On Thu, 29 Jul 2021 at 13:52, Jan Sikorski jsikorski@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;
- 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 vkd3d_select_memory_type().
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.
On 7/29/21 9:41 AM, Henri Verbeet wrote:
On Thu, 29 Jul 2021 at 16:38, Jan Sikorski jsikorski@codeweavers.com wrote:
On 29 Jul 2021, at 16:24, Henri Verbeet hverbeet@gmail.com wrote: On Thu, 29 Jul 2021 at 13:52, Jan Sikorski jsikorski@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;
- 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 vkd3d_select_memory_type().
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?
On 29 Jul 2021, at 16:52, Zebediah Figura (she/her) zfigura@codeweavers.com wrote:
On 7/29/21 9:41 AM, Henri Verbeet wrote:
On Thu, 29 Jul 2021 at 16:38, Jan Sikorski jsikorski@codeweavers.com wrote:
On 29 Jul 2021, at 16:24, Henri Verbeet hverbeet@gmail.com wrote: On Thu, 29 Jul 2021 at 13:52, Jan Sikorski jsikorski@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;
- 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 vkd3d_select_memory_type().
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?
Hm, maybe it would, how about this:
While failed: 1. If type had DEVICE LOCAL and HOST CACHED bits, set it to desired type with HOST CACHED dropped, and retry 2. If type had DEVICE LOCAL and HOST VISIBLE bits, set it to desired type with DEVICE LOCAL dropped, and retry 3. Else, give up
So if it’s all 3, we’d try DEVICE LOCAL | HOST VISIBLE first, then HOST VISIBLE | HOST CACHED. If it’s DEVICE LOCAL | HOST VISIBLE, we try just HOST VISIBLE. If it was DEVICE LOCAL | HOST CACHED, we’d drop HOST CACHED, but we don’t ever request that. - Jan
-
Henri Verbeet -
Henri Verbeet -
Jan Sikorski -
Zebediah Figura (she/her)