The dark 3D view, the RSX's fragment TXB, and what came after (2026-10-20)

The hardware fact this found is in docs/RSX.md (the fragment program’s TXB samples wrong whatever the bias), the driver’s answer, Mesa 0045, in docs/DRIVER.md. The earlier smoke runs of the same day (the black textures from the stb_image_resize miscompile, the white-noise music) are in the game’s technical page.

Symptom

The third smoke run (2026-10-20 13:43-13:49, warzone2100 ps3.619 with patches 0004-0008: the stb_image_resize no-vectorize and the Opus byte order, Mesa ps3.545): the sound was right, and the user heard plausible music and effects (white noise before; the card fine, 9 recovered xruns), but the picture was still wrong: the loading bar broken, the 3D view dark (terrain black, structures flat and untextured). The UI was fine. qemu ppc64 rendered the same build correctly, so it was RSX-specific.

Evidence

Every 3D shader of the game samples through texture2D(tex, uv, bias) with a bias of 0, and the UI shaders call texture2D without one. The stripes variant of the recipe (assets/warzone2100-stripes, a shader mod in the autoload mods) draws the 3D shaders in vertical stripes 120 px wide. The four modes repeat from the left edge: TEX without bias, TXB with bias -20, TXB with the game’s bias 0, no texture (flat grey). On the PS3 the TEX stripe was fully right, terrain included (cobbled tiles, the “F1 F2” labels), and both TXB stripes were dark and flat.

Cause

The RSX’s fragment TXB (opcode 0x31, the bias in .w) samples wrong whatever the bias, and Mesa’s nv30 emitted GLSL’s biased lookups as TXB.

Fix

• Mesa 0045 (ps3.628): TXB emitted as TEX, the bias dropped; NV30_TXB_HW=1 keeps the hardware TXB for tests. On ps3.628 the stripes were all textured, NV30_TXB_HW=1 brought the dark TXB band back, and the game rendered like the PC (commits 3fa7528, e43696d).
• warzone2100 0009 drops the bias argument on the GLSL 1.20 path, so the game also works with a Mesa that doesn’t have 0045. Its first version did that only for a bias of 0 and changed nothing (ps3.629): the default LOD distance (“High”, lodDistanceBias -50) makes the bias -0.5. Shaders captured under qemu with MESA_SHADER_CAPTURE_PATH showed it. ps3.633 drops the bias whatever the setting, so the LOD distance option does nothing on GLSL 1.20.

The variants noaniso (anisotropic filtering hidden) and tc0 (no DXT) ran in the same batch and were not needed for the answer.

What came after (moved from docs/TESTS.md’s history rows of 2026-10-20)

• 16:37, Mesa ps3.628: the user, at the TV, compared with the x86 build of the same test on the PC: terrain, textures and grey structures the same. On Mesa ps3.545, ps3.629’s game-side rewrite (0009) did not take effect (dark, magenta-lilac, untextured): the LOD bias above. Stripes photo at 200 s.
• 17:28 (shots1): warzone2100 ps3.633 renders like the PC except the team colour, which the game picks at random every run (not a bug; the recipe pins player 0 to pink since).
• 19:05-20:10, played normally by the user next to the PC build (ps3.633, then ps3.634~dev with patch 0010): like the PC except the grass at the game’s default texture size 2048 (35 GL_OUT_OF_MEMORY, 649 “out of VRAM”); with 0010 (512 on the Cell build) none. Published to stable as ps3.644, then uninstalled: it works, but it is a mouse-and-keyboard game with a sparse UI.