Depth texture comparison with multisampled FBO

OpenGL OpenGL: Advanced Coding
1

Hey everyone,

I am trying to add MSAA to my multi-pass rendering algorithm, which I originally wrote with a home-rolled supersampling technique in mind.

<EDIT>

I may be barking completely up the wrong tree in the rest of this post, because even when I do not set gl_FragDepth at all, I get this odd kind of translucency: http://imagebin.org/62759

It appears that setting glDepthFunc() to anything other than GL_ALWAYS will cause it.

</EDIT>

One of the challenges I’m facing is that I need to store depth values in a way that I can access them from a shader. This is to work around the fact that OpenGL does not allow for 2 depth tests, which my algorithm (modified depth peeling) requires.

Since I am using GL_EXT_framebuffer_multisample, I cannot render directly to a texture. Instead I copy my depth values using GL_EXT_framebuffer_blit to an FBO with my depth texture bound to it. This causes the depth values from my multisampled FBO to be downsampled.

Now, when I go to render my shaded [multisampled] output on the next pass, I have to test against the depth values from the previous pass in my shader. The trouble is that those values won’t match up as they did before, because of the resolution difference. What I do to make up for that is that instead of setting my depth test to GL_EQUAL, I set it to GL_LESS, and then in my shader I do this:

float depthHere=texture2DRect(depthPeelTexture,gl_FragCoord.xy).r;

gl_FragDepth = abs(gl_FragCoord.z-depthHere);

So that, in theory, I should get the fragment displayed whose depth is the “closest match” to the depth in my depth texture. However, the result renders looking half-transparent. I’ve removed the lighting and just rendered the passing fragments pure green in this example:

http://imagebin.org/62752

My thought is that I am somehow breaking the MSAA implementation. Perhaps it uses the depth values somewhere downstream to make decisions about what to render? When I set up the render FBO without multisampling, I see the expected result.

Thanks for any ideas or tips! I am having trouble finding pertinent implementation details, and I figure maybe someone here knows it intimately…

  • Sean

P.S. This is on an NVidia GeForce 8600M.

2

It seems that this “faded” look was caused by not clearing the depth buffer at the right time. Doh!

3

You could also use http://www.opengl.org/registry/specs/ARB/texture_multisample.txt to render into depth multi sampled textures and then do a custom resolve in a shader, rather than dependong on GL_EXT_framebuffer_blit

4

Thanks for your reply ScottManDeath, it looks very useful. I am a little bit confused now, though, so I am going to revive this thread. I was just looking into how to use NV_explicit_multisample to solve the problem. NV_explicit_multisample seems to be supported in the latest ATI and NVidia drivers - is ARB_texture_multisample just a standardization of it?

Also, in both cases, I am not seeing anything in the specifications on how I would query the “current” (corresponding) sample index. For example, texelFetch() takes a “sample” parameter to identify which sample to fetch. However, since I am doing a depth comparison, I want to query “whichever sample corresponds to the one for this fragment”. Any idea on how to do that?

Many Thanks, Sean

5

Take a look at http://www.opengl.org/registry/specs/ARB/sample_shading.txt

That’ll allow you to run the shader per sample rather than per pixel and be able to retrieve the sample number.

6

Thank you very much. There are so many extensions to read with regard to this functionality!

7

Once more around: It appears that ARB_texture_multisample and ARB_sample_shading are not supported in the latest NVidia forceware drivers. Does anyone know of any alternative approaches to this problem? I’m once again looking at NV_explicit_multisample, since it is supported, but I am finding it lacking in that I have no way of finding out the current sample index to pass into samplerRenderbuffer().

One other option I’ve thought about is to supersample the depth information myself and then access it the same way I am now (with texture2DRect). The only problem with that is that I am not sure if gl_FragCoord is sample-accurate or fragment-accurate. If it’s not sample-accurate, then is there a supported extension where I can get sample positions?

Many thanks, Sean

8

I’ve got ARB_texture_multisample here in the NVidia 190.18.04 drivers (Linux). See this page for beta drivers:

Try 190.57 (MSWin) drivers on the same page.

Missing ARB_sample_shading though…

9

It appears that ARB_texture_multisample and ARB_sample_shading are not supported in the latest NVidia forceware drivers.

ARB_texture_multisample is part of OpenGL 3.2 core. As such, there is no need to advertise the extension, since it is part of the core.

10

Right, ARB_texture_multisample is part of 3.2 core.
However, IIRC ARB_sample_shading is not part of 3.2. Last I saw, it was written as an extension to 3.1.

Supposedly in 3.2 glGet(GL_EXTENSIONS) is deprecated/removed from forward compatible contexts (apparently I missed that part when I skimmed the spec, but I saw others mention it on these forums).

So, how will I know when/if ARB_sample_shading is supported in a 3.2 app?

11

