Title
FMV (.vp6) black screen on the host render target path (D3D12 / Vulkan with render_target_path_vulkan="")
Platform
Windows 11, AMD Radeon RX 6700 (discrete desktop GPU), D3D12 backend (Windows default).
The README notes D3D12 is "first bring-up, only tested on Steam Deck APU" — this is a report from a desktop discrete GPU.
Summary
The intro FMVs (.vp6, VP6 codec) play with black video (audio OK) on the host render target path:
- D3D12 — always (D3D12 only has the host RT path)
- Vulkan when
render_target_path_vulkan = "" is forced
The fragment shader interlock path (Vulkan default since 11f7e299) plays the videos perfectly on the same hardware.
Investigation summary (full details in attached DEBUG_REPORT.md)
The D3D12 presentation pipeline works end-to-end. Verified with a diagnostic cvar (vp6_test_pattern = "d") that fills the video's host RT (1280x2048, 1xMSAA, k_2_10_10_10) with solid blue before the dump:
- Host RT readback: 100% non-zero (blue) — the fill lands
edram_buffer_ readback after dump: 100% non-zero (blue) — the dump shader works- The menu/animations display the fill (blue shown as red — an R↔B channel swap in the conversion) — dump → copy → swap texture → presenter all work
The FMV itself stays black because:
VP6-DIAG DUMPRT: the video RT is only dumped ~20 frames (~360 ms) at the start of each FMV; for the rest of the FMV a different RT (4xMSAA) is dumped instead — the game stops drawing to the video RT (or the host RT cache evicts it)VP6-DIAG TEXLOAD: the frontbuffer (0x034EC000) is loaded as fmt=7 (k_2_10_10_10, 32bpb) although the fetch constant says fmt=54 (k_2_10_10_10_AS_16_16_16_16, 16-bit-per-channel storage, 64bpb) — suspected load-stride mismatch
Reproduction (D3D12)
# simpsons.toml
vp6_test_pattern = "d" # diagnostic: fill the video RT with solid blue pre-dump
With "d": menu/animations turn red (the blue fill with R↔B swap) — proving the chain works — while the FMV stays black.
Logs (attached)
simpsons_017.log / 018.log (Test D), 021.log (TEXLOAD + DUMPRT), 022.log (DUMPRT per second).
Note: logs contain local diagnostic instrumentation (VP6-* prefixes) not part of the project.
Workaround
Use the Vulkan backend (FSI path) — videos play fine on the tested hardware. A 90-minute session with the Vulkan build ran without issues (see Issue # for the level-load workaround needed on top).
Suggested next step
Investigate why the video RT stops being dumped after ~20 frames in the host RT path (RT cache eviction vs the game stopping its draws), and/or the fmt=54 → fmt=7 load-stride mismatch.
Title
FMV (.vp6) black screen on the host render target path (D3D12 / Vulkan with
render_target_path_vulkan="")Platform
Windows 11, AMD Radeon RX 6700 (discrete desktop GPU), D3D12 backend (Windows default).
The README notes D3D12 is "first bring-up, only tested on Steam Deck APU" — this is a report from a desktop discrete GPU.
Summary
The intro FMVs (.vp6, VP6 codec) play with black video (audio OK) on the host render target path:
render_target_path_vulkan = ""is forcedThe fragment shader interlock path (Vulkan default since
11f7e299) plays the videos perfectly on the same hardware.Investigation summary (full details in attached DEBUG_REPORT.md)
The D3D12 presentation pipeline works end-to-end. Verified with a diagnostic cvar (
vp6_test_pattern = "d") that fills the video's host RT (1280x2048, 1xMSAA, k_2_10_10_10) with solid blue before the dump:edram_buffer_readback after dump: 100% non-zero (blue) — the dump shader worksThe FMV itself stays black because:
VP6-DIAG DUMPRT: the video RT is only dumped ~20 frames (~360 ms) at the start of each FMV; for the rest of the FMV a different RT (4xMSAA) is dumped instead — the game stops drawing to the video RT (or the host RT cache evicts it)VP6-DIAG TEXLOAD: the frontbuffer (0x034EC000) is loaded asfmt=7(k_2_10_10_10, 32bpb) although the fetch constant saysfmt=54(k_2_10_10_10_AS_16_16_16_16, 16-bit-per-channel storage, 64bpb) — suspected load-stride mismatchReproduction (D3D12)
With
"d": menu/animations turn red (the blue fill with R↔B swap) — proving the chain works — while the FMV stays black.Logs (attached)
simpsons_017.log / 018.log (Test D), 021.log (TEXLOAD + DUMPRT), 022.log (DUMPRT per second).
Note: logs contain local diagnostic instrumentation (VP6-* prefixes) not part of the project.
Workaround
Use the Vulkan backend (FSI path) — videos play fine on the tested hardware. A 90-minute session with the Vulkan build ran without issues (see Issue # for the level-load workaround needed on top).
Suggested next step
Investigate why the video RT stops being dumped after ~20 frames in the host RT path (RT cache eviction vs the game stopping its draws), and/or the fmt=54 → fmt=7 load-stride mismatch.