Texture3D depth slices are rejected by tex-stats and omitted from resource metadata #268

What happened?

tex-stats cannot inspect depth slices of a true 3D texture. It validates the requested slice against TextureDescription.arraysize, but RenderDoc reports arraysize == 1 for Texture3D; the valid slice count is the mip-level depth instead.

The regular resource/descriptor output also omits the texture depth, so a CLI user cannot tell that the resource is 3D from those results.

Reproduction

In an Android GLES capture, resource 8413 (RainDropSplash01.dds) is a compressed ASTC 3D texture created as:

glTexStorage3D(GL_TEXTURE_3D, 7, GL_COMPRESSED_RGBA_ASTC_6x6, 64, 64, 4)

RenderDoc's Python API reports:

type=Texture3D, dimension=3, width=64, height=64, depth=4, mips=7, arraysize=1

At draw event 3235:

rdc tex-stats 8413 3235 --mip 0 --slice 0   # succeeds
rdc tex-stats 8413 3235 --mip 0 --slice 1   # fails: slice 1 out of range (max: 0)

Calling controller.GetMinMax() directly with Subresource.slice = 0, 1, 2, 3 succeeds for all four mip-0 depth slices and returns non-zero, distinct data. Therefore this is rdc-cli validation/metadata, not missing capture or RenderDoc API data.

rdc resources / rdc resource and descriptor rows show only width/height. tex_info already exposes type, dimension, depth, mips, and array_size, so the information is available internally.

Source-level cause

src/rdc/handlers/texture.py:335 validates with:

if array_slice < 0 or array_slice >= tex.arraysize:

For Texture3D, validate against requested-mip depth, e.g. max(1, tex.depth >> mip). Array textures/cubemaps should retain arraysize validation.

src/rdc/handlers/query.py:166-170 and src/rdc/handlers/descriptor.py:126-129 enrich texture output with only width/height; they should expose at least depth and preferably dimension/type.

Expected behavior

• tex-stats --mip 0 --slice 0..3 accepts the valid depth slices.
• At mip 1 only slices 0..1 are valid; later mips expose only slice 0.
• Resource and descriptor output make 3D depth visible.
• Add a regression test using TextureType.Texture3D, depth=4, mips>=2, arraysize=1, including a valid nonzero depth slice and an invalid slice for a reduced-depth mip.

I can provide the .rdc capture privately if useful; it contains the Android GLES draw described above.

rdc doctor output

[ok] python: 3.14.3
[ok] platform: windows
[ok] renderdoc-module: version=1.45
[ok] replay-support: renderdoc replay API surface found
[ok] renderdoccmd: E:\Source\rdc-cli\dist-internal\rdc-cli-offline-win64-py314\renderdoc\renderdoccmd.exe (renderdoccmd x64 v1.45 built from 2fc0bc04cb95499635f63986a55bc6f67849dd9f)
[ok] win-python-version: MSBuild renderdoc.pyd found at E:\Source\rdc-cli\dist-internal\rdc-cli-offline-win64-py314\renderdoc\renderdoc.pyd (version check skipped)
[ok] win-vs-build-tools: Visual Studio Build Tools found (version 18.7.11925.98)
[ok] win-renderdoc-install: RenderDoc found at E:\Source\rdc-cli\dist-internal\rdc-cli-offline-win64-py314\renderdoc\renderdoc.dll
[FAIL] win-vulkan-layer: 3 'VK_LAYER_RENDERDOC_Capture' layers registered (capture is ambiguous): E:\Source\rdc-cli\.local\renderdoc\renderdoc.json -> E:\Source\rdc-cli\.local\renderdoc\renderdoc.dll (v45); D:\Program Files\RenderDoc\renderdoc.json -> D:\Program Files\RenderDoc\renderdoc.dll (v45); D:\Program Files\RenderDocAI\renderdoc.json -> D:\Program Files\RenderDocAI\renderdoc.dll (v44)
[ok] adb: found: D:\Program Files\RenderDoc\plugins\android\adb.EXE
[ok] android-apk: not found (run: rdc setup-renderdoc --android)
[ok] renderdoc-variant: upstream (1.45)

OS / Platform

Windows 11; Android GLES capture replayed with RenderDoc 1.45

Python version

Python 3.14.6

rdc-cli version

0.6.1 (local source commit 8d31fc2)

Capture file

Android GLES capture. Texture: GL_TEXTURE_3D / GL_COMPRESSED_RGBA_ASTC_6x6, 64x64x4, 7 mips. Capture available privately on request.