Card upgrade -- missing driver symbols

OpenGL Development
#1

Hi folks.

I recently upgraded my video card from an nVidia GF4 ti 4600 to an ATI Radeon 9800XT (woo! ;D). I figured my simple OpenGL stuff would run a lot faster, but no dice. I’m sure that has to do with inefficiencies in my code… The real reason I’m posting though is that I get odd messages on System.out when I exit my program now:

[quote]NOTICE: GL_EXT_vertex_shader disabled because of missing driver symbols
NOTICE: GL_NV_point_sprite disabled because of missing driver symbols
[/quote]
I don’t specifically reference these items. My code isn’t all that fancy yet – I don’t use any special extensions, etc. Is this some optimization for nVidia cards that LWJGL tries to do? (The GL_NV_point_sprite is nVidia specific, isn’t it?)

Browsing LWJGL src, I see the reference to the first extension when it runs the check for the available extensions… Perhaps it is thread priority that keeps the comment hidden until the end?

Thanks again for your comments!

PS: Yes, I have the latest drivers for my card. :slight_smile:

#2

ATI’s drivers claim to support those two extensions but then they fail to actually provide all the function pointers for them, so we disable the extensions currently. Please contact ATI and hassle them about it! The more developers complain the better.

You might want to use the ARB extensions anyway as they’re better.

Cas :slight_smile:

#3

Thanks for the info. I don’t specifically call those extensions… I simply call glEnable, glShadeModel… for a few basic things like Lighting and GL_SMOOTH, etc. In fact, if I comment out all of my enables and disables, lights, etc, I still get the same messages.

Could you explain how to use one versus the other? (Pardon in advance if this is a dumb question… :-[)

#4

It’s actually a debug log, there’s no problem with it being output - it’s just letting you know that the card’s drivers are a bit dicky.

You use extensions merely by choice:


if (GLCaps.ARB_something) {
GL.glSomeFunctionARB();
}

but you must be sure that they are supported by checking GLCaps first or you’ll get a runtime exception.

Cas :slight_smile:

#5

So the ARB methods are enhanced versions basically? I understand ARB to mean OpenGL’s Architecture Review Board…

Curious: Maybe this isn’t the place to ask, but what are some ARB functions that you find yourself commonly using (versus using the non-ARB one)

#6

Not really. ARB extensions are just more common than the vendor specific ones. Depending on GL_NV extensions will mostly result in your program will only run on nvidia hardware. Same thing applies for GL_ATI. To maximize the portability of your game, you shouldn’t use extensions at all if avoidable, and if you do, you should provide fallbacks in case the extensions are not available.

  • elias
#7

Ah. Thanks for helping clear that up!

#8

What we try to do is pick several combinations of extensions and write specific renderers for each combo.

In AF I’ve got three renderers for the background - one does dynamic dot3 rendering, one does plain rendering, and the other one uses pure OpenGL1.1 with no extensions at all.

Likewise my sprite renderer takes advantage of a few extensions if they’re available - currently I only use NV_vertex_array_range2 but I should really add ARB_vertext_buffer or whatever it’s called for future niceness on all cards. The idea is to make the actual rendering somewhat divorced from what you want to achieve and make it all a bit “pluggable”.

Cas :slight_smile:

#9

Did some checking at ATI’s site and they claim to indeed support the two aforementioned extensions in their current driver. (which I have) :confused: Is there any way to verify that the card supports these extensions myself outside of lwjgl?

#10

Well, there’s lots of ways, and indeed they do claim to support them, but for safety’s sake we’ve disabled it. I’m wondering whether this is wise though as it’s an important extension and the missing functions are rarely used. We might be better of putting a special hack in and throwing a runtime exception rather than disabling the extensions just because a couple of rare functions aren’t implemented.

Cas :slight_smile: