Re: [Plib-users] problem with fnt and release mode

[Stephen J B. <sj...@li...>]

The screenshots I've seen of this look VERY similar to a problem
that was common under Linux *ONLY* on the G200 and G400 cards.

The symptoms were exactly the same as the ones you guys are
reporting - the top half of the font texture map being garbage.
In the case of the Linux drivers, the bottom half of the map
was the bottom half of the texture map - whilst in the Windoze
case, it appears to be two copies of a half-resolution version.

But those symptoms are just too similar for that to be a
coincidence.

I *thought* that the bug under Linux was caused by Mesa - and
had subsequently been fixed...but I don't have a G400 card -
and my G200 isn't currently installed in any of my machines
so it's a pain to go back and test it.

The issue of it failing in RELEASE mode versus DEBUG mode is
also symptomatic of problems I've heard of before.  MSVC does
some VERY bad things when you are in DEBUG mode:

  1) It makes sure that all uninitialised variables are
     zeroed (Those guys at M$ are COMPLETE IDIOTS!)...so
     if you have an uninitialised variable, it works just
     fine in debug mode and crashes horribly in release mode!

  2) It turns off some of the compiler optimisations.  Since
     some versions of MSVC very buggy optimisations, that
     can conceal the effect of compiler bugs.  Trying RELEASE
     mode compilation with all of the optimisations turned
     off would be an interesting experiment.

  3) I don't use M$ software any more - but didn't I hear somewhere
     that when you compile in debug mode, the debugger loads different
     versions of the library DLL's?   If that's the case, maybe you
     are getting a different Matrox driver when in debug mode.

Whilst I don't completely rule out a FNT library bug, it is a
fact that this problem NEVER shows up on non-Matrox hardware
- and when it does show up, it does so both under Linux and
Windoze with similar symptoms - despite there being a totally
different set of drivers in each case.

That's *very* suspicious.

You might ask "if it's a hardware problem - how come I don't
see it in other programs?"   If I had to guess, I'd say it
was because FNT uses MIPmapped luminance+alpha textures -
which are VERY rarely seen in other applications.

Not only that - but look closely at those bogus screen shots.

The bottom-left corner of the FNT test screen should be
one copy of the entire texture map.  What you see is the
top half of the image being garbage (in one case it's
clearly garbage left over from some other program) -
and the bottom half is TWO copies of a half-resolution
version of the texture.

If I had to guess what that means, I'd say that we are
seeing the luminance and alpha data (which look identical)
of the lower level MIPmap.  This points to a memory allocation
error inside the device driver.  Perhaps it's packing the
data into memory as if it was an RGBA texture or something
and mis-computing the addresses.

At any rate - if the data in the top half of the map was
just total garbage - then I'd concede that it *could* somehow
be an error in 'FNT' that sends garbage down to the G200/G400
card.  HOWEVER, in one of those screen shots, there is a perfect
picture of the front of a building in the upper half of the
texture map.  What are the odds of garbage from the main memory
of your CPU being a perfect picture of a building?  Pretty
small I'd say.  OTOH, what are the odds of garbage in the
TEXTURE MEMORY of the card being a perfect picture left
over from some previous application?  Almost certain!

So, it's 99.999% certain that the garbage ISN'T being
transmitted to the hardware from main memory - it's
texture data that's never being written to down in the
Matrox hardware.

There is no way to do that in OpenGL.  There is absolutely
no sequence of API instructions that can make it do that.

*IF* I was using the 'glTexSubImage' or 'glCopyTexSubImage'
commands - then *maybe* we could attribute this to poor
error checking in the drivers (and in the drivers of every
other card that FNT runs on - which are MANY)...but I
don't ever do that.  The only way I write to texture
memory is using glTexImage2D - and that API only permits
you to write to a whole map.  You can't even try to draw
an image using a map that you havn't downloaded...the
API prevents that too.

Hence, we may deduce that the G200/G400 has some kind of
a hardware problem - or some kind of driver bug that
was somehow propagated into Mesa by virtue of bad information
passed to the OpenSource driver developers by the G200/G400
developers at Matrox.

So, right now - using the facts you guys have given me - I'm
entirely unconvinced that this is a FNT bug...although
anything's possible the odds are HEAVILY against it.

I think that the next step should be to extract the font
loader code from FNT, boil it down to a SIMPLE OpenGL/GLUT
program that exhibits the problems - and (presuming that
we don't thereby discover a FNT library bug) ship that
off to Matrox as a bug report.

----
Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1