WineD3D texture bug
thunderbird2k at gmx.net
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 codesampler.com. 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
http://roderick.student.utwente.nl/sample.tar.gz 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
http://roderick.student.utwente.nl/log.bz2 The problem appears near the
'LoadTexture' lines for textures created with 'pool 2' (D3DPOOL_SYSTEMMEM).
More information about the wine-devel