However, IIRC ARB_sample_shading is not part of 3.2. Last I saw, it was written as an extension to 3.1.

Of course not.

The reason core extensions are core extensions is because they are all supported by a certain range of hardware. That is, what might be called Direct3D 10-capable hardware. The only things that go into GL 3.x core (thus far) are features for that minimum level of hardware. Everything else requires more hardware than this basic level.

This means that every piece of hardware that can implement GL 3.0 can also implement GL 3.2. So point-releases of OpenGL are exposing more of the hardware, or improving the API.

Therefore, if the implementation does not support ARB_sample_shading, then either the driver developers haven’t finished implementing it, or the hardware doesn’t have that functionality.

I’m guessing that this is more of a D3D 10.1-type feature, one that only ATI hardware supports.

Supposedly in 3.2 glGet(GL_EXTENSIONS) is deprecated/removed from forward compatible contexts

Yes, it is. Use glGetStringi(GL_EXTENSIONS, i) instead. Query the number of extensions with GL_NUM_EXTENSIONS.

12

I’m pretty confused now. If I try to use ARB_texture_multisample in a shader by means of

#extension ARB_texture_multisample : enable

I get a warning saying that the extension is unsupported. If I try to use sampler2DMS or any of the other features of ARB_texture_multisample I get errors.

Given that gl_FragCoord seems to only by fragment accurate, I don’t see any way to get the sample index to feed to GL_NV_explicit_multisample. The only way I can see to get this to work is to write a custom resolve in my fragment shader. Does that have any hope of working?

I am using Forceware 6.14.11.9062 (8-17-2009). Here are the results of glGetString(). “GPU Caps Viewer” corroborates this data.

9/11/2009 at 6:09:54 PM: OpenGL Implementation Information:
Vendor: NVIDIA Corporation
Renderer: GeForce 8600M GT/PCI/SSE2
Version: 3.1.0
Extensions:
GL_ARB_color_buffer_float GL_ARB_compatibility GL_ARB_copy_buffer GL_ARB_depth_buffer_float GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_draw_instanced GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_framebuffer_object GL_ARB_geometry_shader4 GL_ARB_imaging GL_ARB_map_buffer_range GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_texture_border_clamp GL_ARB_texture_buffer_object GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_transpose_matrix GL_ARB_vertex_array_object GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_ATI_draw_buffers GL_ATI_texture_float GL_ATI_texture_mirror_once GL_S3_s3tc GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_Cg_shader GL_EXT_bindable_uniform GL_EXT_depth_bounds_test GL_EXT_direct_state_access GL_EXT_draw_buffers2 GL_EXT_draw_instanced GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXTX_framebuffer_mixed_formats GL_EXT_framebuffer_sRGB GL_EXT_geometry_shader4 GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_packed_pixels GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_shader_objects GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_array GL_EXT_texture_buffer_object GL_EXT_texture_compression_latc GL_EXT_texture_compression_rgtc GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_integer GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_sRGB GL_EXT_texture_swizzle GL_EXT_texture_shared_exponent GL_EXT_timer_query GL_EXT_vertex_array GL_EXT_vertex_array_bgra GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square GL_NV_copy_depth_to_color GL_NV_copy_image GL_NV_depth_buffer_float GL_NV_conditional_render GL_NV_depth_clamp GL_NV_explicit_multisample GL_NV_fence GL_NV_float_buffer GL_NV_fog_distance GL_NV_fragment_program GL_NV_fragment_program_option GL_NV_fragment_program2 GL_NV_framebuffer_multisample_coverage GL_NV_geometry_shader4 GL_NV_gpu_program4 GL_NV_half_float GL_NV_light_max_exponent GL_NV_multisample_coverage GL_NV_multisample_filter_hint GL_NV_occlusion_query GL_NV_packed_depth_stencil GL_NV_parameter_buffer_object GL_NV_parameter_buffer_object2 GL_NV_pixel_data_range GL_NV_point_sprite GL_NV_primitive_restart GL_NV_register_combiners GL_NV_register_combiners2 GL_NV_texgen_reflection GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 GL_NV_texture_expand_normal GL_NV_texture_rectangle GL_NV_texture_shader GL_NV_texture_shader2 GL_NV_texture_shader3 GL_NV_transform_feedback GL_NV_vertex_array_range GL_NV_vertex_array_range2 GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_NV_vertex_program2_option GL_NV_vertex_program3 GL_NVX_conditional_render GL_NV_vertex_buffer_unified_memory GL_NV_shader_buffer_load GL_SGIS_generate_mipmap GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow GL_SUN_slice_accum GL_WIN_swap_hint WGL_EXT_swap_control

13

Version: 3.1.0

Looks like your drivers don’t support 3.2 or ARB_texture_multisample.

14

Ah. Thanks for the clarification Alfonse. That helps a lot.