Multisampled Framebuffer issue

Troubleshooting
1

Hi,

I created an image with several samples and added the texture of which to the colour texture of a frame buffer with the same number of samples, in view to render several processes of a geometry which works fine.

I also need to process the depth so when I tried to add the depth buffer image texture to the frame buffer an error said that it needed to have the same number of samples as the frame buffer. Fine, I created a depth buffer image with the same number of samples and it was accepted.

I cant for the life of me find out how to write to each of the depth samples.

I use gl_fragData[n] to write to the colour samples. I have umpteen number of depth samples as forced upon me by the implementation yet no clear method to write to them.

My question is, can someone please explain how to do this.

Many Thanks
Penny

2

From my understanding, you don’t write depth, the GPU does for you, If you want to write a specific data into a depth buffer, you need to attach a depth texture into a color buffer.

@Momoko_Fan, correct me if I’m wrong

3

For depth computed in fragment shader, you can write gl_FragDepth. I never succed to used gl_FragDepth, so I often use a Color buffer (eg in a luminance16). Else I let GPU write depth as usual.

4

Thanks for your replies. I have used gl_FragDepth on single sample buffers and it works a treat.

I have considered the idea of incorporating the depth buffers into the colour buffers and since I use Depth32 they fit nicely into the 4 byte per pixel format.

Thank you Nehon for confirming to me that that is the way to go.

I didnt find any Endien helpers in my initial search through the glsl language spec. So, although I haven’t actually tested, the following code should do the trick…

int readInt(in vec4 _pixel)
 {
 int i=0;
 i|=_pixel.b<<0;
 i|=_pixel.g<<8;
 i|=_pixel.r<<16;
 i|=_pixel.a<<24;
 return i;
 }

vec4 writeInt(in int _i)
 {
 vec4 pixel;
 pixel.b=_i&0xff;
 pixel.g=(_i>>8)&0xff;
 pixel.r=(_i>>16)&0xff;
 pixel.a=(_i>>24)&0xff;
 return pixel;
 }

If there are Endien helpers or optimisations to be made I would very much appreciate the details.

Many Thanks
Penny

ps. As there isnt a way to write multisample depth buffers I wondered why the implementation would require multisample depth buffers if multisample colour buffers were provided. I note the “setTargetIndex(n)” function defined on the FrameBuffer class. I imagine the gl_FragDepth would write to the appropriate sample specified by the target index but there is no way to write to multiple depth buffers in a single pass. I haven’t tested to see if this is true as it is not the direction I am going but I have added this paragraph as a helper for someone who is.

5

I just noticed the fixed functionality computed depth can be obtained by reading gl_FragCoord.z

This is a float and I imagine it ranges from zero to one so the Endien helpers above will not be suitable.

I notice the glsl language specification only states that the texture2D(sampler,coord) returns a vec4. However, with depth buffers I have successfully used…

float depth=texture2D(m_DepthMap,coord);

and the returned float was in the rangle of zero to one. I have yet to determine whether buffers created using RGBA8 can be read, as above, as buffers created using Depth32. I am hoping that as essentially these are just ByteBuffers that there shouldn’t be an issue.

I also need to determin whether gl_FragData[n] can be written to as a float in addition to vec4…

gl_FragData[n]=vec4(1,1,1,1); // colour buffer
float f=0.5;
gl_FragData[n]=f; // depth buffer

I will update with my test results.

update…

I just tried this…

uniform sampler2DArray m_MultiSampleMaps;
varying vec2 texCoord;
void main()
 {
 for(int i=0;i<16;i+=2)
  {
  vec4 c=texture2DArray(m_MultiSampleMaps,vec3(texCoord,i));
  float d=texture2DArray(m_MultiSampleMaps,vec3(texCoord,i+1));

  gl_FragData[i]=c;
  gl_FragData[i+1]=d;

  }
 }

No errors were raised. I have yet to determine if the depth data returns sensible values but as reading the depth data provides sensible values I am hoping that writing the depth data also provides sensible values.

I hope this has been helpful.
Regards
Penny

6

Writing depth in a shader turns off early depth testing in the GPU, hence making things slower by increasing fill rate significantly. There’s rarely a reason to write depth anyway…
Sounds like a case of the XY problem.