CNA-VGAP-056: The checked-in shader bytecode headers of SDL_GPU and DIRECTX9 come from generators that no CTest or workflow runs and that have no --check mode

CNA snapshot 3b43bd86  ·  Known Issues › Verification gaps  ·  source links pinned to 3b43bd86

spirv_shaders.hpp (SDL_GPU) and the d3d9_*shaders.hpp headers (DIRECTX9) come from hand-run generators with no --check mode and no CTest or workflow, so a shader source edit without regeneration would go unnoticed.

Identifier

CNA-VGAP-056

Category

Verification gap

Subsystem

Testing & evidence

Status

Open

Verified against

CNA 3b43bd86 (3b43bd8687ed46523d873f9bec4b32bd8481dcb5)

Evidence basis

Source-verified: read at TARGET, not executed

Tests touching this area

Yes: see Current tests

Affected contract

The checked-in generated shader headers of the classic renderers (spirv_shaders.hpp for SDL_GPU, the d3d9_*shaders.hpp headers for DIRECTX9)

Expected behaviour

The graphics-ext shader packages set the standard in this tree: generate_shader_package.py --check behind one reproducibility CTest per package, so a checked-in generated artefact stays derivable from its declared sources. The renderer-family headers are generated the same way and would be held to the same guard.

Actual behaviour at TARGET

SDL_GPU's compile_shaders.py accepts only --output, and compile_shaders_sm2.py (DIRECTX9) is documented as not part of any CMake target and run by hand through MinGW and Wine. Neither is referenced by a CMake target, CTest or workflow. verify_d3d_shaders_reproducible.sh is a manual no-change regeneration check of the DIRECTX9 custom shader bytecode that no workflow runs. SpirvPayloadValidation runs spirv-val, which checks validity, not freshness.

Source locations

• modules/renderers/sdl-gpu/src/shaders/compile_shaders.py — main: only --output is parsed; shadow_sampling.glsl beside the script
• modules/renderers/directx9/src/shaders/compile_shaders_sm2.py — docstring: not part of any CMake target, run by hand
• scripts/verify_d3d_shaders_reproducible.sh — manual reproducibility check, referenced by no workflow or CTest
• cmake/Tests/ModuleProbes.cmake — SpirvPayloadValidation (validity only) and the graphics-ext package reproducibility tests

Evidence

Read at 3b43bd86, nothing executed. Searched every CMake file and workflow for references to the generators and the reproducibility script: none names them. No drift was found or claimed; the gap is the missing guard.

Re-verified at c6dec91f: the generators of the renderers retired on 2026-10-13 went with them, together with the shared Direct3D shader directory and its native recompilation script; SDL_GPU's shadow-sampling source now lives beside its own generator instead of being expanded from another renderer's directory.

Focused reproduction

No focused reproduction is known. Nothing has been invented here; the evidence above is what exists.

Current tests

None for the generated headers' freshness: no CTest or workflow runs either generator or compares its output with the checked-in headers. SpirvPayloadValidation runs spirv-val, which checks validity, not freshness; the shader-package reproducibility CTests (ShaderPackageReproducibility and ShaderEffect3DShaderPackageReproducibility) cover the graphics-ext packages only and exit 77 where their tools are absent.

Regression test

Give each generator a --check mode (regenerate to a temporary path and compare bytes) and register one reproducibility CTest per generated header, as tools/shader_package/generate_shader_package.py --check does for the graphics-ext packages.

Blast radius

SDL_GPU and DIRECTX9: an edit to a shader source that is not followed by a regeneration ships stale bytecode without any check noticing.

Workaround

Re-run the generator by hand after a shader source edit and diff the header (for DIRECTX9, scripts/verify_d3d_shaders_reproducible.sh does this manually).