RE: [Plib-users] problem with fnt and release mode
Brought to you by:
sjbaker
From: Paul B. <pbl...@di...> - 2000-12-20 18:56:15
|
More than likely it is either "global optimizations" or "assume no aliasing". These two cause the most problems. Paul > -----Original Message----- > From: Eric Desrosiers [mailto:sre...@ho...] > Sent: Wednesday, December 20, 2000 11:28 AM > To: pli...@li... > Subject: Re: [Plib-users] problem with fnt and release mode > > > 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 > > > > _______________________________________________ > plib-users mailing list > pli...@li... > http://lists.sourceforge.net/mailman/listinfo/plib-users > |