This may be of little use to most people, unless you are considering buying a
new Video card / sytem.. Or just like to hear me complain about OpenGL driver
problems.

We've recently tested our VisKit app (OpenGL on NT) on various machines and
video cards. I thought I'd take a minute to describe the results.

First off our App is definitely going beyond whatever 'test' programs the
various card makers use when they quote having a "Full OpenGL ICD" (although
half life, which shipped w/ the ATI, had polygon offset issues). We're using
homogenous texture coords (glTexCoord4*()) and polygon offset (ala vkDecal).
We're also have a multithreaded app where textures are getting paged in/out in a
second thread.

So:
Test machine #1:
P2-400 (128M ram), NT 4 SP4 (using VC6.0 w/ SP2)
- software rendering only: works perfectly, albeit slow. < 1 fps
- Raven (3dfx banshee): I don't think I could get it to work ever.
- ATI Rage Fury (128): Ok, here is the current winner of the suckiest driver
award. Textures come in completely wrong (grey scale almost, w/ banding and the
texture is squished + repeated). This happens in any VK example. Polygon offset
(vkDecal) works for possibly 1 decal, but fails for more. And finally, in our
app we get a ATION4AA.DLL (ati's dll) unhandled exception when drawing.. "You're
fired!" Back to the store you go. :)

(Different machine, same specs)
- Permedia 2 (tested on 2 machines) works perfectly, ~8-10fps (best openGL
driver we've tested w/o zero problems, just slow)

(Different machine, same specs)
- TNT (STB 4400) (tested on 2 machines) works perfectly, ~20-25 fps (16bit)
nVidia is the winner of the best driver for our test, with one MAJOR exception.
When debugging our app (and my code at home) the following frequently happens.
After running a GL app in a debug session and killing the session from
DevStudio, it becomes very likely that the next time your go to recompile your
code, you will get a blue screen of death (not run it, just hit "Build"). Not
only that, it has happened multiple times on different machines that one of the
open source files will get completely corrupted/destroyed. This was using the
first version of the detonator drivers (perhaps they have release new ones? i
can't get to nVidia's site at work for some reason).

Intergraph TDZ-2000-GX1 (Dual Xeon processors) 512M ram
- Wildcat 4000 card: homogenous texture coordinate problem (glTexCoord4*) has
serious problems (textures get destroyed on polygons as you approach them
(clipping problem?)) ~25 fps (32 bit) <I would like to say that Intergraph has,
after 2 days, still not responded to my email or our post on their newsgroup>
This machine was ~$12,000 i think.
Paging of textures works perfectly. There is no noticable pausing/jumping as
they are paged in (as we expected on a dual processor system)
- TNT (STB 4400) - This setup is very nice.. ~25fps (16bit look almost as good
as 32bit) which makes you wonder what the Wildcat's outrageous price gets you..
Paging of textures is perfect. Blue screen o' death happens on this machine
also.

SGI Visual Workstation 320 - Dual P2-450s (not xeons) 512M ram,
configued w/ 8, 16, 96 Megs of system RAM for graphics use showed no
preformance difference in our app. (understandable for our app)
- Cobalt Gfx - Very impressive, no openGL driver problems so far. ~30fps making
it the fastest in the group. However, there is noticable pausing/skipping as
textures are loaded in the 2nd thread and we're moving around in the app. We
cannot seem to explain this. We took them out of the scene (to test if it was
the glBindTexture) call, but it appears to be the act of file IO and converting
the image to a vk texture from a PNG. (and yes the thread does appear to be
running on the 2nd processor) This makes the SGI fairly useless to demo our app
on.

Finally, due to an unknown problem (!?) after paging in/out a large number of
textures, both the TNT and Wildcat textures become completely destroyed. We
have not tested it long enough of other machines to see if they show a similar
problem.
Textures (instantly) become all black except a few which appear to shrink into
nothingness (black replaces the images). Ok, yes, it's odd, but if you saw it,
you'd say the same thing.. Perhaps the texture memory on the cards is getting
filled/hosed or it's a VK issue, i can't tell yet.

I think this comes close to covering everything we've tested.. Oh, we did do
some DirectX Media testing to grab frames of video and use them as textures.
This works on software rendering, permedia 2, and Wildcat. The TNT appears to
downsample the bitdepth of the video to 256colors or something crazy as the end
result is completely different (banding on walls etc) from the other cards.
This is still odd to me as I thought the video->texture code should run in an
system buffer w/ nothing to do w/ the video card. On the SGI Vis Workstation the
video setup calls fail in a call they shouldn't, so I can't say what happens on
it.

Just thought some of you might find this interesting/useful.
-doug


-- Douglas H. Cox - dougcox@... - http://public.surfree.com/dougcox --

--------------------------------------------------------
$14.95 Unlimited Internet Access, http://www.surfree.com