PDA

View Full Version : Vertex shaders acting strangely...



Joel
07-25-2002, 07:34 AM
Hi,

i've a piece of code that isn't working and i don't know why...
This part of my vertex shader is just clamping a color (no matter it is a color could be anything else....) between 0 and 1 (cause I can get negative value when N.L is negative, don't ask why http://www.opengl.org/discussion_boards/ubb/smile.gif)



float zeroValues[4] = { 0.f, 0.f, 0.f, 1.0f};
GLuint intensity;
GLuint temp;
GLuint temp2;
GLuint zero;
[snip]
intensity = glGenSymbolsEXT( GL_VECTOR_EXT, GL_LOCAL_EXT, GL_FULL_RANGE_EXT, 1);
temp = glGenSymbolsEXT( GL_VECTOR_EXT, GL_LOCAL_EXT, GL_FULL_RANGE_EXT, 1);
temp2 = glGenSymbolsEXT( GL_VECTOR_EXT, GL_LOCAL_EXT, GL_FULL_RANGE_EXT, 1);

zero=glGenSymbolsEXT( GL_VECTOR_EXT, GL_LOCAL_CONSTANT_EXT, GL_FULL_RANGE_EXT, 1);
glSetLocalConstantEXT( zero, GL_FLOAT, &zeroValues);
[snip]

glSwizzleEXT(temp, intensity, GL_ONE_EXT, GL_ONE_EXT, GL_ONE_EXT, GL_ONE_EXT);
glShaderOp3EXT( GL_OP_CLAMP_EXT, temp2, temp2, zero, temp);
glShaderOp2EXT( GL_OP_ADD_EXT, intensity, intensity, temp2);
[snip]


If in glSwizzleEXT(temp, intensity, GL_ONE_EXT, GL_ONE_EXT, GL_ONE_EXT, GL_ONE_EXT); i put anything but intensity the code is working.
With intensity as second parameter the effect i get is the same as if i was clamping in [0, 0] interval.

I don't seek a solution, as I said it is working if i use another variable. I just want somebody to explain why it doesn't work with intensity.
Or there is something i totally misunderstood how vertex shaders are working or there is some kind of bug (quite irritating, spent some time before trying another variable).

I do like the swizzling trick where you can make a vector [1,1,1,1] without declaring this vector as you must with NV's vertex programs. (I know i could have done the same with my zero variable but i didn't... for now http://www.opengl.org/discussion_boards/ubb/smile.gif)

Could someone explain me why this doesn't work ?

Joel.

Dan82181
07-25-2002, 09:51 AM
Couple things come to mind...

1 - Have you enabled vertex shaders and bound the vertex shader name before you try to generate a vector name?

2 - Does "intensity" get used previously somewhere in that [snip]?

3 - If "intensity" doesn't, try creating another vector name that doesn't get used in the [snip] either and see if you get the same results.

(I believe the swizzle and write mask commands might not like having undefined data in the input vector parameter)

Dan

vincoof
07-25-2002, 09:55 AM
Probably in your [snip] section you set something wrong for intensity, so that glSwizzleEXT generates an error (which discards operations).

Apart from that, I can't see what's wrong in changing the in parameter since it is not taken in account because all X, Y, Z and W elements are overriden by GL_ONE_EXT.

vincoof
07-25-2002, 09:59 AM
Dan82181: I think the intensity does not have an undefined data because Joel calls :


glShaderOp2EXT( GL_OP_ADD_EXT, intensity, intensity, temp2);
To my mind he wouldn't call that addition if intensity was not initialized. Also, I may be wrong and Joel could have forgot the line that initializes intensity.

Dan82181
07-25-2002, 10:14 AM
Then again, he wouldn't be trying to generate locals without first calling glBeginVertexShaderEXT() either.

From the spec...


If this data is not set before being used the values used are undetermined and may result in unpredictable values being used in the calculation.


True, it's not actually using any of the parts of the vector, I'm just assuming that it could be complaining about it having undefined values. Yeah, I'd hope he would have something in that register before he goes to add to it as well. Try calling a glGetError() after that swizzle and see if it generates a GL_INVALID_OPERATION.

Dan

vincoof
07-25-2002, 10:23 AM
I don't think it will generate an error, because the two errors that glSwizzleEXT generate are :

ILLEGAL_OPERATION is generated if the datatype of the <res> or <in>
parameters to WriteMaskEXT or SwizzleEXT is not VECTOR_EXT.

ILLEGAL_OPERATION is generated if if the <res> parameter of ShaderOPEXT,
SwizzleEXT, or WriteMaskEXT does is not a local or output storage type.
and none of those cases seem to apply to Joel's piece of code.

Anyway, I agree that unpredicatble results may appear when intensity's data is not initialized, even if GL_ONE_EXT makes intensity's data useless.

Joel
07-25-2002, 11:31 AM
Thank you all for your answers.


I can't tell for sure what i'm doing with intensity cause i don't have my source (yea back home after a looooong day http://www.opengl.org/discussion_boards/ubb/smile.gif).
I guess you must be right cause i don't think i've writen to intensity before this one.
It has been a cut past from the version that handled only one light and it's quite possible I didn't initiliaze it now.

Can't see other explanations (and this one didn't come into my mind...)

