Experimental depth read support

[PeterHiber]

This PR contains experimental support for reading the depth buffer from shaders, see: #576

What works:

• Reading depth buffer in D3D11
• Reading depth buffer in WebGL 2

What doesn't work:

• Metal
• Issues reading depth buffer in WebGL 1 with depth_texture extension, not sure why
• Not super well-tested with depth_stencil formats, likely broken in some variations.

At this point we are a bit stuck mainly at the Metal implementation. In our testing environment we don't get any errors of any kind when attempting to read the depth buffer, just a black screen. (Our testing environment could be bad, and we readily admit that we are fairly new to Metal compared to other GFX API's) We suspect that it might be related to the difference between depth2d and texture2d types in MSL shaders.

Our time on this has unfortunately run out a bit, and it will take a while until we have more time to look at it. If anyone wants to take a look at and fix issues with this PR it would be greatly appreciated. :)

[pseregiet]

Hi. This is required to create a render pass with a cubemap depth buffer attachment

diff --git a/3rdparty/sokol/sokol_gfx.h b/3rdparty/sokol/sokol_gfx.h
index ec893f7..bd4be4f 100644
--- a/3rdparty/sokol/sokol_gfx.h
+++ b/3rdparty/sokol/sokol_gfx.h
@@ -6964,8 +6964,18 @@ _SOKOL_PRIVATE sg_resource_state _sg_gl_create_pass(_sg_pass_t* pass, _sg_image_
         if (_sg.gl.ext_depth_read) {
             const GLuint gl_depth_tex = pass->gl.ds_att.image->gl.tex[0];
             SOKOL_ASSERT(gl_depth_tex);
-            glFramebufferTexture2D(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_TEXTURE_2D, gl_depth_tex, 0);
-             if (_sg_is_depth_stencil_format(pass->gl.ds_att.image->cmn.pixel_format)) {
+            switch (pass->gl.ds_att.image->cmn.type) {
+                case SG_IMAGETYPE_2D:
+                    glFramebufferTexture2D(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_TEXTURE_2D, gl_depth_tex, 0);
+                    break;
+                case SG_IMAGETYPE_CUBE:
+                    const GLenum slice = _sg_gl_cubeface_target(pass->cmn.ds_att.slice);
+                    glFramebufferTexture2D(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, slice, gl_depth_tex, 0);
+                    break;
+                default:
+                    break;
+            }
+            if (_sg_is_depth_stencil_format(pass->gl.ds_att.image->cmn.pixel_format)) {
                 glFramebufferTexture2D(GL_FRAMEBUFFER, GL_STENCIL_ATTACHMENT, GL_TEXTURE_2D, gl_depth_tex, 0);
             }
         }

With this change you still need to attach a dummy RGB texture even if you don't use it in the shader. Do you have any plans on fixing that ? I tried but I think it's a bit too complicated for me.

[floooh]

Some updates... I was hoping to allow depth texture access in shaders with #834 but ran into various problems in the other 3D backends (specifically D3D11 - do you know if using the TYPELESS pixel formats has any downsides? I've seen that exact same D3D11 validation layer message, but that looks suspiciously simple as a solution lol).

I'll make another attempt after finalizing the WebGPIU backend.

Rendering without color attachments is also on the list to fix (this will be easier I think).

Basically: first finalize the WebGPU backend, then re-evaluate if the following things can be implemented, either across all backends, or behind a per-backend runtime feature flag:

• accessing MSAA textures from shaders (e.g. loading individual samples)
• accessing depth textures from shaders (as 'raw values', not the special 'depth compare' sampling in GLSL)
• depth-only rendering (no color attachments)
• rendering without vertex/index buffer (still won't allow 'proper' vertex pulling from buffers though because at least WebGL2 lacks SSBOs)