Shader failed to compile

Hi I would like to use atomic counter to increment it each time a fragment is write at x,y position, an write the color of this fragment in gl_FragData[n] where n is the current counter’s value.
So then I just have to sort all fragments and using blending in another fragment shader.
It tells me that the extension is supported

    if (GL_ARB_shader_atomic_counters)
            std::cout<<"atomic counters supported"<<std::endl;

But when I try to compile the shader source code, I get an error at this line

  atomic_uint counter;
Syntax error : failed to, unexpecting NEW identifier, expecting $end.

I know I have to use layout qualifier with binding and offset but it tells me that bindig is not a recognized layout qualifier.
So my question is how to use GL_ARB_shader_atomic_counter extension with an opengl 3.0 version ?

I declared this in fragment shader

#extension GL_ARB_shader_atomic_counters : require

but know it tells me that atomic counter require a binding point, how to specify this ?

Ok I solved my problem, it’s very cool mesa doesn’t support GLSL 4.2 functions but I can use the extensions in shaders!

                #extension GL_ARB_shader_atomic_counters : require
                #extension GL_ARB_shading_language_420pack : require
                uniform float maxLayers;
                layout( binding = 0, offset = 0) uniform atomic_uint counter;

Know I’ll be able to solve my order independent transparency problem with per pixel linked lists! (Yeah)
Depthpeeling was too slow, and weighted blended OIT didn’t worked, I didn’t have success when implementing them.

Know I’ll be able to solve my order independent transparency problem with per pixel linked lists!

Not unless you’re using image load/store. All fragment shader outputs get values regardless of whether you write to a particular output or not. If you don’t write to a particular output, then the value written will be undefined. So you can’t just write to gl_FragData[n] and expect the other fragment values to be unmodified.

If you want to do OIT in this way, you have to use image load/store (or SSBOs) as the destination where your output is written. The idea is that you will have an integer image that contains an index into an SSBO array, and you’ll store the value you fetch from the atomic counter to that image. You then write the color to that index in the SSBO.

The trick is that, when you stored that index into the image, you do that with an atomic “swap” operation, not a regular store. So you get back the integer index that used to be there. When you write your color to the SSBO array, you also write the index you retrieved from the swap operation. This effectively builds a linked list of values for each pixel.

Ok thanks for that information, I’ll try to do that.

Hum… I don’t understant very well, is that code does what you said ?

Ok I’ve understand the idea now.

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