https://bugs.winehq.org/show_bug.cgi?id=55591
Bug ID: 55591 Summary: Castlevania: Lords of Shadow 2 has rendering glitches Product: Wine Version: 7.2 Hardware: x86-64 OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs@winehq.org Reporter: andrey.goosev@gmail.com CC: z.figura12@gmail.com Regression SHA1: 1b1b03055db8bf03c6783d4fcb19abf670d53338 Distribution: ---
Created attachment 75118 --> https://bugs.winehq.org/attachment.cgi?id=75118 example
Doesn't matter what graphics settings are used.
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.
https://bugs.winehq.org/show_bug.cgi?id=55591
--- Comment #2 from Zeb Figura z.figura12@gmail.com --- (In reply to Zeb Figura from comment #1)
- The buffers happen to be initialized with the "right" data, or at least
data that results in no-op draws.
I can rule out the "no-op draws" theory at least. If I specifically skip every draw with a mapped index buffer, fire stops rendering, and that's definitely supposed to render. C.f. the torches and candles in the background, at 9:20 here:
https://www.youtube.com/watch?v=VttL3fRfd3w
It's probably unlikely that the buffers just happen to have the right data in them, at that rate, although not impossible...
https://bugs.winehq.org/show_bug.cgi?id=55591
--- Comment #3 from Zeb Figura z.figura12@gmail.com --- To be clear, we could just fix this bug the obvious way: rename buffers on map rather than unmap, and flush every time a draw is done if we don't have coherent BOs. (At that point the only function of unmap is to release address space if we aren't mapping persistently.)
But that's going to be a nontrivial amount of work, and it's going to touch some very central code that could easily result in more accidental regressions. I'd kind of like to get to the bottom of this before trying that.
https://bugs.winehq.org/show_bug.cgi?id=55591
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
https://bugs.winehq.org/show_bug.cgi?id=55591
--- Comment #4 from Zeb Figura z.figura12@gmail.com --- Turns out that my test was just broken (I wrote the wrong VB data), and if I fix the test, drawing from a mapped dynamic buffer does in fact just work on Windows. Cool!
https://bugs.winehq.org/show_bug.cgi?id=55591
--- Comment #5 from Zeb Figura z.figura12@gmail.com --- Note for future reference: trying to do the same thing with d3d11 works on WARP, but fails on NVidia.
https://bugs.winehq.org/show_bug.cgi?id=55591
Andrey Gusev andrey.goosev@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED Fixed by SHA1| |c93440b700efa23069177db0090 | |9f12e95f90ecd
--- Comment #6 from Andrey Gusev andrey.goosev@gmail.com --- Fixed by https://source.winehq.org/git/wine.git/commit/c93440b700efa23069177db00909f1...
https://bugs.winehq.org/show_bug.cgi?id=55591
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #7 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 9.0-rc1.
-
WineHQ Bugzilla