[Bug 26229] New: FEAR: waterplane rendering triggers SW fallback in mesa
http://bugs.winehq.org/show_bug.cgi?id=26229 Summary: FEAR: waterplane rendering triggers SW fallback in mesa Product: Wine Version: 1.3.14 Platform: x86 URL: http://www.gamershell.com/download_10167.shtml OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d AssignedTo: wine-bugs(a)winehq.org ReportedBy: liquid.acid(a)gmx.net Hi there, while profiling FEAR with sysprof I found out that rendering certain objects trigger a software fallback in mesa. If you check the demo version of the game, you can find such an object after the first underground section: Once the game renders the waterplane that exists in the next section the fallback becomes active and the performance collapses (this happens once you leave the underground area with the ladder). The engine probably uses an FBO for reflection of the world geometry on the waterplane. Profiling was done on my Intel i965, but I also noticed a slowdown on r600g, so probably the fallback is also triggered there (going to check this later). sysprof shows these two function consuming the majority of CPU time: _mesa_texstore_s8_z24 54.21% intel_ReadDepthSpan_z24_s8 32.06% The span functions are used in the driver for software fallbacks. Tracing back intel_ReadDepthSpan_z24_s8 shows: IWineD3DDeviceImpl_DrawIndexedPrimitive drawPrimitive surface_load_ds_location glCopyTexImage2D copyteximage intelCopyTexImage2D copy_tex_image intelReadPixels _swrast_ReadPixels read_depth_stencil_pixels intel_ReadDepthSpan_z24_s8 My guess is that the fallback is triggered by the lack of using EXT_packed_depth_stencil for stencil/depth handling. Greets, Tobias -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=26229 Enrico <Enrico_m(a)gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Enrico_m(a)gmx.de -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=26229 --- Comment #1 from Tobias Jakobi <liquid.acid(a)gmx.net> 2011-02-24 11:19:34 CST --- Also could have verified this by using the debugging functionality of the intel driver. With INTEL_DEBUG=fall I get these: intelCopyTexImage2D - fallback to swrast (intformat=35056, target=3553) intelReadPixels: fallback to swrast (modified the fallback printf to give me internal format and target) 35056 -> GL_DEPTH24_STENCIL8 3553 -> GL_TEXTURE_2D Tracked this down into intel_copy_texsubimage. Fallback kicks in because of: "The blitter can't handle Y-tiled buffers." Hmmmmmm..... I wonder why r600g is also affected by this? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=26229 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=26229 --- Comment #2 from Henri Verbeet <hverbeet(a)gmail.com> 2011-02-24 21:00:34 CST --- (In reply to comment #0)
My guess is that the fallback is triggered by the lack of using EXT_packed_depth_stencil for stencil/depth handling.
z24_s8 is a packed depth/stencil format, so I don't think that's it. (In reply to comment #1)
Hmmmmmm..... I wonder why r600g is also affected by this? Gallium drivers typically don't have software fallbacks, but it may e.g. end up doing the transfers through system memory. Regardless, this sounds like it should be two separate fd.o bugs.
-- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=26229 --- Comment #3 from Tobias Jakobi <liquid.acid(a)gmx.net> 2011-02-26 15:03:45 CST --- (In reply to comment #2)
z24_s8 is a packed depth/stencil format, so I don't think that's it. Yeah, I also noticed that. And Stefan confirmed that wined3d should now have proper packed depth/stencil support.
(In reply to comment #2)
Gallium drivers typically don't have software fallbacks, but it may e.g. end up doing the transfers through system memory. Regardless, this sounds like it should be two separate fd.o bugs. It has fallback functions, because I'm triggering one with r600g.
Anyway I have now two mesa bugs open: https://bugs.freedesktop.org/show_bug.cgi?id=34674 https://bugs.freedesktop.org/show_bug.cgi?id=34778 Like mentioned in the second bug, probably all Gallium based OpenGL drivers are affected by this problem. Is that (the way wined3d works now) supposed to work natively on any available hardware? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=26229 --- Comment #4 from Henri Verbeet <hverbeet(a)gmail.com> 2011-02-28 03:19:50 CST --- (In reply to comment #3)
(In reply to comment #2)
Gallium drivers typically don't have software fallbacks, but it may e.g. end up doing the transfers through system memory. Regardless, this sounds like it should be two separate fd.o bugs. It has fallback functions, because I'm triggering one with r600g.
That's the transfer through sysmem I was referring to.
Like mentioned in the second bug, probably all Gallium based OpenGL drivers are affected by this problem. Is that (the way wined3d works now) supposed to work natively on any available hardware? R600+ hardware should certainly be able to do it, the Gallium case looks more like not yet implemented functionality than a fundamental limitation to me.
-- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=26229 --- Comment #5 from Tobias Jakobi <liquid.acid(a)gmx.net> 2011-02-28 08:13:04 CST --- (In reply to comment #4)
R600+ hardware should certainly be able to do it, the Gallium case looks more like not yet implemented functionality than a fundamental limitation to me. Hmm, but isn't an Intel Arrandale also a DX10-capable GPU? I don't have a native Windows installation on this system here, but I doubt that I get such a fallback when running the game natively on Windows.
Furthermore FEAR is DX9-based, so its hardware demand isn't that high. It just looks fishy to me that some DX9 game is triggering a fallback on a DX10-level GPU where the developers tell me that this is a blitter hardware limitation. So what does the Windows driver do to work around this blitter limit? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=26229 --- Comment #6 from Henri Verbeet <hverbeet(a)gmail.com> 2011-02-28 08:32:15 CST --- (In reply to comment #5)
So what does the Windows driver do to work around this blitter limit? Native D3D doesn't need that blit at all. It's only needed due to not being able to share the depth buffer between application FBs and the system FB in GL. One way to avoid it in GL would be to do all rendering offscreen and only blitting the result to the framebuffer, but I think this is something the hardware should be able to do.
-- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=26229 joaopa <jeremielapuree(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree(a)yahoo.fr --- Comment #7 from joaopa <jeremielapuree(a)yahoo.fr> 2012-11-03 15:37:46 CDT --- still a bug in current wine? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=26229 Jonas Jelten <jonas.jelten(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonas.jelten(a)gmail.com -- 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.
http://bugs.winehq.org/show_bug.cgi?id=26229 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED CC| |focht(a)gmx.net Resolution|--- |UPSTREAM --- Comment #8 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, I can't reproduce this with Intel Haswell HD4600, Mesa 10.1.5. The upstream Mesa bugs have been resolved some time ago. Resolving 'upstream'. $ sha1sum fear_spdemo_en.zip 9856e6ea836ef1afee0d716849335ec4d407b0a7 fear_spdemo_en.zip $ du -sh fear_spdemo_en.zip 647M fear_spdemo_en.zip $ wine --version wine-1.7.21-41-g5af3b8c Regards -- 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=26229 Bruno Jesus <00cpxxx(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #9 from Bruno Jesus <00cpxxx(a)gmail.com> --- (In reply to Anastasius Focht from comment #8)
Hello folks,
I can't reproduce this with Intel Haswell HD4600, Mesa 10.1.5.
The upstream Mesa bugs have been resolved some time ago.
Resolving 'upstream'.
There were 2 upstream bugs, one was fixed in mesa and the other fixed in wine. I think it's safe to close this now. -- 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