On 6 July 2015 at 23:47, Stefan Dösinger stefan@codeweavers.com wrote:
dlls/d3d9/tests/visual.c | 92 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 92 insertions(+)
Testbot failures aside, GetFrontBufferData() is pretty unreliable. This will (potentially) fail if e.g. a different window is covering the test window. (And the ChildWindowFromPoint() in v2 doesn't help, because it only takes other Wine windows into account.)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2015-07-07 um 17:00 schrieb Henri Verbeet:
Testbot failures aside, GetFrontBufferData() is pretty unreliable. This will (potentially) fail if e.g. a different window is covering the test window. (And the ChildWindowFromPoint() in v2 doesn't help, because it only takes other Wine windows into account.)
Sure, but I don't think we can fundamentally fix this. The only option I see is not having those tests, which would be fine with me.
On 7 July 2015 at 17:27, Stefan Dösinger stefandoesinger@gmail.com wrote:
Am 2015-07-07 um 17:00 schrieb Henri Verbeet:
Testbot failures aside, GetFrontBufferData() is pretty unreliable. This will (potentially) fail if e.g. a different window is covering the test window. (And the ChildWindowFromPoint() in v2 doesn't help, because it only takes other Wine windows into account.)
Sure, but I don't think we can fundamentally fix this. The only option I see is not having those tests, which would be fine with me.
I theory, once the shadowfb is moved from ddraw to wined3d we'd never read from the real drawable anymore.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2015-07-08 um 09:26 schrieb Henri Verbeet:
I theory, once the shadowfb is moved from ddraw to wined3d we'd never read from the real drawable anymore.
I don't think we want to use the shadowfb unconditionally. It would mean an extra copy (shadow backbuffer -> shadow frontbuffer -> GL_BACK - -> swap as opposed to shadow backbuffer -> GL_BACK -> swap). I don't think a reliable GetFrontBufferData is worth the extra copy, especially since GetFrontbufferData isn't reliable on Windows either (But ChildWindowFromPoint is).
We need the shadowfb for ddraw (esp. overlays, but also other corner cases) and swapeffect_flip, although in that case we ideally swap the FBOs and avoid the shadow backbuffer -> shadow frontbuffer blit and just do shadow frontbuffer -> GL_BACK -> swap. In theory we also want the shadow frontbuffer for a correct software cursor, but there are other problems with that.
On 8 July 2015 at 10:52, Stefan Dösinger stefandoesinger@gmail.com wrote:
I don't think we want to use the shadowfb unconditionally. It would mean an extra copy (shadow backbuffer -> shadow frontbuffer -> GL_BACK
- -> swap as opposed to shadow backbuffer -> GL_BACK -> swap). I don't
think a reliable GetFrontBufferData is worth the extra copy, especially since GetFrontbufferData isn't reliable on Windows either (But ChildWindowFromPoint is).
We need the shadowfb for ddraw (esp. overlays, but also other corner cases) and swapeffect_flip, although in that case we ideally swap the FBOs and avoid the shadow backbuffer -> shadow frontbuffer blit and just do shadow frontbuffer -> GL_BACK -> swap. In theory we also want the shadow frontbuffer for a correct software cursor, but there are other problems with that.
Actually, it would probably be helpful to have an overview of how this is all going to work in the end. E.g., how is ddraw_surface7_Flip() going to work with the new setup?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2015-07-15 um 10:47 schrieb Henri Verbeet:
Actually, it would probably be helpful to have an overview of how this is all going to work in the end. E.g., how is ddraw_surface7_Flip() going to work with the new setup?
Which part of this complicated function are you interested in? :-)
I've attached the current status of my work, but it's far from complete. The immediate goal is to make swapchain_blit work with wined3d_surface_blt (patch 13). Yeah, I realize I don't need most of the previous 12 patches for that technically.
The current code handles flip in the ddraw and d3d9 version by swapping the GL textures, invalidates all other locations (could move around sysmem as well, but didn't bother yet) and unloads the resource to remove the textures from the FBO cache. The same thing is currently done in flip_surface() in surface.c Especially the FBO cache handling is ugly.
Patches 15-17 give some idea how I plan ddraw overlays to work. I used the d3d9 software cursor to experiment with this, but I don't think we want to handle the software cursor in the way patch 15 handles it. It's matching the native behavior, but GL vsync causes major performance problems when updating the SW cursor and patch 17 doesn't really fix this.
As you can see in patch 18-20 I hit a wall while trying to eliminate the ddraw shadow frontbuffer. I think I first have to replace the swapchain destroy and recreate in SetCooperativeLevel with a _Reset call, and I'm sure there are many other issues. As such I haven't even bothered yet with the flip target parameter for surface_flip().
On 15 July 2015 at 12:43, Stefan Dösinger stefandoesinger@gmail.com wrote:
The current code handles flip in the ddraw and d3d9 version by swapping the GL textures, invalidates all other locations (could move around sysmem as well, but didn't bother yet) and unloads the resource to remove the textures from the FBO cache. The same thing is currently done in flip_surface() in surface.c Especially the FBO cache handling is ugly.
I didn't review the entire set, but that's a problem. I think flip_surface() is incredibly ugly, fragile and probably broken in some way. I would very much like it to go away, so I don't think anything that expands its usage is much of an improvement. ddraw_surface7_Flip() doesn't exactly make me happy either, but at least it only swaps complete surfaces and views, instead of depending on all kinds of wined3d internals. Not invalidating basically everything is probably a good thing too.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2015-07-15 um 13:23 schrieb Henri Verbeet:
I didn't review the entire set, but that's a problem. I think flip_surface() is incredibly ugly, fragile and probably broken in some way. I would very much like it to go away, so I don't think anything that expands its usage is much of an improvement. ddraw_surface7_Flip() doesn't exactly make me happy either, but at least it only swaps complete surfaces and views, instead of depending on all kinds of wined3d internals. Not invalidating basically everything is probably a good thing too.
Yeah, it's ugly, but in the patchset I kept it for now because there are plenty of other problems to solve as well. How we flip the surfaces or surface contents is fairly easy to separate from the rest of the issues we need to fix.
One idea would be to swap the swapchain resource pointers (and render target views if one of the buffers is currently assigned) and have a callback that tells the client libraries to re-fetch the wined3d objects for its front and back buffers. The lucky part is that render targets aren't stored in stateblocks in d3d8/9. I have done absolutely no investigation how well this would work with d3d10/11 yet. The expected problem is that in d3d10 the swapchain textures can be part of any number of views and they all need to be updated.
I don't think controlling everything from the client library (the current ddraw_surface7_Flip way) works without having the shadowfb in the client library as well.
The other option would be to restructure the FBO cache to store GL textures instead of surfaces to make the GL texture swapping scheme more efficient. That won't fix the remaining ugliness of flip_surface though.
On 15 July 2015 at 13:58, Stefan Dösinger stefandoesinger@gmail.com wrote:
Yeah, it's ugly, but in the patchset I kept it for now because there are plenty of other problems to solve as well. How we flip the surfaces or surface contents is fairly easy to separate from the rest of the issues we need to fix.
I think it's kind of fundamental to the overall design. (And I think I mentioned this before.)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2015-07-15 um 14:41 schrieb Henri Verbeet:
On 15 July 2015 at 13:58, Stefan Dösinger stefandoesinger@gmail.com wrote:
Yeah, it's ugly, but in the patchset I kept it for now because there are plenty of other problems to solve as well. How we flip the surfaces or surface contents is fairly easy to separate from the rest of the issues we need to fix.
I think it's kind of fundamental to the overall design. (And I think I mentioned this before.)
Do you have any thoughts on how this should work? Otherwise my plan is to go for the client lib callback idea (or make the client libs update their pointers automatically after a present call) and write some tests for how dxgi swap effects and multiple backbuffers work and see what happens.
I'll resend the GL drawable clipping and frontbuffer size patches soon and plan to go on to add separate texture pointers in the swapchain for the WGL back and front buffers. The WGL back buffer is needed to use wined3d_surface_blt from the FBO back buffer to the WGL back buffer. The front buffer separation is for consistency for now, but will later be used to separate the shadow front buffer from the real front buffer. I don't expect the flipping solution to influence this because we'll never flip the WGL buffers and at best invalidate their non-drawable locations.
(Wrt the polygon offset stuff, I'm waiting for Matteo's test draw work before resending that).
On 15 July 2015 at 16:03, Stefan Dösinger stefandoesinger@gmail.com wrote:
Do you have any thoughts on how this should work? Otherwise my plan is to go for the client lib callback idea (or make the client libs update their pointers automatically after a present call) and write some tests for how dxgi swap effects and multiple backbuffers work and see what happens.
I haven't thought about it in detail. The callback doesn't sound all that attractive, but could be better than flip_surface(). The conclusion may very well turn out to be that it's best to keep this in ddraw.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2015-07-16 um 20:22 schrieb Henri Verbeet:
The conclusion may very well turn out to be that it's best to keep this in ddraw.
Do you mean the shadowfb entirely, or just the flip handling? I guess it should be possible to separate shadowfb and flip handling, at least when we don't require that the front buffer shows up at the end of the backbuffer chain (the ddraw test doesn't test for that afair). It'd require similar code in the other client libraries if we ever find a d3d8+ application that requires correct flipping.
-
Henri Verbeet -
Stefan Dösinger