Allow using depth textures with texture_2d (gpuweb#3038)

kainino0x · web-flow · commit be3d31fb4037 · 2022-06-16T16:56:55.000-07:00
And update the "Reading and Sampling Depth/Stencil Textures" section. Fixes gpuweb#2094
diff --git a/spec/index.bs b/spec/index.bs
@@ -6063,7 +6063,7 @@ typedef double GPUPipelineConstantValue; // May represent WGSL's bool, f32, i32,
 
                         : {{GPUTextureSampleType/"depth"}}
                         ::
-                            |variable| has type `texture_depth_2d`, `texture_depth_2d_array`,
+                            |variable| has type `texture_2d<f32>`, `texture_depth_2d`, `texture_depth_2d_array`,
                             `texture_depth_cube`, `texture_depth_cube_array`, or `texture_depth_multisampled_2d`.
                     </dl>
                 ::
@@ -13264,22 +13264,33 @@ be used with {{GPUSamplerBindingType/"comparison"}} samplers (which may use filt
 
 #### Reading and Sampling Depth/Stencil Textures #### {#reading-depth-stencil}
 
-When reading or sampling a depth component via a `texture_depth_*`-typed binding, the value is
-returned as an `f32` value.
+It is possible to bind a depth-aspect {{GPUTextureView}} to either a `texture_depth_*` binding
+or a `texture_2d<f32>` binding. In both cases, the {{GPUTextureBindingLayout/sampleType}} must
+be {{GPUTextureSampleType/"depth"}}.
 
-Issue(gpuweb/gpuweb#2094): Depending on the resolution of this issue, allow reading/sampling via
-`texture_2d` etc. in the table above and specify the behavior. (`vec4<f32>(D, X, X, X)`?)
-Update the note below which would become slightly outdated.
+When reading or sampling a depth aspect via a binding with type `texture_2d<f32>`,
+it behaves as if the texture contains the values `(D, X, X, X)`, where D is the depth value
+and each X is an implementation-defined unspecified value.
 
-Reading or sampling a stencil component must be done via a normal texture binding
-(`texture_2d`, `texture_2d_array`, `texture_cube`, or `texture_cube_array`).
-When doing so, the value is returned as `vec4<u32>(S, X, X, X)`, where S is the stencil value and each X is an implementation-defined unspecified value.
-Authors must not rely on these `.y`, `.z`, and `.w` components, as their behavior is non-portable.
+Reading or sampling a stencil aspect must be done via a normal texture binding
+(`texture_2d`, `texture_2d_array`, `texture_cube`, or `texture_cube_array`). When doing so,
+it behaves as if the texture contains the values `(S, X, X, X)`, where S is the stencil value
+and each X is an implementation-defined unspecified value.
+
+<div class=example>
+    If a depth texture is bound to `tex` with type `texture_2d<f32>`:
+
+    - `textureSample(tex, ...)` will return `vec4<f32>(D, X, X, X)`.
+    - `textureGather(0, tex, ...)` will return `vec4<f32>(D1, D2, D3, D4)`.
+    - `textureGather(2, tex, ...)` will return `vec4<f32>(X1, X2, X3, X4)` (a completely unspecified value).
+</div>
 
 Note:
-Short of adding a new more constrained stencil sampler type (like depth), it's infeasible for implementations to efficiently paper over the driver differences for stencil reads.
+Short of adding a new more constrained stencil sampler type (like depth), it's infeasible for
+implementations to efficiently paper over the driver differences for depth/stencil reads.
 As this was not a portability pain point for WebGL, it's not expected to be problematic in WebGPU.
-In practice, expect either `vec4<u32>(S, S, S, S)` or `vec4<u32>(S, 0, 0, 1)`, depending on hardware.
+In practice, expect either `(V, V, V, V)` or `(V, 0, 0, 1)` (where `V` is the depth or stencil
+value), depending on hardware.
 
 #### Copying Depth/Stencil Textures #### {#copying-depth-stencil}
 
