I.e. if ARB_buffer_storage is not supported.
Signed-off-by: Zebediah Figura zfigura@codeweavers.com --- Somehow I had forgotten to protect against this...
dlls/wined3d/adapter_gl.c | 1 + dlls/wined3d/adapter_vk.c | 1 + dlls/wined3d/buffer.c | 4 +++- dlls/wined3d/wined3d_private.h | 1 + 4 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/dlls/wined3d/adapter_gl.c b/dlls/wined3d/adapter_gl.c index 0d9f6953de3..05e8c112388 100644 --- a/dlls/wined3d/adapter_gl.c +++ b/dlls/wined3d/adapter_gl.c @@ -5231,6 +5231,7 @@ static void wined3d_adapter_gl_init_d3d_info(struct wined3d_adapter_gl *adapter_ d3d_info->fences = wined3d_fence_supported(gl_info); d3d_info->feature_level = feature_level_from_caps(gl_info, &shader_caps, &fragment_caps); d3d_info->filling_convention_offset = gl_info->filling_convention_offset; + d3d_info->persistent_map = !!gl_info->supported[ARB_BUFFER_STORAGE];
if (gl_info->supported[ARB_TEXTURE_MULTISAMPLE]) d3d_info->multisample_draw_location = WINED3D_LOCATION_TEXTURE_RGB; diff --git a/dlls/wined3d/adapter_vk.c b/dlls/wined3d/adapter_vk.c index cd1748afe90..3b87ab63ee5 100644 --- a/dlls/wined3d/adapter_vk.c +++ b/dlls/wined3d/adapter_vk.c @@ -2351,6 +2351,7 @@ static void wined3d_adapter_vk_init_d3d_info(struct wined3d_adapter_vk *adapter_ d3d_info->feature_level = feature_level_from_caps(&shader_caps); d3d_info->subpixel_viewport = true; d3d_info->fences = true; + d3d_info->persistent_map = true;
/* Like GL, Vulkan doesn't explicitly specify a filling convention and only mandates that a * shared edge of two adjacent triangles generate a fragment for exactly one of the triangles. diff --git a/dlls/wined3d/buffer.c b/dlls/wined3d/buffer.c index 0d6550bf613..9b0d98139ce 100644 --- a/dlls/wined3d/buffer.c +++ b/dlls/wined3d/buffer.c @@ -1008,11 +1008,13 @@ static HRESULT buffer_resource_sub_resource_map(struct wined3d_resource *resourc addr.buffer_object = buffer->buffer_object; addr.addr = 0; buffer->map_ptr = wined3d_context_map_bo_address(context, &addr, resource->size, flags); + /* We are accessing buffer->resource.client from the CS thread, * but it's safe because the client thread will wait for the * map to return, thus completely serializing this call with * other client code. */ - buffer->resource.client.addr = addr; + if (context->d3d_info->persistent_map) + buffer->resource.client.addr = addr;
if (((DWORD_PTR)buffer->map_ptr) & (RESOURCE_ALIGNMENT - 1)) { diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h index ce4d7384066..9304de4e9d6 100644 --- a/dlls/wined3d/wined3d_private.h +++ b/dlls/wined3d/wined3d_private.h @@ -243,6 +243,7 @@ struct wined3d_d3d_info uint32_t pbo : 1; uint32_t subpixel_viewport : 1; uint32_t fences : 1; + uint32_t persistent_map : 1; enum wined3d_feature_level feature_level;
DWORD multisample_draw_location;
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52663 Signed-off-by: Zebediah Figura zfigura@codeweavers.com --- dlls/wined3d/context_gl.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/dlls/wined3d/context_gl.c b/dlls/wined3d/context_gl.c index 1e4fcd12e9d..a0c7457d922 100644 --- a/dlls/wined3d/context_gl.c +++ b/dlls/wined3d/context_gl.c @@ -2939,7 +2939,8 @@ static void wined3d_bo_gl_unmap(struct wined3d_bo_gl *bo, struct wined3d_context { const struct wined3d_gl_info *gl_info = context_gl->gl_info;
- if (context_gl->c.device->adapter->mapped_size <= MAX_PERSISTENT_MAPPED_BYTES) + if (context_gl->c.d3d_info->persistent_map + && context_gl->c.device->adapter->mapped_size <= MAX_PERSISTENT_MAPPED_BYTES) { TRACE("Not unmapping BO %p.\n", bo); return; @@ -2962,6 +2963,7 @@ static void wined3d_bo_gl_unmap(struct wined3d_bo_gl *bo, struct wined3d_context if (bo->b.client_map_count) { wined3d_device_bo_map_unlock(context_gl->c.device); + assert(context_gl->c.d3d_info->persistent_map); TRACE("BO %p is still in use by a client thread; not unmapping.\n", bo); return; }
Am Dienstag, 31. Mai 2022, 04:10:07 EAT schrieb Zebediah Figura:
I.e. if ARB_buffer_storage is not supported.
Is it worth adding a sysmem map + glBufferSubData codepath to this for <= d3d9 games? I am aware of many problems with this (like applications giving us incorrect map ranges, thus breaking). How many GPU/driver combinations that still matter lack ARB_buffer_storage these days?
On 5/31/22 05:50, Stefan Dösinger wrote:
Am Dienstag, 31. Mai 2022, 04:10:07 EAT schrieb Zebediah Figura:
I.e. if ARB_buffer_storage is not supported.
Is it worth adding a sysmem map + glBufferSubData codepath to this for <= d3d9 games? I am aware of many problems with this (like applications giving us incorrect map ranges, thus breaking). How many GPU/driver combinations that still matter lack ARB_buffer_storage these days?
You mean accelerating NOOVERWRITE by mapping sysmem from the client thread? It might be possible, I think, although a bit orthogonal to this commit. But I'm not sure that any GPUs/drivers that lack ARB_buffer_storage are new enough to matter.
FWIW, the bug report in question is Nvidia G96 ("9600M GT") + binary drivers version 340. So, pretty ancient, but of course worth not breaking entirely.
-
Stefan Dösinger -
Zebediah Figura