[Bug 45747] New: GPU-GPU depth stencil blit is slow (FF XIV)
https://bugs.winehq.org/show_bug.cgi?id=45747 Bug ID: 45747 Summary: GPU-GPU depth stencil blit is slow (FF XIV) Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: awesie(a)gmail.com Distribution: --- When running FFXIV in D3D11 mode, it is horrendously slow because it does several UpdateSubresource calls to a depth-stencil texture from another texture. Right now, texture2d_blt will pass this on to a raw_blitter_blit as WINED3D_BLIT_OP_DEPTH_BLIT, which will ignore it and continue passing it on until it ends up at the CPU blitter. I believe a simple fix is to update the conditional in raw_blitter_blit to allow op == WINED3D_BLIT_OP_DEPTH_BLIT. I don't see an obvious reason why a depth-stencil blit should be special from the perspective of glCopyImageSubData. On my system, this significantly improved fps (though still not quite to matching FFXIV D3D9). -- 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=45747 --- Comment #1 from Henri Verbeet <hverbeet(a)gmail.com> --- (In reply to Andrew Wesie from comment #0)
When running FFXIV in D3D11 mode, it is horrendously slow because it does several UpdateSubresource calls to a depth-stencil texture from another texture. Right now, texture2d_blt will pass this on to a raw_blitter_blit as WINED3D_BLIT_OP_DEPTH_BLIT, which will ignore it and continue passing it on until it ends up at the CPU blitter.
I believe a simple fix is to update the conditional in raw_blitter_blit to allow op == WINED3D_BLIT_OP_DEPTH_BLIT. I don't see an obvious reason why a depth-stencil blit should be special from the perspective of glCopyImageSubData. On my system, this significantly improved fps (though still not quite to matching FFXIV D3D9).
Well, the issue isn't that WINED3D_BLIT_OP_DEPTH_BLIT is special, it's that WINED3D_BLIT_OP_RAW_BLIT has additional restrictions. E.g., WINED3D_BLIT_OP_DEPTH_BLIT can do scaling and multi-sample resolves, while WINED3D_BLIT_OP_RAW_BLIT can't. The way to use the raw blitter would be to call the blitter with WINED3D_BLIT_OP_RAW_BLIT in texture2d_blt(), under the right circumstances. (I.e., WINED3D_BLT_RAW or !scale, !convert, !resolve, like it's done for colour blits.) There are a couple of things that sound suspicious here though. Are you sure these blits are coming from UpdateSubresource()? Those should normally go to wined3d_texture_upload_data() rather than the blitter; did you perhaps mean CopyResource() or CopySubresourceRegion()? Why does the FBO blitter reject the blit? The raw blitter rejecting these is expected, although not ideal; the FBO blitter rejecting them is somewhat unexpected. -- 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=45747 --- Comment #2 from Andrew Wesie <awesie(a)gmail.com> --- You are obviously correct, I meant CopySubresourceRegion. Sorry. fbo_blitter_supported was returning FALSE because only the source texture has the depth and stencil flags. Both textures have format id WINED3DFMT_R24G8_TYPELESS. Your suggestion for adding the conditional code in raw_blitter_blit should be workable. -- 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=45747 --- Comment #3 from Henri Verbeet <hverbeet(a)gmail.com> --- (In reply to Andrew Wesie from comment #2)
fbo_blitter_supported was returning FALSE because only the source texture has the depth and stencil flags. Both textures have format id WINED3DFMT_R24G8_TYPELESS.
Ah, makes sense. -- 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=45747 zzzzzyzz(a)hacari.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zzzzzyzz(a)hacari.org -- 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=45747 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED CC| |leslie_alistair(a)hotmail.com Fixed by SHA1| |c3af72019ef1141610d2116d66e | |3fb7591832557 Status|UNCONFIRMED |RESOLVED --- Comment #4 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- Fixed by https://source.winehq.org/git/wine.git/?a=commit;h=c3af72019ef1141610d2116d6... -- 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=45747 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |3.15 -- 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=45747 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #5 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 3.16. -- 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