Godot's effects scene on our D3D12, after one missing 4-bit texture format

What changed

The Godot editor and a second, heavier Godot scene are now part of the test suite.

The editor test needed no fix in mtl12. In the last session the editor stopped presenting after 10 to 19 frames. That was Godot's low-processor mode, which presents only when something on screen changes. The test now runs the editor with continuous updates turned on and checks frame 120.

The effects scene turns on most of Godot's Forward+ renderer at once:

• screen-space reflections (SSR) on a mirror floor;
• ambient occlusion (SSAO) and screen-space indirect light (SSIL);
• SDFGI, Godot's global illumination from signed distance fields;
• glow, volumetric fog, three shadowed lights and 200 GPU particles.

At first Godot crashed, because CreateResource failed for one texture format, B4G4R4A4_UNORM. SDFGI keeps a 256x128x512 3D texture in it. After that one format, the scene rendered.

The interesting part

B4G4R4A4 packs four 4-bit channels into 16 bits. D3D12 puts blue in the lowest four bits, then green, red and alpha. Metal's closest format, ABGR4Unorm, holds the same bits but reads them the other way round: alpha from the lowest four, then blue, green and red.

mtl12 keeps the bytes as they are and gives every shader view a swizzle, a per-view remap of channels: red comes from Metal's green, green from blue, blue from alpha, and alpha from red. The swizzle is applied on top of whatever channel mapping the application asked for.

Metal can swizzle reads but not writes. So the format is offered for sampling only, and render targets and unordered-access views of it are refused. That is enough for SDFGI, which creates its texture without render-target or unordered-access flags.

The scene's checks were chosen by turning each effect off in turn and seeing which pixels move. With SSR off, the probe on the ball's reflection reads (61,54,65) instead of (233,146,81). With SDFGI off, every probe changes. SSAO moved no pixels in this scene; on a plain floor without SDFGI it changes 755, so it does run.

I also measured what a draw costs Metal 4 on the CPU, for the performance work. Under Rosetta, where Wine's Unix side runs, an indexed draw costs about 88 ns when the argument table (Metal 4's list of buffer addresses for a draw) is unchanged. It costs about 191-197 ns when one address in it changes first. mtl12 changes the root-argument address before every draw. The size of the table makes no difference, and indirect command buffers are no cheaper under Rosetta. No code changed from this yet.

Numbers

• Full run: 846 pass, 29 fail, 76 skip of 951; entry 061 ended at 844 of 948.
• Three tests are new and passing: api/bgra4_texture (194 checks), apps/godot-editor and apps/godot-effects.
• One test is newly failing, apps/Tutorial08_Tessellation: 270 pixels over tolerance against 266 allowed. The same frame appeared once before, in an earlier full run. In four solo reruns it passed with 228, so it is intermittent; the cause is unknown.
• Draw cost under Rosetta, in ns per draw: 88.5 with the table unchanged, 197.0 with one setAddress before each draw, 287.1 with three. Natively: 35.0 and 73.8.