gpuweb · kvark · Nov 24, 2021 · Nov 20, 2021 · Nov 20, 2021 · Nov 20, 2021
diff --git a/spec/index.bs b/spec/index.bs
@@ -5718,10 +5718,17 @@ write into a [=texture=] from the {{GPUQueue}}.
   - For {{GPUTextureDimension/2d}} textures, data is copied between one or multiple contiguous [=images=] and [=array layers=].
   - For {{GPUTextureDimension/3d}} textures, data is copied between one or multiple contiguous [=images=] and depth [=slices=].
 
+Issue: Define images more precisely. In particular, define them as being comprised of [=texel blocks=].
+
 Operations that copy between byte arrays and textures always work with rows of [=texel blocks=],
 which we'll call <dfn dfn>block row</dfn>s. It's not possible to update only a part of a [=texel block=].
 
-Issue: Define images more precisely. In particular, define them as being comprised of [=texel blocks=].
+[=Texel blocks=] are tightly packed within each [=block row=] in the linear memory layout of an
+image copy, with each subsequent texel block immediately following the previous texel block,
+with no padding.
+This includes [[#depth-formats|copies to/from specific aspects of depth/stencil textures]]:
+stencil values are tightly packed in an array of bytes;
+depth values are tightly packed in an array of the appropriate type ("depth16unorm" or "depth32float").
 
 Issue: Define the exact copy semantics, by reference to common algorithms shared by the copy methods.
 
@@ -5743,7 +5750,7 @@ Issue: Define the exact copy semantics, by reference to common algorithms shared
 
 ### <dfn dictionary>GPUImageCopyBuffer</dfn> ### {#gpu-image-copy-buffer}
 
-In an image copy operation, {{GPUImageCopyBuffer}} defines a {{GPUBuffer}} and, together with
+In an [=image copy=] operation, {{GPUImageCopyBuffer}} defines a {{GPUBuffer}} and, together with
 the `copySize`, how image data is laid out in the buffer's memory (see {{GPUImageDataLayout}}).
 
 <script type=idl>
@@ -5768,7 +5775,7 @@ dictionary GPUImageCopyBuffer : GPUImageDataLayout {
 
 ### <dfn dictionary>GPUImageCopyTexture</dfn> ### {#gpu-image-copy-texture}
 
-In an image copy operation, a {{GPUImageCopyTexture}} defines a {{GPUTexture}} and, together with
+In an [=image copy=] operation, a {{GPUImageCopyTexture}} defines a {{GPUTexture}} and, together with
 the `copySize`, the sub-region of the texture (spanning one or more contiguous
 [=texture subresources=] at the same mip-map level).
 
@@ -5892,7 +5899,7 @@ dictionary GPUImageCopyExternalImage {
 <dl dfn-type=dict-member dfn-for=GPUImageCopyExternalImage>
     : <dfn>source</dfn>
     ::
-        The source of the image copy. The copy source data is captured at the moment that
+        The source of the [=image copy=]. The copy source data is captured at the moment that
         {{GPUQueue/copyExternalImageToTexture()}} is issued.
 
     : <dfn>origin</dfn>
@@ -5978,7 +5985,7 @@ dictionary GPUImageCopyExternalImage {
         </div>
 </dl>
 
-### Image Copies ### {#image-copies}
+### <dfn dfn lt="image copy">Image Copies</dfn> ### {#image-copies}
 
 WebGPU provides {{GPUCommandEncoder/copyBufferToTexture()}} for buffer-to-texture copies and
 {{GPUCommandEncoder/copyTextureToBuffer()}} for texture-to-buffer copies.
@@ -9960,7 +9967,8 @@ and {{GPUTextureUsage/STORAGE_BINDING|GPUTextureUsage.STORAGE_BINDING}} usage re
 
 ### Depth/stencil formats ### {#depth-formats}
 
-All depth formats support {{GPUTextureUsage/COPY_SRC}}, {{GPUTextureUsage/COPY_DST}}, {{GPUTextureUsage/TEXTURE_BINDING}}, and {{GPUTextureUsage/RENDER_ATTACHMENT}} usage. However, the source/destination is restricted based on the format.
+All depth formats support {{GPUTextureUsage/COPY_SRC}}, {{GPUTextureUsage/COPY_DST}}, {{GPUTextureUsage/TEXTURE_BINDING}}, and {{GPUTextureUsage/RENDER_ATTACHMENT}} usage.
+However, the source/destination of copy operations is restricted based on the format.
 
 None of the depth formats can be filtered.
 
@@ -10033,9 +10041,28 @@ In practice, expect either `vec4<u32>(S, S, S, S)` or `vec4<u32>(S, 0, 0, 1)`, d
 
 Additionally, {{GPUTextureFormat/depth32float}} textures can be copied into {{GPUTextureFormat/depth32float}} and {{GPUTextureFormat/r32float}} textures.
 
-Note:
-{{GPUTextureFormat/depth32float}} texel values have a limited range. As a result, copies into
-{{GPUTextureFormat/depth32float}} textures are only valid from other {{GPUTextureFormat/depth32float}} textures.
+The texel values of depth32float formats
+({{GPUTextureFormat/"depth32float"}} and {{GPUTextureFormat/"depth32float-stencil8"}}
+have a limited range.
+As a result, copies into such textures are only valid from other textures of the same format.
+<!-- Update this if an unrestricted-depth feature is added. -->
+
+The depth aspects of depth24plus formats
+({{GPUTextureFormat/"depth24plus"}} and {{GPUTextureFormat/"depth24plus-stencil8"}})
+have opaque representations (implemented as either "depth24unorm" or "depth32float").
+The depth aspect of {{GPUTextureFormat/"depth24unorm-stencil8"}}
+doesn't have a aligned tightly-packed representation (the depth aspect is 3 bytes).
+As a result, depth-aspect [=image copies=] are not allowed with these formats.
+
+<div class=note>
+    It is possible to imitate these disallowed copies:
+
+    - All of these formats can be written in a render pass using a fragment shader that outputs
+        depth values via the `frag_depth` output.
+    - Textures with "depth24plus"/"depth24unorm" formats can be read as shader textures, and
+        written to a texture (as a render pass attachment) or
+        buffer (via a storage buffer binding in a compute shader).
+</div>
 
 Issue: clarify if `depth24plus-stencil8` is copyable into `depth24plus` in all target backend APIs.