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@winehq.org ReportedBy: liquid.acid@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
http://bugs.winehq.org/show_bug.cgi?id=26229
Enrico Enrico_m@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Enrico_m@gmx.de
http://bugs.winehq.org/show_bug.cgi?id=26229
--- Comment #1 from Tobias Jakobi liquid.acid@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?
http://bugs.winehq.org/show_bug.cgi?id=26229
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download
http://bugs.winehq.org/show_bug.cgi?id=26229
--- Comment #2 from Henri Verbeet hverbeet@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.
http://bugs.winehq.org/show_bug.cgi?id=26229
--- Comment #3 from Tobias Jakobi liquid.acid@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?
http://bugs.winehq.org/show_bug.cgi?id=26229
--- Comment #4 from Henri Verbeet hverbeet@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.
http://bugs.winehq.org/show_bug.cgi?id=26229
--- Comment #5 from Tobias Jakobi liquid.acid@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?
http://bugs.winehq.org/show_bug.cgi?id=26229
--- Comment #6 from Henri Verbeet hverbeet@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.
http://bugs.winehq.org/show_bug.cgi?id=26229
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #7 from joaopa jeremielapuree@yahoo.fr 2012-11-03 15:37:46 CDT --- still a bug in current wine?
http://bugs.winehq.org/show_bug.cgi?id=26229
Jonas Jelten jonas.jelten@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jonas.jelten@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=26229
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED CC| |focht@gmx.net Resolution|--- |UPSTREAM
--- Comment #8 from Anastasius Focht focht@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
https://bugs.winehq.org/show_bug.cgi?id=26229
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #9 from Bruno Jesus 00cpxxx@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.
-
wine-bugs＠winehq.org