Glsl compiler bug ?!

The following example seems not to compile correctly:

bool option = true;

if(…)
{
if(option)
{
// do something here
}
}

The comment will not be reached! If I put “if(true)” instead of “if(option)” the comment will be reached.

Sorry, I couldn’t replicate this bug in a simple shader, so the error has to do with previous stuff, but still this shouldn’t happen, right?

Has anybody experienced similar problems?

Thanks

What GLSL implementation are you using?

Originally posted by jeremyz:
What GLSL implementation are you using?

I am using a Radeon 9800XT with the latest drivers (6.14.10.6414) running Windows XP

What kind of shader is it? Vertex or fragment?

Originally posted by Korval:
What kind of shader is it? Vertex or fragment?

It’s a fragment shader.
I also noticed an extreme performance drop with this issue (when using “if(option)”), from 500 fps to 8 fps… while the shader should be doing even less calculations, not more.

It’s a fragment shader.

That’s what I guessed.

Remember that fragment programs on this hardware are quite limitted. They don’t actually have real conditional branching, so they have to fake it. Unfortunately, they can’t always fake it, so it may fall back to software, or, given the less than stable glslang implementation of ATi cards, it could crash.

Try to make your conditional statements as simple as possible. Think about the conditional capabilities of ARB_fp, and try to make if-statements that mirror that.

And you should submit a bug on it to ATi.

Originally posted by Korval:
[b] That’s what I guessed.

Try to make your conditional statements as simple as possible. Think about the conditional capabilities of ARB_fp, and try to make if-statements that mirror that.
[/b]

Thanks for the tip. Speaking of ARB_fp, can you recommend a decent documentation on ARB_fs and ARB_vs, something in the realm of the GLSL Specs?

Hi def,

Nested conditionals should work fine, although it does sound like you are exceeding the instruction count limit and are punting to SW. If you have a reproducer app that shows the incorrect results you are seeing, please send it to ‘devrel@ati.com’ and we will investigate the issue.

As mentioned above, the hardware does not natively support nested conditionals so generally it is better to try and avoid this type of construct. We end up having to evaluate each path of the conditional and then conditionally ‘cmov’ the results out based on the result of the test. If you can structure your shader more efficiently, you will get better performance by doing so.

However, you should still get correct results so please file a report with ‘devrel@ati.com’ if you are not.

Thanks.

– Dan (ATI)

[This message has been edited by dginsburg (edited 02-09-2004).]

Originally posted by dginsburg:
[b]Hi def,


However, you should still get correct results so please file a report with ‘devrel@ati.com’ if you are not.
[/b]

Thanks Dan,
I have managed to simplify the shader and I will send it to ‘devrel@ati.com’.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.