[PATCH 3/3] wined3d: Don't initialize system memory for buffers.

[Henri Verbeet]

On Tue, 25 Jan 2022 at 03:35, Zebediah Figura <zfigura at codeweavers.com> wrote:
> This fixes test_map_synchronisation() on 64-bit machines, broken after
> 194b47b4fd92dda8ebf24e88ca7a14fc926c84ab.
>
How is it broken, and why does that happen?

> @@ -1233,7 +1233,7 @@ static HRESULT wined3d_buffer_init(struct wined3d_buffer *buffer, struct wined3d
>      }
>      buffer->buffer_ops = buffer_ops;
>      buffer->structure_byte_stride = desc->structure_byte_stride;
> -    buffer->locations = data ? WINED3D_LOCATION_DISCARDED : WINED3D_LOCATION_SYSMEM;
> +    buffer->locations = WINED3D_LOCATION_DISCARDED;
>
I think avoiding WINED3D_LOCATION_SYSMEM would be great, but I'm not
as convinced about using WINED3D_LOCATION_DISCARDED for that purpose.
I'm not sure we've ever confirmed that buffer resources should be
zeroed after creation, but we have for texture resources; it would not
surprise me if this change would break some applications.

My preferred way of handling this would be to introduce
WINED3D_LOCATION_CLEARED, which would effectively defer clearing the
resource until loading it into another location. When replacing the
entire (sub-)resource with e.g. a DISCARD map or sub-resource update,
we can then just skip that clear. This approach would also allow us to
avoid zeroing texture resources on creation, an in case of the Vulkan
renderer, we could even extend that a bit further and merge
render-target clears with starting render passes by using
VK_ATTACHMENT_LOAD_OP_CLEAR and appropriate clear values.