Hello developers (mostly direct3d hackers),
the infamous crash in d3d9:stateblock [1] is caused by a call sequence that is forbidden according to the DirectX SDK documentation. The switch_rendertarget test makes a new swap chain, and sets its backbuffer as new rendering target, and then releases the swap chain. The backbuffer is obtained by GetBackBuffer on the new swapchain. The SDK tells states explicitly that you have to release all surfaces obtained by GetBackBuffer before you release the swapchain itself. [2]
In Windows, this buggy behaviour seems to work nicely (no crash in the d3d9:stateblock test and no errors with maximum debugging settings in the debugging d3d9 runtime), whereas on wine, at releasing the backbuffer finally, some access to the state is made which has already been released with the swapchain.
So, we have two options: - Consider using backbuffer of released chains buggy: Fix the test to not release the swapchain Upgrade the FIXMEs in dlls/wined3d/swapchain.c, lines 95 and 104 to ERR - Implement behaviour seemingly compatible to Windows: Have a hidden reference counter to the swap chain or for the contexts to prevent them from getting freed too early.
Does anyone knows whether the test has this been written buggy on purpose (some app does this), or it is by accident?
Regards, Michael Karcher
[1]: Bugs 9916, 12246 [2]: http://msdn.microsoft.com/en-us/library/bb205902(VS.85).aspx
Michael Karcher wrote:
Does anyone knows whether the test has this been written buggy on purpose (some app does this), or it is by accident?
Probably the first one - I wrote the test with rather limited understanding of how rendertargets work. I don't think there was a specific application need driving this test.
The intention was to test how the stateblock behaves under different event sequences - for example if the rendertarget is changed. I see the test is doing its job uncovering interesting behavior :)
Ivan
Ivan Gyurdiev wrote:
Michael Karcher wrote:
Does anyone knows whether the test has this been written buggy on purpose (some app does this), or it is by accident?
Probably the first one - I wrote the test with rather limited understanding of how rendertargets work. I don't think there was a specific application need driving this test.
The intention was to test how the stateblock behaves under different event sequences - for example if the rendertarget is changed. I see the test is doing its job uncovering interesting behavior :)
s/ "first one"/"second one"/
I guess the reason why switching the render target was tested in particular was some weird code manipulating the stateblock when Wine was switching rendertargets, which I was interested in testing. The last event sequence should probably be dropped if it's invalid, but I would keep the rest, since the test has uncovered a number of bugs in the past.
Ivan
Am Montag, den 02.06.2008, 06:23 -0400 schrieb Ivan Gyurdiev:
Ivan Gyurdiev wrote:
Michael Karcher wrote:
Does anyone knows whether the test has this been written buggy on purpose (some app does this), or it is by accident?
I guess the reason why switching the render target was tested in particular was some weird code manipulating the stateblock when Wine was switching rendertargets, which I was interested in testing. The last event sequence should probably be dropped if it's invalid, but I would keep the rest, since the test has uncovered a number of bugs in the past.
Oh, everything is valid, except for the IUnknown_Release(swapchain) in switch_render_target. It must not happen before the render target gets reverted in revert_render_target. That means, a IDirect3DSwapchain9 variable has to be added to the event_data block to keep the pointer between switch_render_target and revert_render_target.
Today, I am on high workload on my paid job, so don't expect a patch until 23:00 CEST. Feel free to fix it yourself, if you want.
Regards, Michael Karcher
With textures, the surface and the texture(the container) share one reference count. In the case of swapchains the swapchain is the container, so a GetBackBuffer would increment the swapchain's refcount to 2. So the swapchain wouldn't be destroyed before the backbuffer was released.
I am not sure if the texture refcounting applies to swapchains as well. Does the test test refcounts? If not, it might be worth adding a test. A fix would be in dlls/d3d9, not wined3d.
-
Ivan Gyurdiev -
Michael Karcher -
Stefan Dösinger