We currently have a special requirement that all depth textures must use a special texture_2d_depth type in the WGSL shader. While it's common to have special shadow sampler types for doing comparison tests, it's not common for shaders just loading depth values to require it. This is somewhat of an annoying requirement for engines, though not an impossible one; I'd like to see if it is strictly necessary.

This requirement seems to originate from the Metal Shading Language Specification, which says:

You must declare textures with depth formats as one of the following texture data types:
depth2d<T, access a = access::sample>
depth2d_array<T, access a = access::sample>
depthcube<T, access a = access::sample>
depthcube_array<T, access a = access::sample>
depth2d_ms<T, access a = access::read>
depth2d_ms_array<T, access a = access::read>

However, I looked at the common shader tools for Metal, and found:

• glsl-optimizer only outputs depth2d for comparison samplers: https://github.com/aras-p/glsl-optimizer/blob/d78c3d2f249aa870368ad320905bc954c47704f6/src/glsl/ir_print_metal_visitor.cpp#L471-L474
• SPIRV-Cross only outputs depth2d if comparison operations were used on the samplers: https://github.com/KhronosGroup/SPIRV-Cross/blob/c2500e504d2b823d73d2f129e4f4f050e9618ecb/spirv_msl.cpp#L13498-L13540

These two tools cover a substantial amount of games shipping on Unity and Unreal. So, it seems that these operations are "de facto" spec'd to work.

I think this could be evidence that we could drop the texture_2d_depth requirement for simply loading depth textures, though it could still be required for doing comparison sampling.

The second issue is that loading from a depth texture seems to have undefined values for the second, third and fourth components in loads, as seen in the Metal Shading Language Specification:

For a texture with the MTLPixelFormatR8Unorm pixel format, the default values for unspecified normalized components are G = 0.0, B = 0.0, and A = 1.0. For a texture with depth or stencil pixel format (such as MTLPixelFormatDepth24Unorm_Stencil8 or MTLPixelFormatStencil8), the default value for an unspecified component is undefined.

(This is a bizarre contradiction in the spec. depth2d's special load function only returns one component, there are no "unspecified components", so how could they even be undefined? This gives me some confidence that the texture loads are actually spec'd.)

On new enough devices, we could use texture swizzles, but that doesn't work for all platforms we want to support. However, given that I expect loading the G/B/A channels from a depth texture to be relatively rare in content, I think it could be solved by compiling an extra shader at pipeline creation time on these devices only if they access G/B/A of a depth texture load. But others can respond with the difficulty of such an approach.