Re: [PATCH 3/5] wined3d: Don't set WINED3DUSAGE_RENDERTARGET on the front buffer.

[Stefan Dösinger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 2013-09-04 08:56, schrieb Henri Verbeet:
> We never render directly to the front buffer, and in case of e.g. a
> P8 front buffer, we would fail surface creation if we were to
> enforce format restrictions.
> This patch uncovers a problem I am not quite sure how to solve.

We set the frontbuffer as render target in wined3d_device_init_3d if
there's no backbuffer, i.e., when ddraw is used. In theory this
doesn't matter because we're not rendering to it, just blitting.

Similarly, dlls/ddraw/device.c calls set_render_target to set the
ddraw frontbuffer on release. The call fails now, but that doesn't
cause any visible problems yet. There is a zombie wined3d surface
left, but it goes away on ddraw shutdown or when a new ddraw
IDirect3DDevice is created.

However, when we create wined3d textures for standalone surfaces, the
ddraw surface isn't destroyed until the wined3d surface goes away
because we're waiting for the callback. This keeps the ddraw surface
alive as well.

The ddraw tests notice this because keeping the IDirectDrawSurface
alive means keeping an IDirect3DDevice1 alive as well. The device
holds a reference to the attached viewport(s), which triggers a
failure in the ddraw1 tests.

The test failure was lingering before, I fixed this by adding a
similar set_render_target call to ddraw_surface_release_iface_destroy.
See the attached patches for reference.

The easiest solution seems to create a separate dummy render target
that ddraw can use to unset application targets. That still leaves the
problem that we're initializing wined3d with an invalid render target now.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSJ6NiAAoJEN0/YqbEcdMwqEsP/3We5UyaUsuUmh8DuqpUDozy
OPFdfg0defIGBB3xdcRPYtwz265jsThxK8ek/vb24E1fJXJsm7zE1CJq1jUh/Beo
X1zkewvL29WpriNvh11AW0+FIrE2XMwmr/5ekHQMXM4Evv2aRWG6zmWj0Wv1zR+x
EcFgHE7J6boOIHtogPoge8KHiVULjxm91Dpnariab0YzUNDUfaHUXopWH0N4hb3T
W5ds4cnHLOapOk8ihDfyAcBXOH4JlvConKKG4zDtbcuovp01yLR+eF03m/eBqt5m
0x3VpPyyaIJpFtOERAi9CqbN0Xuy3wOLmtgHsjy8Qh1wKr/I+DmkuakcsJYELmrY
Ou7n+fDRceJyxdqP8vGtwlsP7Skkyxet/KYt7xbWsMcIcMjFDv6KW6YMyOGg2aJM
O4o8gEFH3zgBQqLBsOf+O85GbQ2ZTLFoRaWkbRYFYYBaypd+S4TBRn9i0gL0Qw/q
KImvYV47HcBK0uTuuV0dG/2YzUs/JraKGMU0sVmUNiDqfOm7+R+NAlU86jQ4PNo+
G0cV2IpEt9Bk/06XmSWI944X7NTe/ZDXs8Fa5MveLk87wETzg54F3RK2AoyHPY59
UK/3nisrRmUDeRZHiRp53E6eSW7VSXoHUgqeHt04fvLheMXpAnuibKJcKGTYqYMe
kfkNuq73chpb9uZhe0EJ
=PCrO
-----END PGP SIGNATURE-----

[PATCH 3/5] wined3d: Don't set WINED3DUSAGE_RENDERTARGET on the front buffer.

[Henri Verbeet]

On 4 September 2013 23:18, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote:
> We set the frontbuffer as render target in wined3d_device_init_3d if
> there's no backbuffer, i.e., when ddraw is used. In theory this
> doesn't matter because we're not rendering to it, just blitting.
>
> Similarly, dlls/ddraw/device.c calls set_render_target to set the
> ddraw frontbuffer on release. The call fails now, but that doesn't
> cause any visible problems yet. There is a zombie wined3d surface
> left, but it goes away on ddraw shutdown or when a new ddraw
> IDirect3DDevice is created.

Right. I had noticed the FIXME, but didn't quite realize we already
enforced it. My long term plan for fixing that FIXME was to get rid of
the restriction on setting render target 0 to NULL, since afaik that's
valid in d3d10 anyway.