I implemented ARB_vertex_program, and it works fine on a GeForce3 with drivers 40.41.

But, I tried on a Radeon 9700 with drivers 32.59 and it crashes !!
I appears that glBindProgramARB(GL_VERTEX_PROGRAM_ARB, 0); causes the crash. If I remove it, it doesn't crash, but the display is still incorrect.
Anybody experienced problems with ARB vertex programs on ATI cards ?

fresh

09-19-2002, 09:56 AM

Can you make a small sample program which demonstrates the problem and post the source here?

opla

09-19-2002, 11:27 AM

I'll make a sample program tomorrow (if I have time, I don't own the Radeon 9700, I have limited access to it).

fresh

09-19-2002, 12:58 PM

I'd be happy to test it for you on a 9700 when you post it.

NitroGL

09-19-2002, 02:43 PM

Originally posted by opla:
I implemented ARB_vertex_program, and it works fine on a GeForce3 with drivers 40.41.

But, I tried on a Radeon 9700 with drivers 32.59 and it crashes !!
I appears that glBindProgramARB(GL_VERTEX_PROGRAM_ARB, 0); causes the crash. If I remove it, it doesn't crash, but the display is still incorrect.
Anybody experienced problems with ARB vertex programs on ATI cards ?

Doesn't crash here, just causes an "invalid value" error.
Why would you want to do that anyway? Just disable VERTEX_PROGRAM_ARB when you don't want to use the vertex program.

Humus

09-19-2002, 03:44 PM

glBindProgramARB(GL_VERTEX_PROGRAM_ARB, 0) doesn't disable vertex_programs, it just binds the default program. However, I'd use glGenProgram() to generate the program.

Korval

09-19-2002, 04:04 PM

I'm not sure (not having meticulously read the spec), but I'd guess that glBindProgramARB expects the interger value to be one returned by glGenProgramARB. If it isn't, the behavior is likely undefined (and doing nothing or crashing is perfectly acceptable in terms of being undefined).

jra101

09-19-2002, 04:25 PM

As Humus has said, it binds the default program. Heres the exact wording from the spec:

BindProgramARB(enum target, uint program);

If <program> is zero, the default program object for <target> is bound.

default program - Each program target has a default program object,
referred to using a program name of zero. The current program for each
program target is initially the default program for that target.

[This message has been edited by jra101 (edited 09-19-2002).]

solarforge

09-19-2002, 06:42 PM

Originally posted by Humus:
glBindProgramARB(GL_VERTEX_PROGRAM_ARB, 0) doesn't disable vertex_programs, it just binds the default program. However, I'd use glGenProgram() to generate the program.

According to the spec, you shouldn't have to genProgram() for the default program -- but it doesn't say anything about what the default program would be...

So my understanding is you shouldn't get _anything_ from the default program -- much the same as the default uninitialized texture for texture unit 0 (or just texture unit for non multitexture GL).

Leathal.

Humus

09-19-2002, 07:59 PM

Well, I'm not sure, but my understanding is that you should be able to use the program 0 too. But as I said, I'd use glGenProgram, as it's garantueed to work. I see no real reason to not use it.

secnuop

09-19-2002, 10:37 PM

Originally posted by Humus:
glBindProgramARB(GL_VERTEX_PROGRAM_ARB, 0) doesn't disable vertex_programs, it just binds the default program. However, I'd use glGenProgram() to generate the program.
Humus is correct. Binding program object zero doesn't disable vertex programs, it just binds the default program. If you haven't specified a program for program object zero, it's an invalid program, and you should be getting an error. I would have thought it would have been INVALID_OPERATION ("If vertex program mode is enabled and the currently bound program object does not contain a valid vertex program, the error INVALID_OPERATION will be generated by Begin, RasterPos, and any command that implicitly calls Begin (e.g., DrawArrays)."), but an error nontheless...

If you want to disable vertex programs, Disable(VERTEX_PROGRAM_ARB).

opla

09-20-2002, 01:48 AM

It seems that it's a 3 passes effect (a different VP for each pass) that causes the crash.

ATI's being really cute here. Their EXT_vertex_shader extension exposes 2 sets of constants: one for optimized maxima and one for unoptimized (ie, software) maxima. It looks like they're just listing the unoptimized maxes, and of course, not telling the user whether or not the maxes are for hardware or software.

Well, I guess it's possible those could be the legitimate numbers for the 9700, but I seriously doubt it.

Roderic (Ingenu)

09-20-2002, 10:46 AM

mmmh..

I just don't find it or ARB_fragment_program in the glext.h on SGI OpenGL Registry website http://www.opengl.org/discussion_boards/ubb/frown.gif

Where can I find an up to date glext.h ?

Asgard

09-20-2002, 11:01 AM

I just don't find it or ARB_fragment_program in the glext.h on SGI OpenGL Registry website http://www.opengl.org/discussion_boards/ubb/frown.gif

Then look again, ARB_vertex_program is available in the SGI registry (albeit not in the current revision).
ARB_fragment_program is still in specification phase and probably won't be available until some time to come.

Where can I find an up to date glext.h ?

Here for example: http://www.uni-karlsruhe.de/~uli2/

NitroGL

09-20-2002, 11:04 AM

Originally posted by Asgard:
Here for example: http://www.uni-karlsruhe.de/~uli2/

Actually, ARB_fragment_program is out now

pbrown

09-20-2002, 12:01 PM

Originally posted by opla:
It seems that it's a 3 passes effect (a different VP for each pass) that causes the crash.

btw, the glinfo2 program (delphi3d.net) is bugged, it reports 32 for each GL_MAX_PROGRAM* limit.

The ARB extension provides two sets of limits: (1) the ones you cite above which are API-level metrics and (2) a set of "native" resources that should roughly correspond to what hardware supports. These are not necessarily the same -- there may be instructions or features not supported in hardware that require multiple hardware instructions to emulate. For example, on NVIDIA hardware, you can only read one vertex attribute per instruction. So an instruction like:

MAD tmp, vertex.texcoord[0], vertex.texcoord[1], vertex.texcoord[2];

would require three instructions, two of which load the "extra" coordinates into temporaries.

What these limits are telling you is that ATI is accepting pretty much arbitrarily complex programs. It will run them in software if it can't fit them onto the hardware.

secnuop

09-20-2002, 12:07 PM

Originally posted by Korval:
ATI's being really cute here. Their EXT_vertex_shader extension exposes 2 sets of constants: one for optimized maxima and one for unoptimized (ie, software) maxima. It looks like they're just listing the unoptimized maxes, and of course, not telling the user whether or not the maxes are for hardware or software.
ARB_vertex_program exposes 2 sets of constants as well - for example, MAX_PROGRAM_INSTRUCTIONS_ARB and MAX_PROGRAM_NATIVE_INSTRUCTIONS_ARB. I don't have all of the hardware to test on, but I'd be curious to know what the "native" queries are (both for ATI and nVidia).