I'll tell you tomorrow if that's the reason.

Thanks.
Joel.

Joel
07-25-2002, 01:51 PM
I've just re-read the code i've post and i remember that i initiliaze intensity with a [0,0,0,1] vector that i got either from my variable zero or swizzeling.

More info tomorrow.
Good night for those who are concerned http://www.opengl.org/discussion_boards/ubb/smile.gif

Joel.

vincoof
07-25-2002, 10:46 PM
lol.

and i remember that i initiliaze intensity with a [0,0,0,1] vector that i got either from my variable zero or swizzeling.
If you initialize intensity with swizzle, for instance glSwizzleEXT(intensity, intensity, GL_ZERO_EXT, GL_ZERO_EXT, GL_ZERO_EXT, GL_ONE_EXT), it may not help that much ! http://www.opengl.org/discussion_boards/ubb/smile.gif

Joel
07-25-2002, 11:44 PM
Hi

here are some news to make your brain boil http://www.opengl.org/discussion_boards/ubb/smile.gif
I've tested with a variable that doesn't get initialized by some values. And it works.
I've initiliazed my variable intensity with the variable zero



// initialize intensity to zero
glShaderOp1EXT( GL_OP_MOV_EXT, intensity, zero);

And yes, zero is initialized(think i've showed how in my first post).
So AFAIK this a bug from ATI's drivers.
I can' explain me how this is possible but it happens...
This week-end i'll try to make a simple app that i can send to whoever wants, but it will be hard to me to do it cause i don't have a radeon at home (guess why http://www.opengl.org/discussion_boards/ubb/wink.gif...)
I also think that this bug will be hard to reproduce cause it should be really dependent of all the context and not just my vertex shader code... will see.

If anyone as an idea, even one that can seem funny, just tell me.

Joel.

vincoof
07-25-2002, 11:53 PM
Have you tried on another card, or with other drivers ?
If it works with a different configuration, that probably means it's a bug that your driver/card combo encounter.
Also, have you downloaded the latest drivers ? (be careful, unlike nVidia, ATI have different drivers for different cards).

Joel
07-26-2002, 12:10 AM
Originally posted by vincoof:
Have you tried on another card, or with other drivers ?
If it works with a different configuration, that probably means it's a bug that your driver/card combo encounter.
Also, have you downloaded the latest drivers ? (be careful, unlike nVidia, ATI have different drivers for different cards).

I haven't tried with another card cause we aren't that rich http://www.opengl.org/discussion_boards/ubb/wink.gif. I've got the only Radeon 8500 in the firm.
That's why i've suggested that i should do another app that i could send (this one is confidential and is _huge_).

The drivers are 6094 that i downloaded at most 2 weeks ago, and these are the ones that you can still find in ATI's site.

I'll just try to make the bug happens in a simple app and hope that an ATI guy will be interested in it.
Anyway that's no more problem for me cause I know how to solve it. Was just thinking of the next poor guy that will get the same problem.

To be complete my OS is Windows 2000.

Joel.

Joel
07-29-2002, 11:54 PM
Originally posted by Joel:

I'll just try to make the bug happens in a simple app and hope that an ATI guy will be interested in it.


Hi,

you thought that i forgot, didn't you ?
I just had a CRC error while getting my app back at work http://www.opengl.org/discussion_boards/ubb/wink.gif
Now everythig is all right.
I've got a very simple app that shows the problem. All the code, libs, exec... are 97 ko.

I'm sorry i don't have a web site to put this example on. But i will send this app to anyone who is interested in it. Especially if chrisATI or anyone else i forgot from ATI could answer me i'll be grateful.

Anyone who wants to test the app (who have a radeon 8500 of course http://www.opengl.org/discussion_boards/ubb/wink.gif) is also welcome.

Hope it will help someone.

Joel.

vincoof
08-02-2002, 01:51 AM
I'm sorry, but I've read your piece of code again, and I read ATI's extension specifications again and again and I still can't get where the hell you're making something bad.
So I'm thinking of a bug from ATI's drivers :\

Joel
08-02-2002, 04:34 AM
Originally posted by vincoof:
I'm sorry, but I've read your piece of code again, and I read ATI's extension specifications again and again and I still can't get where the hell you're making something bad.
So I'm thinking of a bug from ATI's drivers :\

So do I.
I will send the simple app i've done to anyone who wants.
I should try to make a web site this night on which i could put my app for who wants to test it. Hopefully we'll get ARB_vertex_program "soon".
Is there a way to report bugs to ATI ? Their site is a little messy and i didn't search too long http://www.opengl.org/discussion_boards/ubb/wink.gif.

PH
08-02-2002, 04:49 AM
I'll look at it if you want.

PH
08-02-2002, 05:24 AM
I found something that seems a bit strange: with the line,

glShaderOp2EXT( GL_OP_MUL_EXT, temp2, temp2, temp);

you are multiplying temp2 ( that contains N.L ) with a temporary that you didn't initialize ( temp ).

With all three swizzle lines I get a black square.

Also, I would suggest using glGenVertexShadersEXT(..) rather than binding to a specific value ( maybe you only did this for the test but just in case ).

I don't think this is a driver bug.

Oh, and I'm using the 6118 official drivers ( released yesterday ).

PH
08-02-2002, 05:37 AM
After running it a few times, I suddenly get a blue square for the first two swizzle lines and black for the other. Hmmm...

PH
08-02-2002, 05:41 AM
Initializing 'temp' with zero will give a black square. Local temporaries have undefined values, so using them in operations will likely give pretty random results.

PH
08-02-2002, 05:50 AM
Now I don't get a blue square anymore ( removing the line that I used to initialize temp with ). The problem is with the line I posted above.

Result = clamp( ( N.L ) * <random>, 0, 1 );

Joel
08-02-2002, 05:53 AM
Originally posted by PH:
I found something that seems a bit strange: with the line,

glShaderOp2EXT( GL_OP_MUL_EXT, temp2, temp2, temp);

you are multiplying temp2 ( that contains N.L ) with a temporary that you didn't initialize ( temp ).

Oh, and I'm using the 6118 official drivers ( released yesterday ).

My fault...
in my original code temp was initialized...
you can remove this line.
The thing is that when you use intensity has the 2nd variable you get a black quad but get a blue one with all others (which is what you can expect).
Try again removing the line



glShaderOp2EXT( GL_OP_MUL_EXT, temp2, temp2, temp);


As you can see i've even tested with an unitiliazed variable (called nonInitiliazed http://www.opengl.org/discussion_boards/ubb/wink.gif) and it works this way...


But for me the result is not random. I've always the same effects each time i run.
I'll give a try to the new drivers has soon as i get back the radeon (have lend it for another project http://www.opengl.org/discussion_boards/ubb/wink.gif)

Joel.

PH
08-02-2002, 05:58 AM
Ok, tried that. I get a black quad will all 3 lines.

Now the result should be,

Result = clamp( N.L, 0, 1 ) + intensity( = 0 );

Where does the color blue come from ?

Joel
08-02-2002, 06:16 AM
Originally posted by PH:
Ok, tried that. I get a black quad will all 3 lines.

Now the result should be,

Result = clamp( N.L, 0, 1 ) + intensity( = 0 );

Where does the color blue come from ?

In fact that is N.L that is encoded as a color.



glShaderOp1EXT( GL_OP_MOV_EXT, GL_OUTPUT_COLOR0_EXT, intensity);

in my original code i handle multiple lights that's why you have got intensity = intensity + clamp(N.L, 0, 1)
I didn't initialized the light position has it is supposed to have a default value, but maybe i should have...

Too bad i have lost my radeon the day i get replies...
As we don't get the same results i guess this must be an issue of drivers... (so that was finally a bug that has been fixed)
The thing that trouble me is that you should get a blue quad and not a black one. May be by initalizing the light position this will have the expected results.

Thanks.

Joel.

PH
08-02-2002, 06:22 AM
Well, intensity contains 'zero' and you are clamping N.L to be between 0 and 1. The result of N.L is a scalar and adding this to 0 gives N.L which is then replicated to all channels in GL_OUTPUT_COLOR0_EXT. The result is a shade of grey ( or is that gray ? ).

With the code you mailed me, there should never be a blue quad.

Joel
08-02-2002, 06:38 AM
Originally posted by PH:
Well, intensity contains 'zero' and you are clamping N.L to be between 0 and 1. The result of N.L is a scalar and adding this to 0 gives N.L which is then replicated to all channels in GL_OUTPUT_COLOR0_EXT. The result is a shade of grey ( or is that gray ? ).

With the code you mailed me, there should never be a blue quad.

You're right. With the code i've sent there should not have a blue quad (with my original you could, but it is a lot more trickier).
Seems the blue came from the temp i didn't initialized. But as it reproduced the problem i had (with one variable i get a result and with another one i don't get the same even if the variable's values aren't used) i didn't even though of that http://www.opengl.org/discussion_boards/ubb/wink.gif.

I'll make more tests when i get my radeon back. I've coded the part i've sent without having a radeon. I just tested it on the radeon and as i've seen that i got the same behaviour i haven't been any deeper...
The thing is that my original code _is_ well initialized and presents the problem.

Hold on for now and i'll make more tests as soon as i get my radeon back (and tell you my results).

Thanks for your help.

Joel.

[edit] typos and spelling, i'm getting too tired to write correct english http://www.opengl.org/discussion_boards/ubb/wink.gif

[This message has been edited by Joel (edited 08-02-2002).]

Joel
08-19-2002, 01:51 AM
Ok,

so i finally get my Radeon back after a fight to death... http://www.opengl.org/discussion_boards/ubb/wink.gif

I've intialized all the things properly in the app now and i still have the strange bug.
I've tried with my old drivers and the 6118 ones, same result...

PH if you're still interested i can send you this (clean) example.
I'd like an ATI guy to give me any answers too... I'm quite sure this is a bug in the drivers.

Thanks so far.
Joel.

vincoof
08-19-2002, 02:00 AM
6118 are the latest drivers from the beginning of August ?
I haven't heard that they meant to fix bugs in vertex shaders, so I'm not surprised you didn't get any better result. Well, as long as we consider it is a bug from the drivers...

PH
08-19-2002, 02:53 AM
Originally posted by Joel:
..PH if you're still interested i can send you this (clean) example...


Sure, looking forward to it. I've done a lot of work with EXT_vertex_shader recently, so everything is still fresh in my mind http://www.opengl.org/discussion_boards/ubb/smile.gif.

PH
08-19-2002, 10:26 AM
I had a look at the new code and did a few tests. It looks like a driver bug, so you should probably notify ATI about it.

A few observations,

(1) If you don't use 'intensity' after the swizzle command, everything works as expected.

(2) If you add,

glShaderOp1EXT( GL_OP_MOV_EXT, intensity, zero);

after the clamp instruction, things work as expected. The strange thing is that if you add the line immediately after the swizzling instruction ( just before the clamp ), things don't work. So it can't simply be a problem with the swizzling instruction. It looks more like the driver is doing some incorrect code optimizations.

(3) If you remove the clamp instruction, everything works as expected.

(4) Changing the clamp instruction to a combination of MIN/MAX doesn't work either ( unless you re-initialize 'intensity' right after, like it 2. ).

Joel
08-19-2002, 12:13 PM
Originally posted by PH:
I had a look at the new code and did a few tests. It looks like a driver bug, so you should probably notify ATI about it.

I would like but didn't find anywhere on their site how to report it...
I hoped one ATI guy will see this post http://www.opengl.org/discussion_boards/ubb/frown.gif



It looks more like the driver is doing some incorrect code optimizations.
That's what i thought too. So i think it should be usefull that ATI is notified of this (the reason of this thread as i've found a way to go over the problem)

Oh and by the way i switched back to the elder drivers. The newest make my GUI all screwed (i use QT for that). Does anybody has the same problem ?

PH
08-19-2002, 12:18 PM
You can use this driver feedback form ( and provide a download link to the code ),
http://apps.ati.com/driverfeedback/index.asp

or send an e-mail to devrel 'at' ati.com.

vincoof
08-20-2002, 12:51 AM
(nm swwy)

[This message has been edited by vincoof (edited 08-21-2002).]