From: Henri Verbeet Subject: Re: [PATCH 3/3] wined3d: Don't initialize system memory for buffers. Message-Id: Date: Wed, 26 Jan 2022 14:47:12 +0100 In-Reply-To: <20220125022039.2005817-3-zfigura@codeweavers.com> References: <20220125022039.2005817-1-zfigura@codeweavers.com> <20220125022039.2005817-3-zfigura@codeweavers.com> On Tue, 25 Jan 2022 at 03:35, Zebediah Figura 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.