Large fragment program

[Clint Weisbrod]

Hi All,

Just wondering if anyone has run into issues involving native limits for GLSL fragment programs. I've written a fragment shader which uses gl_FragCoord to render using a stereographic projection. Just to avoid any confusion, I'm referring to the projection described at http://mathworld.wolfram.com/StereographicProjection.html and not two side-by-side images that you cross your eyes at. :-)

Anyway, the fragment program uses a fair amount of math and runs fine on a number of more capable cards; NVidia 6800 Ultra and ATI X800 XT. Both of these cards have significant capabilities with respect to items like GL_MAX_PROGRAM_INSTRUCTION_ARB.

I'm now trying to get the shader to run on a lesser card that still supports GLSL. The shader doesn't appear to do anything unless I start removing code to make the program smaller.

Is there no way of determining things like GL_PROGRAM_INSTRUCTIONS_ARB and GL_PROGRAM_ALU_INSTRUCTIONS_ARB as I used to be able to do using ARB fragment programs?

It would be ideal if I could make a call like:

GLint isUnderNativeLimits;
glGetProgramivARB(GL_FRAGMENT_PROGRAM_ARB, GL_PROGRAM_UNDER_NATIVE_LIMITS_ARB, &isUnderNativeLimits);

Without such information, I have no way of knowing for certain if my shader will run on any particular GPU short of testing it on all of them. This would seem like a severe deficiency in the GLSL language specification.

I'm sure I must be missing something.

Thanks for any help.

Clint Weisbrod
Imaginova Canada, Ltd.
Starry Night Software.

[Korval]

Is there no way of determining things like GL_PROGRAM_INSTRUCTIONS_ARB and GL_PROGRAM_ALU_INSTRUCTIONS_ARB as I used to be able to do using ARB fragment programs?What would that mean in the context of a high-level language? You don't know how many instructions a particular line corresponds to, so you can't make adiquate use of this information.


Without such information, I have no way of knowing for certain if my shader will run on any particular GPU short of testing it on all of them.For a shader that can't run on the hardware, the driver ought to fail to link the shader. If it doesn't, then this is probably a bug or you have CPU emulation turned on. Check your errors after linking the shader to make sure that it did something.

[Humus]

Originally posted by Korval:
For a shader that can't run on the hardware, the driver ought to fail to link the shader. If it doesn't, then this is probably a bug or you have CPU emulation turned on. Check your errors after linking the shader to make sure that it did something.Actually, the driver can't fail to link a valid shader. Instead it will run it in software if it can't be run in hardware, as per standard OpenGL philosophy. On ATI cards at least you'll find information whether it will run in hardware or software in the infolog, but personally I think it would be useful to have an official way to get this information.

[Brolingstanz]

perhaps korval meant to imply that that is what the driver ought to do, as opposed to how it's spec'd, implying further that the spec could be better in this area. i would agree.


I think it would be useful to have an official way to get this information.i couldn't agree more, not without hurting myself. the "try it and see" approach is tedious at best.

[Fitz]

One thing you might try is removing any commented out code and as I've found that even though its commented out GLSL still seems to count it.

[Korval]

Actually, the driver can't fail to link a valid shader.No, the driver is well within its rights to fail to link any shader if it doesn't fulfill implementation-dependent requirements.

A driver is also within its rights to run such a shader in software. However, I would also consider such a driver (particularly for fragment shaders) to be... annoying.

[Humus]

A driver can and should fail a shader that doesn't fall within queriable limits, such as number of varyings, vertex attributes etc. But the driver can't fail to link a shader that's within all those limits, yet goes above a non-queriable hardware limit, such as the instruction count. In that case, running in software is the only conformant option.

[V-man]

But instruction count is not queryable, so there is no way to know how long a shader can be and run on the hw.
That's what the OP is interested in.
We would need a way to query the max instruction count and also how many intructions a particular shader compiles too.
Other things like nesting level and whatever should be queyable too.
That's what I like about shader targets like in D3D and nVidia's extensions.

Neverthless, you still need to benchmark on every hw to make sure the program runs fast enough to be acceptable.