WineD3D refcounting fun part II :)

Roderick Colenbrander thunderbird2k at gmx.net
Thu Feb 23 13:46:04 CST 2006


Hi,

During the d3d8 -> wined3d transition I noticed one huge refcounting issue 
which affects both d3d8 and d3d9. The issue is illustrated by running 
http://www.codesampler.com/source/dx9_multitexture.zip (the same demo is 
available for dx8) and then modify wined3d's globalChangeGlRam in 
wined3d_main.c to let it output how it adjusts the memory.

If you run the test on d3d9 or using oliver's full d3d8 patch, you'll notice 
that not all memory is returned when quitting the program. (In 3dmark2001 
this is a big issue as because of this we are out of memory after running a 
few demos) The problem appears that wined3d surfaces contain a reference to 
the wined3d device. So when you run a game the d3d8 and wined3d device 
refcounts are out of sync (the wined3d refcount is a lot higher because of 
all the refcounts from the surfaces).

At the moment you quit a game the d3d8 device refcount nicely becomes zero and 
the object tries to kill itself. The release function also calls the wined3d 
device release function but the wined3d device object won't kill itself 
because its refcount doesn't become zero due to all the surfaces which still 
contain a reference to it. (the surfaces which useally are front-, 
backbuffers and more are normally released in the wined3d device release call 
when the refcount becomes zero)

One way to 'fix' the problem is to let d3d8/d3d9 handle the reference counts 
(remove the refcounts from wined3d; and let d3d8/d3d9 call some cleanup 
function to remove the garbage in case its refcount becomes zero)

Does anyone have a better solution?

Roderick



More information about the wine-devel mailing list