https://bugs.winehq.org/show_bug.cgi?id=38974
Bug ID: 38974 Summary: Red Faction Guerilla: texture smearing at the side of the screen Product: Wine Version: 1.5.11 Hardware: x86 OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs@winehq.org Reporter: gyebro69@gmail.com CC: matteo.mystral@gmail.com Regression SHA1: 152a09ce75b97b1139e358428cea2c371a8b6804 Distribution: ---
Textures in the game get smeared at the bottom and the right side of the screen in a width of ~50 pixels. This corruption appears only in mid-game, neither menus nor cutscenes are affected. This screencast demonstrates the problem: https://drive.google.com/open?id=0B-tTbLKBl-tOQnRvQXdOUDJ2ckU
Reproducible with nouveau/mesa-git and with Nvidia blob 340.76 as well. Disabling GLSL or reducing graphical detail level/running the game in windowed mode doesn't help.
Terminal output shows only fixme:win:EnumDisplayDevicesW ((null),0,0x33eda8,0x00000000), stub! fixme:d3d9:D3DPERF_SetOptions (0x1) : stub fixme:thread:SetThreadIdealProcessor (0x294): stub fixme:thread:SetThreadIdealProcessor (0x2a0): stub
The problem is present since
commit 152a09ce75b97b1139e358428cea2c371a8b6804 Author: Matteo Bruni mbruni@codeweavers.com Date: Wed Aug 15 00:38:23 2012 +0200
wined3d: Use GL_FRAMEBUFFER_SRGB when possible.
No demo available, please let me know if you need debug logs or further tests.
wine-1.7.47-196-g4e6e9a1 Fedora 22 32-bit VGA compatible controller: NVIDIA Corporation G92 [GeForce GTS 250] (rev a2)
https://bugs.winehq.org/show_bug.cgi?id=38974
--- Comment #1 from Matteo Bruni matteo.mystral@gmail.com --- Thanks for the report.
That kind of buggy behavior is quite surprising. Can you try to comment out just the wined3d_get_device_caps() hunk of the patch? It's around line 4924 of directx.c in current Wine.
BTW, for your following bug reports, can you attach a screenshot in addition / instead of videos? I can't be bothered to watch videos usually.
https://bugs.winehq.org/show_bug.cgi?id=38974
--- Comment #2 from Béla Gyebrószki gyebro69@gmail.com --- Created attachment 51940 --> https://bugs.winehq.org/attachment.cgi?id=51940 screenshot
(In reply to Matteo Bruni from comment #1)
That kind of buggy behavior is quite surprising. Can you try to comment out just the wined3d_get_device_caps() hunk of the patch? It's around line 4924 of directx.c in current Wine.
It doesn't make it any better.
BTW, for your following bug reports, can you attach a screenshot in addition / instead of videos? I can't be bothered to watch videos usually.
Got it.
https://bugs.winehq.org/show_bug.cgi?id=38974
--- Comment #3 from Matteo Bruni matteo.mystral@gmail.com ---
(In reply to Matteo Bruni from comment #1)
That kind of buggy behavior is quite surprising. Can you try to comment out just the wined3d_get_device_caps() hunk of the patch? It's around line 4924 of directx.c in current Wine.
It doesn't make it any better.
Thanks for testing, although that's unfortunate :/
This seems hard to debug without being able to reproduce locally. I guess you could try to take a trace with Apitrace while generating a +tid,d3d9,d3d,d3d_shader,d3d_texture,d3d_surface log, although you will most likely get some huge files and I don't guarantee to be able to figure out the issue from that...
https://bugs.winehq.org/show_bug.cgi?id=38974
--- Comment #4 from Béla Gyebrószki gyebro69@gmail.com --- d3d9,d3d,d3d_shader,d3d_texture,d3d_surface log (uncompressed 350 MB): https://drive.google.com/open?id=0B-tTbLKBl-tOTExEaTBzLUw0OHc
Trace (uncompressed 100 MB): https://drive.google.com/open?id=0B-tTbLKBl-tOaC1QS0IwblhpQms
The texture corruption is first visible in frame #318. Fbo from Call 680835 glDrawArrays(GL_Triangle_Strip,0,4) already contains the corrupted image.
https://bugs.winehq.org/show_bug.cgi?id=38974
--- Comment #5 from Matteo Bruni matteo.mystral@gmail.com --- (In reply to Béla Gyebrószki from comment #4)
d3d9,d3d,d3d_shader,d3d_texture,d3d_surface log (uncompressed 350 MB): https://drive.google.com/open?id=0B-tTbLKBl-tOTExEaTBzLUw0OHc
Trace (uncompressed 100 MB): https://drive.google.com/open?id=0B-tTbLKBl-tOaC1QS0IwblhpQms
The texture corruption is first visible in frame #318. Fbo from Call 680835 glDrawArrays(GL_Triangle_Strip,0,4) already contains the corrupted image.
Very nice Béla, thanks. Can I ask you for the same log + trace of a run without the bug?
The patch can't be cleanly reverted but commenting out the ARB_FRAMEBUFFER_SRGB entry from the gl_extension_map table should do the same (and if it doesn't that's interesting too).
https://bugs.winehq.org/show_bug.cgi?id=38974
--- Comment #6 from Béla Gyebrószki gyebro69@gmail.com --- Commenting out ARB_FRAMEBUFFER_SRGB in wined3d/directx.c indeed makes the problem go away.
Here are the new traces, now with that entry commented out:
d3d9,d3d,d3d_shader,d3d_texture,d3d_surface log: https://drive.google.com/open?id=0B-tTbLKBl-tOMU4zZ0Q2eEtaa0E
Trace from apitrace: https://drive.google.com/open?id=0B-tTbLKBl-tOX0UxMzU5bXJpOW8
https://bugs.winehq.org/show_bug.cgi?id=38974
--- Comment #7 from Matteo Bruni matteo.mystral@gmail.com --- Created attachment 51957 --> https://bugs.winehq.org/attachment.cgi?id=51957 Possible fix
Excellent, I think I see what's going on. I'm attaching a patch, can you check whether it fixes the bug?
https://bugs.winehq.org/show_bug.cgi?id=38974
--- Comment #8 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to Matteo Bruni from comment #7)
Created attachment 51957 [details] Possible fix
Excellent, I think I see what's going on. I'm attaching a patch, can you check whether it fixes the bug?
The patch fixes the issue here, thank you.
https://bugs.winehq.org/show_bug.cgi?id=38974
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #51957|0 |1 is obsolete| |
--- Comment #9 from Matteo Bruni matteo.mystral@gmail.com --- Created attachment 52783 --> https://bugs.winehq.org/attachment.cgi?id=52783 Fix v2
I managed to get around writing some tests for this bug and it turns out that they don't quite give the results I expected. Can you check if the new patch also fixes the bug for you?
A quick explanation of the bug itself: the game uses ID3DDevice9::Clear() to initialize a texture to color (0.5, 0.5, 0.0, 0.0). That texture is then used in the final postprocessing pass as a sort of offset for the rendered scene. In the broken case the SRGBFRAMEBUFFER GL state happens to be enabled at the time of the clear because of the last draw (to a different render target), the texture ends up being cleared with the gamma-corrected color and that results in the smearing visible in the screenshot.
My initial guess was that clears should always ignore the D3DRS_SRGBWRITEENABLE state but my testing shows that's not the case, clears are affected by it. It's pretty weird actually, on the Windows systems I tested (XP and Win7) changes in the render state setting are ignored by clears unless "something" (e.g. a draw) happens in between and switching render targets sometimes also has an effect. The testbot (WARP on Win8 and Win10) seems to give a more sensible behavior though - the state affects the clears without that weirdness.
https://bugs.winehq.org/show_bug.cgi?id=38974
--- Comment #10 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to Matteo Bruni from comment #9)
Created attachment 52783 [details] Fix v2
I managed to get around writing some tests for this bug and it turns out that they don't quite give the results I expected. Can you check if the new patch also fixes the bug for you?
The patch works here.
wine-1.7.55-55-g7f6634b OpenGL vendor string: nouveau OpenGL renderer string: Gallium 0.4 on NV92 OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.1.0-devel OpenGL core profile shading language version string: 3.30
https://bugs.winehq.org/show_bug.cgi?id=38974
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |787a2716e1f7e3ade07b16c820e | |e2026153c80da Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #11 from Béla Gyebrószki gyebro69@gmail.com --- Fixed in wine-1.8-rc2-29-g66d8e38. Thank you, Matteo.
https://bugs.winehq.org/show_bug.cgi?id=38974
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #12 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.8-rc3.