Re: [Mesa3d-users] Rendering Errors in Software Rasterizer (Normals Swapping?)

[tom f. <tf...@al...>]

Hi John,

John Wythe <bit...@gm...> writes:
> I am encountering different rendering behavior between two
> seemingly compatible Linux environments. [. . .] Below are links to
> screen-shots and troubleshooting information:
> 
> Screenshots of the issue:
> http://lh6.ggpht.com/_mTZwuLfG_iE/SvTnUfC0eWI/AAAAAAAAAB0/SUeL9K7CPcU/s800/sc
> reenshots.jpeg

These look (to me) like they might be Z-fighting issues.

Is there any chance of requesting more resolution from the depth
buffer?  You would normally do this when choosing your glX visual.

> Server environment information:
> http://docs.google.com/View?id=ddkkm9rx_2fvwmsdpt
> 
> Desktop environment information:
> http://docs.google.com/View?id=ddkkm9rx_3dgj28nf4

Unsurprisingly, your desktop X configuration is using XCB, probably
with it's libX11 `emulation' of a sorts, while your server
configuration does not have XCB.

> On my desktop I have a NVidia 8800GTS. To try and isolate the
> problem, I wanted to force my desktop to use the software
> renderer. For some unknown reason setting LIBGL_ALWAYS_SOFTWARE=1 has
> no effect.

You're probably using NVIDIAs driver.  Actually, you almost definitely
are, because the only other options are `nv' and `noveau', and of
course the Mesa `swrast' driver. `nv' former can't do 3D, and `noveau'
will crash when used for 3D -- if you're lucky -- AFAICT (never tried
it myself).

If you're using NVIDIA's driver, none of Mesa's environment variables
matter.

> Instead I compiled Mesa using the xlib software driver. When using
> this libGL version the application continues to work just fine on my
> desktop.

Are you absolutely certain you're using Mesa?

I would recommend you remove any drivers your package manager supplies,
as much as possible at least.  This won't be fully possible on Ubuntu
because the removal of all GL impls will make the package manager want
to remove X, but at least remove all nvidia packages.

> The server on the other hand, is a managed environment without root
> access. The default version of libGL caused the application to crash,
> which initially, I thought was due to an older version of Xvfb. After
> learning much more about xorg, I came to realize that it was not the
> version of Xvfb that made things marginally work, but rather the
> libGL version that was built as a result of building Xvfb/Mesa. Now
> I am only building Mesa and libXmu on the server and using the older
> Xvfb.

CentOS, IMHO, is trash.  Everything's too damn old on it; for software
I work on, we're always hitting things like old compilers not accepting
valid templates or similar.  If you can update the toolchain, I would
recommend as much.  Or better yet, put a Debian stable / Ubuntu LTS /
hell even openSUSE on the machine and save yourself the pain.

> On the server experiencing the problem, I have set MESA_DEBUG=FP
> to try and get some debug information. I also tried to set
> LIBGL_DEBUG=verbose but that seems to have no effect on either
> machine. Two messages were encountered at various times -only- on the
> server:
> 
> "Mesa warning: couldn't open libtxc_dxtn.so, software DXTn
> compression/decompression unavailable"
> and
> "Mesa warning: XGetGeometry failed!"
> 
> 
> I downloaded the libtxc_dxtn from
[snip]

I would not worry about it.  Mesa will give that warning regardless
of whether or not compressed textures are actually used.  I encounter
very few apps that actually use them (I suppose games would frequently,
though?), and in any case the image you sent makes me think there's no
texturing at all in your app, anyway.

> Overall these two machines are
> * Using the same version of Mesa
> * Both using software rendering
> * Both using the same version of wine
> 
> Which leads me to believe this must be a subtle dependency problem,
> either at runtime or build time. At this point though, I would have
> no idea what could affect the rendering in such a way.

My best guess is XCB/X11.  Try configuring Mesa with --enable-xcb.  If
the app is threaded, --enable-glx-tls is probably a good idea as well.

Beyond that my guess is issues with the ancient toolchain provided by
CentOS.

You might consider OSMesa for this use case as well.  Though, I guess
without source to the application, your only option would be to hack
OSMesa into wine.

HTH,

-tom