Jump to content

  • Log In with Google      Sign In   
  • Create Account


GLSL Issue when using pow()


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 AndyEsser   GDNet+   -  Reputation: 371

Like
0Likes
Like

Posted 22 January 2014 - 01:32 PM

Hello,

 

I'm currently implementing a shader for doing some Directional Lights. I'm following the tutorial at Lighthouse 3d (http://www.lighthouse3d.com/tutorials/glsl-core-tutorial/directional-lights-per-pixel/)

 

The issue I'm having is in the following few lines:

vec3 h  = normalize(l_dir + e); 
float intSpec  = max(dot(h, n), 0.0);
float specularPower = pow(intSpec, shininess);

If I leave the "float specularPower" line in - then the shader no longer 'works'.... I say 'works' in quotations, because I get no output or errors from the Shader Log, however, now the uniform locations for my all return -1 and I can't set my texture locations, etc.

 

If I remove it, the rest of the shader works as expected (but producing incorrect results as a result of missing the Specular Power).

 

What's even more curious, is that if I have the nVidia Nsight Debugger attached, then I get output on screen and it appears to 'work', but if I just use VS2012 in Debug mode I get nothing displayed on screen, and the following error message:

First-chance exception at 0x000000005EB066E6 (nvoglv64.dll) in application.exe: 0xC0000005: Access violation reading location 0x0000000000000008.
First-chance exception at 0x000000005EB066E6 (nvoglv64.dll) in application.exe: 0xC0000005: Access violation reading location 0x0000000000000008.

This behaviour has been witnessed on both a GTX 480 and a GTX 560 - on a PC running Windows 8 64-bit.

 

Any suggestions as to what I might be doing wrong are very welcome.

 

Cheers.

 



Sponsor:

#2 richardurich   Members   -  Reputation: 1187

Like
0Likes
Like

Posted 22 January 2014 - 08:24 PM

You only mentioned the shader log. Did you also check the linker output (glGetProgramInfoLog) and glGetError?

 

If no errors occurred, glGetUniformLocation returning -1 is usually because your shader let the variable be optimized out of existence. This is often caused by a simple typo or forgetting to actually output the results or some similar error, so it's hard to guess without seeing code.

 

If you're using uniform blocks like the tutorial you linked, you might try using non-block uniforms while debugging this so each component is fully independent and generating its own errors from its own code.



#3 AndyEsser   GDNet+   -  Reputation: 371

Like
0Likes
Like

Posted 23 January 2014 - 06:24 AM

I haven't checked glGetProgramInfoLog() - I'll do that this evening. glGetError() returns no errors.

 

With regards to the -1, I know that typically means the value has been optimised out, but since I'm not even using the value return from pow() in my test code, I don't see how it could be affecting any of the other uniforms which work normally with that line commented out. 

 

I'm not using uniform blocks, just standard glUniform*() functions.

 

I don't have access to the shader code at the moment, I'll try and get a copy onto Pastebin this evening and post the link.


Edited by AndyEsser, 23 January 2014 - 06:26 AM.


#4 tanzanite7   Members   -  Reputation: 1124

Like
0Likes
Like

Posted 23 January 2014 - 06:48 AM

What's even more curious, is that if I have the nVidia Nsight Debugger attached, then I get output on screen and it appears to 'work', but if I just use VS2012 in Debug mode I get nothing displayed on screen, and the following error message:

First-chance exception at 0x000000005EB066E6 (nvoglv64.dll) in application.exe: 0xC0000005: Access violation reading location 0x0000000000000008.
First-chance exception at 0x000000005EB066E6 (nvoglv64.dll) in application.exe: 0xC0000005: Access violation reading location 0x0000000000000008.

Could be bad source string (Specifically, incorrect length - causing semi-predictable garbage to be included).
Or some other kind of memory corruption, uninitialized values, etc (0x8 sounds suspiciously like "null + pointer aligned member-offset") - where does the stack trace point?

(sniggle: Seeing the actual source would generally be nice as "If I leave the 'float specularPower' line in" is a bit too ambiguous in regard to "-1" uniform locations ... probably irrelevant in this case tho)

#5 AndyEsser   GDNet+   -  Reputation: 371

Like
0Likes
Like

Posted 23 January 2014 - 06:50 AM

Hi Tanzanite,

 

I'll try and strip the shader down to the bare minimum reproducable code and paste it this evening.

 

With regards to the stack trace, I can't access it. The output above is pumped into the console log in VS, and the actual exception seems to be swallowed by the nvoglv64.dll so I can't actually see where it's being triggered.

 

I'll go through and check that all memory is correctly initialised as well and see if I can get some more information about the exception.

 

Many thanks



#6 dpadam450   Members   -  Reputation: 830

Like
0Likes
Like

Posted 23 January 2014 - 10:45 AM

I've had issues though I think it was only with uniforms in the past with older cards. If I was doing something with a variable that never got used: for instance:
intSpec would now be completely useless because you don't do anything with it after you comment out that next line of code.

 

Try keeping the broken shader and just add  " intSpec*.001"  to your gl_FragColor and see if it works.

 

Or if shininess variable is a uniform as I said, you don't actually use it so your shader might just blow up, especially if you call glGetUniformLocation on a uniform that gets compiled out of the shader since you arent using it.


Edited by dpadam450, 23 January 2014 - 10:46 AM.


#7 tanzanite7   Members   -  Reputation: 1124

Like
0Likes
Like

Posted 24 January 2014 - 04:03 AM

OT: the persistently broken embarrassment known as gamedev forum software - crapped its pants again ... i'll be brief.

 

With regards to the stack trace, I can't access it. The output above is pumped into the console log in VS, and the actual exception seems to be swallowed by the nvoglv64.dll so I can't actually see where it's being triggered.

 

The fact that anything shows up in the console log means that the crash happened in user-land in your context where you have authority (it is your stack after all) - if you did not get a debug break then that means you have told your debugger not to do that (you are expected to enable it on your own if and when you need it - which is sensible and preferred behavior in case anyone wonders). If debugger is not told to intercept then the default handler at the bottom of SEH will handle it - part of which is to emit the message into the log (pretty sure only the debug lib of it does that). Anyway, this should help:

 

http://msdn.microsoft.com/en-us/library/d14azbfh.aspx

 

... make sure that at least "Access violation" gets caught - or better yet, everything.


Edited by tanzanite7, 24 January 2014 - 04:12 AM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS