https://bugs.winehq.org/show_bug.cgi?id=55591
--- Comment #1 from Zeb Figura z.figura12@gmail.com --- So this game's creative maneuver is to map a dynamic (DEFAULT + DYNAMIC + WRITEONLY) VB and IB with DISCARD, do a bunch of (indexed) draws with the buffers mapped, then unmap them.
This worked previously as long as you have ARB_buffer_storage, mainly because we specifically request coherent buffers. Map acceleration broke it because we allocate a new buffer on discard but don't actually perform a rename immediately. And I'm pretty sure this is the root cause of the rendering errors, because hacking the map acceleration code to upload on map instead of unmap did make the artifacts go away.
However, I wrote a test that tries to do the same thing, and it failed on the testbot (windows 11, all three of amd, nvidia, warp). So either:
* This behaviour triggers under non-obvious conditions. I did make sure that the pool and usage flags were the same, and the device the game uses is a hardware device + hardware VP. I don't think there's any more obvious conditions, but there could be non-obvious ones.
* The native d3d9 runtime/drivers has a workaround for this game. I did try renaming the test executable to CLOS2.exe, and that didn't change anything.
* The behaviour broke in Windows 10 or 11. (The game was released in 2014 which is contemporaneous with Windows 8.) Unfortunately I don't have a real machine with Windows 7 to test.
* The bug isn't actually related to these buffers after all.
* The buffers happen to be initialized with the "right" data, or at least data that results in no-op draws.