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

[Eric D. <sre...@ho...>]

Sam,

you were right on the money. I had my optimisation set to Maximum Speed. I
turned that off and now everything is fine!! I haven't been able to exactly
pin point which optimisations, but when you use custom optimisations, you
can still set favor fast code and everything will work fine. But the
difference between optimised and non optimised is too subtle to bother.

thank you,

Eric
----- Original Message -----
From: "Stephen J Baker" <sj...@li...>
To: <pli...@li...>
Sent: Wednesday, December 20, 2000 12:11 PM
Subject: Re: [Plib-users] problem with fnt and release mode


>
> 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
>
>
> _______________________________________________
> plib-users mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-users
>