https://bugs.winehq.org/show_bug.cgi?id=42738
Bug ID: 42738 Summary: Annoying flickering in Renegade Ops (needs StrictDrawOrdering=enabled to remove it) Product: Wine Version: 2.1 Hardware: x86 URL: http://store.steampowered.com/app/99300/ OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs@winehq.org Reporter: gyebro69@gmail.com CC: hverbeet@gmail.com Regression SHA1: 602a23a60aaab164acb8a2767094d545172ab4cf Distribution: ---
Created attachment 57732 --> https://bugs.winehq.org/attachment.cgi?id=57732 terminal output
This is a DX10 game and needs native d3dcompiler_43 and d3dx10_42 to start.
From the opening videos throughout the menus and in the main game the screen is
flickering heavily. Changing in-game options e.g. screen resolution, MSAA, Vsync doesn't remove this annoyance.
The problem doesn't occur in Wine Staging when CSMT is enabled or when StrictDrawOrdering is enabled in pure Wine.
What makes this bug different from other similar issues reported here is that that the problem is fairly new, there was no need to enable the StrictDrawOrdering in the registry to avoid the screen flickering until
commit 602a23a60aaab164acb8a2767094d545172ab4cf Author: Henri Verbeet hverbeet@codeweavers.com Date: Fri Jan 27 11:36:31 2017 +0100
wined3d: Just use glBufferSubData() in buffer_direct_upload().
It might seem like a good idea to try to use glMapBufferRange() in buffer_direct_upload(), but it really isn't. The interesting cases for glMapBufferRange() are GL_MAP_INVALIDATE_BUFFER_BIT or GL_MAP_UNSYNCHRONIZED_BIT, but the only way for those to be set here would be for the buffer to be mapped with WINED3D_MAP_DISCARD or WINED3D_MAP_NOOVERWRITE before the buffer object was created. In that case the GPU is obviously not using the buffer object, so glMapBufferRange() doesn't help. On the other hand, if the buffer is currently in use by the application and neither WINED3D_MAP_DISCARD nor WINED3D_MAP_NOOVERWRITE is set, glMapBufferRange() would need to wait for the GPU to finish using the buffer object, while glBufferSubData() may decide not to.
With the previous commit there is no flickering at all.
No demo version available, let me know if you need debug logs.
wine-2.4-256-g4bfa0d829f OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GT 730/PCIe/SSE2 OpenGL core profile version string: 4.5.0 NVIDIA 378.13 OpenGL core profile shading language version string: 4.50 NVIDIA
https://bugs.winehq.org/show_bug.cgi?id=42738
--- Comment #1 from Henri Verbeet hverbeet@gmail.com --- Does this application use Direct3D from multiple threads? If it does, this is a duplicate of the existing "StrictDrawOrdering" bugs, and csmt will be the fix for those. It wouldn't be unexpected for this kind of change to make such an issue visible where it previously wasn't. If it only uses Direct3D from a single thread something else may be going on.
https://bugs.winehq.org/show_bug.cgi?id=42738
--- Comment #2 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to Henri Verbeet from comment #1)
Does this application use Direct3D from multiple threads? If it does, this is a duplicate of the existing "StrictDrawOrdering" bugs, and csmt will be the fix for those. It wouldn't be unexpected for this kind of change to make such an issue visible where it previously wasn't. If it only uses Direct3D from a single thread something else may be going on.
How can I find out if it uses multiple or a single thread for D3D?
https://bugs.winehq.org/show_bug.cgi?id=42738
--- Comment #3 from Henri Verbeet hverbeet@gmail.com --- The easiest is probably to create a WINEDEBUG=+d3d11,+tid log and check if there are calls from different threads. (E.g. by sorting the log and comparing top and bottom, although you can usually tell just by looking at it.)
https://bugs.winehq.org/show_bug.cgi?id=42738
--- Comment #4 from Béla Gyebrószki gyebro69@gmail.com --- Created attachment 57755 --> https://bugs.winehq.org/attachment.cgi?id=57755 +d3d11,+tid log (uncompressed 12 M)
(In reply to Henri Verbeet from comment #3)
The easiest is probably to create a WINEDEBUG=+d3d11,+tid log and check if there are calls from different threads. (E.g. by sorting the log and comparing top and bottom, although you can usually tell just by looking at it.)
I launched the game and let the first video (SEGA logo) play then I terminated the game (the flickering can be observed in the first video.)
I see 4 different tids which contain d3d11 traces: 0073 007d 007e 0088
I suppose it is a duplicate of existing strictdrawordering bugs, and not a regression then. Am I right?
https://bugs.winehq.org/show_bug.cgi?id=42738
--- Comment #5 from Henri Verbeet hverbeet@gmail.com --- (In reply to Béla Gyebrószki from comment #4)
Created attachment 57755 [details] I see 4 different tids which contain d3d11 traces: 0073 007d 007e 0088
I suppose it is a duplicate of existing strictdrawordering bugs, and not a regression then. Am I right?
It looks like it, yeah. It's perhaps interesting to note that most of the interleaving between the threads seems to be early on and between threads 007d and 007e. It's possible that attachment 57262 or something similar would be enough for this specific application.
https://bugs.winehq.org/show_bug.cgi?id=42738
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE
--- Comment #6 from Béla Gyebrószki gyebro69@gmail.com --- The patch from bug #42410 fixes the problem.
*** This bug has been marked as a duplicate of bug 42410 ***
https://bugs.winehq.org/show_bug.cgi?id=42738
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #7 from Austin English austinenglish@gmail.com --- Closing.