[Bug 38974] New: Red Faction Guerilla: texture smearing at the side of the screen
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(a)winehq.org Reporter: gyebro69(a)gmail.com CC: matteo.mystral(a)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(a)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) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38974 --- Comment #1 from Matteo Bruni <matteo.mystral(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38974 --- Comment #2 from Béla Gyebrószki <gyebro69(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38974 --- Comment #3 from Matteo Bruni <matteo.mystral(a)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... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38974 --- Comment #4 from Béla Gyebrószki <gyebro69(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38974 --- Comment #5 from Matteo Bruni <matteo.mystral(a)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). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38974 --- Comment #6 from Béla Gyebrószki <gyebro69(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38974 --- Comment #7 from Matteo Bruni <matteo.mystral(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38974 --- Comment #8 from Béla Gyebrószki <gyebro69(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38974 Matteo Bruni <matteo.mystral(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #51957|0 |1 is obsolete| | --- Comment #9 from Matteo Bruni <matteo.mystral(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38974 --- Comment #10 from Béla Gyebrószki <gyebro69(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38974 Béla Gyebrószki <gyebro69(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |787a2716e1f7e3ade07b16c820e | |e2026153c80da Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Béla Gyebrószki <gyebro69(a)gmail.com> --- Fixed in wine-1.8-rc2-29-g66d8e38. Thank you, Matteo. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38974 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #12 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 1.8-rc3. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org