Re: d3d8: GetDepthStencilSurface/GetRenderTarget refcount issue
Hi, > Well yes, but you don't know if those access the field directly or > call GetRenderTarget / GetDepthStencil internally. Good point > Btw, this construction looks very similar to what happens when you > call GetVertexDeclaration after having set an FVF with SetFVF. Yup pgprcQbBEFlEt.pgp Description: PGP signature
Re: d3d8: GetDepthStencilSurface/GetRenderTarget refcount issue
On 18/10/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote: Yes, but some methods in WineD3D need the back buffer and the front buffer implementation pointer, like Present or LockRect/UnlockRect Well yes, but you don't know if those access the field directly or call GetRenderTarget / GetDepthStencil internally. Btw, this construction looks very similar to what happens when you call GetVertexDeclaration after having set an FVF with SetFVF.
Re: d3d8: GetDepthStencilSurface/GetRenderTarget refcount issue
> > We have an > > IDirect3DDevice?_AddRef call in CreateSurface / CreateTexture... Native > > seems to have this AddRef call in IDirect3DResource_AddRef: > > > > if(oldref == 0) IDirect3DDevice8_AddRef(This->myDevice); > > > > I guess this is the first thing we have to change. > > Not sure how you read that from the test. Not from this test, but I had a test which did this: CreateVertexBuffer(&vb) // ref++ Release(vb) // ref-- AddRef(vb) // ref++ CreateVertexBuffer(&vb) //ref++ SetStreamSource(device, 0, vb); //ref unchanged Release(vb) //ref-- GetStreamSource(device, 0, &vb);//ref++ and check the device refcount after each call, with the results from above. I didn't send the test because it did an incorrect thing(release to 0, then addref). > It could just be that the surface object is only created on the first > call to GetRenderTarget. Note that in this test we don't do any actual > rendering, so it's not impossible that in a typical application the > depth stencil would already be created the moment GetRenderTarget is > called. Yeah, I mentioned that. But I suspect that the surface resources are created with the device, just that the COM object is constructed on the first GetRenderTarget call. > > It could be that the implicit render target and auto depth stencil COM > > objects are not COM objects in d3d's internal management and that they > > are constructed in the first call to GetRenderTarget. But we won't be > > able to do that. Or well, we can do it in d3d8.dll and d3d9.dll, but not > > in wined3d.dll. > > Sure we can. Regular surfaces are currently created with a callback to > d3d8 / d3d9 as well. Yes, but some methods in WineD3D need the back buffer and the front buffer implementation pointer, like Present or LockRect/UnlockRect > I wonder what happens if you release the surface you get from > GetDepthStencilTarget, and then try to do some rendering with the > device. I suspect that it won't have any effect(except that the refcount falls to 0) pgpqQprvf1tNS.pgp Description: PGP signature
Re: d3d8: GetDepthStencilSurface/GetRenderTarget refcount issue
On 18/10/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote: We have an IDirect3DDevice?_AddRef call in CreateSurface / CreateTexture... Native seems to have this AddRef call in IDirect3DResource_AddRef: if(oldref == 0) IDirect3DDevice8_AddRef(This->myDevice); I guess this is the first thing we have to change. Not sure how you read that from the test. The next is that the auto depth stencil surface and the implicit render targets seem to be created with a reference count of 0, that is why they have a ref of 1 on the first GetRenderTarget, and why the AddRef from above increases the device refcount. It could just be that the surface object is only created on the first call to GetRenderTarget. Note that in this test we don't do any actual rendering, so it's not impossible that in a typical application the depth stencil would already be created the moment GetRenderTarget is called. It could be that the implicit render target and auto depth stencil COM objects are not COM objects in d3d's internal management and that they are constructed in the first call to GetRenderTarget. But we won't be able to do that. Or well, we can do it in d3d8.dll and d3d9.dll, but not in wined3d.dll. Sure we can. Regular surfaces are currently created with a callback to d3d8 / d3d9 as well. I wonder what happens if you release the surface you get from GetDepthStencilTarget, and then try to do some rendering with the device.
Re: d3d8: GetDepthStencilSurface/GetRenderTarget refcount issue
Am Mittwoch 18 Oktober 2006 10:18 schrieb Markus Amsler: > I'm trying to solve bug 5872 http://bugs.winehq.org/show_bug.cgi?id=5872 > BF1942 calls GetDepthStencilSurface/IUnknown_Release and checks the > refcount to be 0, but wine returns 1. (test hack attached) > > I have done some testing: The first call to GetDepthStencilSurface > increases the refcount of the device, any subsequent call increases the > refcount of the surface. > On release calls the refcount of the surface gets decreased. If the > refcount is 1 the release call decreases the surface refcount AND the > device refcount. > > The exact same behaviour shows GetRenderTarget. d3d9 does also the same. > > Any ideas how we should implement this behaviour? Doh - refcounting fun :-/ We know that surfaces, textures, ..., hold a reference to the device, which is what you see with the increased device refcount. We have an IDirect3DDevice?_AddRef call in CreateSurface / CreateTexture... Native seems to have this AddRef call in IDirect3DResource_AddRef: if(oldref == 0) IDirect3DDevice8_AddRef(This->myDevice); I guess this is the first thing we have to change. The next is that the auto depth stencil surface and the implicit render targets seem to be created with a reference count of 0, that is why they have a ref of 1 on the first GetRenderTarget, and why the AddRef from above increases the device refcount. And the implicit surfaces aren't destroyed until the device is destroyed. This will be fun to implement with our release code :-/ It could be that the implicit render target and auto depth stencil COM objects are not COM objects in d3d's internal management and that they are constructed in the first call to GetRenderTarget. But we won't be able to do that. Or well, we can do it in d3d8.dll and d3d9.dll, but not in wined3d.dll. But applications don't see what we are doing in wined3d anyway. What you need for sure is a really good test case to convince AJ that all this is correct ;-) pgppTWc6BwaTK.pgp Description: PGP signature
