d3d8 test failure, more details.

David Anderson davea42 at earthlink.net
Thu Dec 3 18:26:49 CST 2009

Thanks to James Mckenzie and Austin English for earlier hints. I've
installed more stuff (ubuntu packages) and spent a bit more time with d3d8.

I assume most people get these tests to work, so I'm a bit distressed I 
cannot seem to get
them to work properly, 100%.
The large amount of test code that 'just works'  is impressive.  I'd be 
I was not breaking things in any patch I submit
if I could figure out why I'm not getting 100%
(that is, what the heck might I be doing wrong?).

Any hints/suggestions would be welcome.

In dlls/d3d8/tests/visual.c one has the call that gets errors:

  1357     if (caps.VertexShaderVersion >= D3DVS_VERSION(1, 1))
   1358     {
   1359         test_rcp_rsq(device_ptr);
   1360     }

and  test_rcp_rsq() does some *VertexShade calls not made elsewhere.

The last few lines of 'make test' output in d3d8/tests are:

fixme:d3d:WineD3D_ChoosePixelFormat Add OpenGL context recreation 
support to SetDepthStencilSurface
fixme:d3d_draw:drawPrimitive Using software emulation because manual fog 
coordinates are provided
visual.c:598: Test failed: Color components differ: c1 = 80, c2 = 00, c3 
= 80
visual.c:632: Test failed: Color components differ: c1 = 80, c2 = 00, c3 
= 80
visual.c:634: Test failed: Color component value is 80
make: *** [visual.ok] Error 3

These failures are in test_rcp_rsq(), the function called at line 1359.

Note that other calls to to getPixelColor()  (a function in the
test code, tests/visual.c) work fine.
Only when a  couple of special Shaders are invoked does getPixelColor() get
something the test does not expect.

Possibly IDirect3DDevice8_CreateVertexShader() is not setting things up 
right or
somehow the 'DRI'  code in package libgl1-mesa-dri is not being effective?

I stuck a couple sleep(5) calls in the test source (to slow things
down at the error points) and I can see the shader code
has an effect visually (the test code generates small-ish windows with 
color blocks).

Compiling d3d8 and its  test code -g (that is, no -O2) gets exactly the same

Ubuntu9.10.    Intel(R) Core(TM)2 Duo CPU     E8500 cpu.  ATI 4350 PCI 
q2 616: dpkg-query -l '*mesa*'
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version        Description
un  libgl1-mesa    <none>         (no description available)
ii  libgl1-mesa-de 7.6.0-1ubuntu4 A free implementation of the OpenGL 
API -- G
ii  libgl1-mesa-dr 7.6.0-1ubuntu4 A free implementation of the OpenGL 
API -- D
ii  libgl1-mesa-dr 7.6.0-1ubuntu4 Debugging symbols for the Mesa DRI modules
un  libgl1-mesa-dr <none>         (no description available)
ii  libgl1-mesa-gl 7.6.0-1ubuntu4 A free implementation of the OpenGL 
API -- G
ii  libgl1-mesa-gl 7.6.0-1ubuntu4 Debugging symbols for the Mesa GLX runtime
un  libgl1-mesa-sw <none>         (no description available)
ii  libglu1-mesa   7.6.0-1ubuntu4 The OpenGL utility library (GLU)
ii  libglu1-mesa-d 7.6.0-1ubuntu4 The OpenGL utility library -- 
development fi
ii  mesa-common-de 7.6.0-1ubuntu4 Developer documentation for Mesa
un  mesa-glide2-de <none>         (no description available)
ii  mesa-utils     7.6.0-1ubuntu4 Miscellaneous Mesa GL utilities
un  mesag-dev      <none>         (no description available)
un  mesag3         <none>         (no description available)
un  mesag3+ggi-dev <none>         (no description available)
un  xlibmesa-dev   <none>         (no description available)
un  xlibmesa-dri   <none>         (no description available)
ii  xlibmesa-gl-de 1:7.4+3ubuntu1 transitional package for Debian etch
un  xlibmesa-glu-d <none>         (no description available)
un  xlibmesa3      <none>         (no description available)
un  xlibosmesa-dev <none>         (no description available)

The 'libgl1-mesa-swx11*' packages are not installed,  swx11 seems to be 
with some of the mesa stuff above (according to synaptic package manager).

Any hints/suggestions would be welcome.

More information about the wine-devel mailing list