On Wed, 26 Jan 2022 at 17:45, Zebediah Figura (she/her) zfigura@codeweavers.com wrote:
Of course, although this motivated the patch, it seems like a good idea regardless. In most cases we don't want SYSMEM for buffer objects, especially for newer d3d versions, and we should avoid the overhead of allocating it and keeping it around.
Yes.
It may also be that we want to translate D3DVBCAPS_WRITEONLY into ~WINED3D_RESOURCE_ACCESS_MAP_R. My limited understanding is that this doesn't contradict test_vb_writeonly() per se, but rather would only be a bad idea performance-wise if ddraw applications rely on reading from such mapped buffers in critical paths. I don't know whether that's the case.
Right, as far as I understand D3DVBCAPS_WRITEONLY, like D3DUSAGE_WRITEONLY in later D3D versions, mostly just affects caching of the mapped memory, somewhat like VK_MEMORY_PROPERTY_HOST_CACHED_BIT in Vulkan.
I left off using it for buffers because it wasn't clear to me that it was necessary. Thus far we had only found evidence that it was necessary for textures (and perhaps just swapchain textures?)
I think these were non-swapchain textures in the application that originally motivated clearing textures on creation.