Anyway to retrive value from fragment shader back to .cpp file?

Started by
8 comments, last by cgrant 8 years, 5 months ago

I am learning Opengl and is on spot light now. I got this code

vec3 lightDir = normalize(light.position - FragPos);

// Check if lighting is inside the spotlight cone
float theta = dot(lightDir, normalize(-light.direction));

if(theta > light.cutOff)
{
// Do some spotlight code here
}

But what if for example you want to see whats going on inside the fragment shader? Say I want to get the value of

theta and light.cutoff

just to be sure I am right? How can i get their value back to my .cpp file? because right now the only thing I know is to send a value to fragmet shader but not get the value back from the fragment shader. I want to get the value before the fragment shader output the colors. Just for debugging purposes and also to better understand what is going on.

Advertisement
That's why you would use a GPU debugger. I don't know many OpenGL debuggers, but I think NSight might be able to help you if you have a Nvidia card.

While there are GPU debuggers out there (RenderDoc, Visual Studio, apitrace, NSight, GPU PerfStudio, Intel GPA), they're often nowhere near close to the state of CPU debugging (specially OpenGL).

What we often do is debug by colour. Change the shader, output the value to the screen, and either intuitively accept it (e.g. it should look yellow -> looks yellow, good enough for me) or use those GPU debuggers to retrieve the value of the texture from an FLOAT32 RTT.

Debugging by colour is a necessary skill. Learn to "read" XYZ from red, green and blue.


Debugging by colour is a necessary skill. Learn to "read" XYZ from red, green and blue.

QFT.

When one of my shaders produces incorrect output, I usually start with each input, and render them to the output colour, one-by-one. Then each intermediate step in the calculation. Visually inspect each one to make sure the colour you are seeing makes sense.

This is pretty much the only portable way to debug shaders.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

While there are GPU debuggers out there (RenderDoc, Visual Studio, apitrace, NSight, GPU PerfStudio, Intel GPA), they're often nowhere near close to the state of CPU debugging (specially OpenGL).

While that's true most of the time, you can usually debug shaders pretty easily.

While there are GPU debuggers out there (RenderDoc, Visual Studio, apitrace, NSight, GPU PerfStudio, Intel GPA), they're often nowhere near close to the state of CPU debugging (specially OpenGL).

What we often do is debug by colour. Change the shader, output the value to the screen, and either intuitively accept it (e.g. it should look yellow -> looks yellow, good enough for me) or use those GPU debuggers to retrieve the value of the texture from an FLOAT32 RTT.

Debugging by colour is a necessary skill. Learn to "read" XYZ from red, green and blue.

Do you also do this say for example when your doing complex calculations on your fragment shader? I havent done any advance yet but ill give an example like for example you want to see the if you are getting the right angle? or say something is wrong and you want to see the calculation to see what is happening and why is it giving the wrong value? In my code above its the same. I want to see their value to see why is that..

That's why you would use a GPU debugger. I don't know many OpenGL debuggers, but I think NSight might be able to help you if you have a Nvidia card.

Sad thing I have an AMD build.

While there are GPU debuggers out there (RenderDoc, Visual Studio, apitrace, NSight, GPU PerfStudio, Intel GPA), they're often nowhere near close to the state of CPU debugging (specially OpenGL).

While that's true most of the time, you can usually debug shaders pretty easily.

What do you do to debug them? is it the same as other have stated?

While there are GPU debuggers out there (RenderDoc, Visual Studio, apitrace, NSight, GPU PerfStudio, Intel GPA), they're often nowhere near close to the state of CPU debugging (specially OpenGL).

While that's true most of the time, you can usually debug shaders pretty easily.

What do you do to debug them? is it the same as other have stated?
I use Visual Studio to debug HLSL (DirectX shaders) but I don't know if it supports GLSL. In order to debug a vertex shader I need to select a specific vertex and to debug a pixel/fragment shader I select a pixel in the final render. This is very useful to debug lighting systems.

It seems that there ARE some GLSL debuggers out there, just Google them. But if you're not able to find anything, then go with color debugging.

AMD CodeXL is a very capable debugger, however, it does not give you the ability to step through your shader code. Like others have mentioned you can debug by color, or if the values are really that important to validate, then setup up MRT, and then write the values you are interested in out to the render target and do a CPU readback. Note: I did not mention anything in regards to optimization, but if this is just for debugging, then this may help you out too.

This topic is closed to new replies.

Advertisement