WineD3D texture bug

Roderick Colenbrander thunderbird2k at
Sun Feb 5 15:20:50 CST 2006


The past few days I have experimented with Oliver his d3d8 patches. As 
mentioned before the patches work fine except Shaders have problems. There's 
one texture/surface related problem I'm trying to debug but I don't know how 
to proceed nor how to fix the problem.

When you create a texture in d3d8 you can specify in what type of memory it 
needs to be stored. There are roughly two options of which one is to store 
the textures in video memory and the other in system memory. Storing of 
textures in system memory has limitations compared to video memory. The main 
one is that textures placed in system memory can't be directly used for 
rendering. In order to render the texture for instance need to copy the data 
to another texture (one which isn't stored in system memory).

The problem I'm having appears in 3dmark2001 which creates some textures in 
system memory and then it directly renders them using DrawPrimitive. This 
works on Windows. Based on the information (from MSDN) which I gave before 
this is illegal but somehow it works. In case of wined3d we check in our 
LoadTexture call if the texture is in system memory and if it is, we don't 
render it. (which is ok according to MSDN) This 'correct' piece of code 
causes that no textures appear in 3dmark, removing the check fixes 3dmark.

I tried to test the behaviour of textures in system memory on windows using 
some multitexturing sample from By default the sample 
uploaded textures to video memory and I changed it to system memory. Directly 
rendering textures from system memory didn't work as expected from the MSDN 
docs. (BTW the demo doesn't work correctly on cedega, they seem to allow 
rendering of textures in system memory. I guess this is a bug but perhaps 
this is a 'feature') The sample also works correctly on wine in case of the 
d3d8->wined3d patches, on the current d3d8 it would be as broken as on 
Cedega. (The demo is available from from the included files 
dx8_multitexture.exe or whatever is the original sample and sample.exe is the 
one which uses textures from system memory)

To summarize 3dmark2001 possibly uses incorrect d3d8 code but the code works 
fine on Windows. I tried to test the behaviour using a test (perhaps not a 
good test) and windows appeared to work correctly and the same for wine. 
Further oliver had the same problem in maxpayne2 (it uses the same 3d engine 
I think) and he used a similar hack.

Does someone has some good ideas for locating the problem? I think my d3d8 
test is good enough but perhaps it isn't. I have uploaded a log of 3dmark to The problem appears near the 
'LoadTexture' lines for textures created with 'pool 2' (D3DPOOL_SYSTEMMEM).


More information about the wine-devel mailing list