fix(test): compare linear-mip 1D samples only against DIM 1D

[mitul72]

What

The explicit-LOD test added in #5583 checked the linear-mip cases against an absolute blend of the two mip levels (10 + 40 * LOD). The weight a host GPU applies between levels is a property of its filtering, not of the 2D-through-1D path. On an RTX 4090 (NVIDIA 616.92), as reported in #5583, the 2D-through-1D sample and the reference image_sample_l with DIM 1D return the same bits but blend with weight 0.4375 at LOD 1.25 instead of 0.25, so agc_driver_image_plane_address_on_line fails on main there.

The linear-mip cases keep the bit-for-bit comparison with image_sample_l DIM 1D through the same T#, which is what the feature claims. Point sampling keeps its absolute texel and level checks. Test-only change.

Tested

Linux, RX 9060 XT (RADV GFX12): agc_driver_image_plane_address_on_line passes. Not run on NVIDIA here; the failing case is the one reported in #5583.

Checklist

• Based on current main; no other open PR implements the same functions
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw (NotImplemented_nid_no_patch); silent stubs are listed under Silent stubs in their library's technical debt file
• No notes, investigation .md files or images added to the repository (attach them to this PR)
• New third-party code is a submodule built from source
• Generic behaviour, not specific to one title
• Depends on: none
• Unblocks: none
• GPUs tested: AMD Radeon RX 9060 XT (RADV GFX12), Linux
• AI-assisted: yes

🤖 Generated with Claude Code

[mitul72]

Marking this as a draft: the same check passed on an RTX 4090 (same driver) at #5583's pre-merge head a98b065, so something in the merged combination with #5375/#5456 changed what NVIDIA computes for 1D explicit-LOD samples. I'm comparing the generated SPIR-V and sampler/view state between those heads to find the cause instead of relaxing the test.

[mitul72]

Found the likely cause. Between a98b065 (passes on the 4090) and e52e140 (fails), the SPIR-V, samplers and image views for this case are byte-identical. The only difference is that the sampled VkImage is now created with VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT, from #4487 (sRGB twin views for FORCE_DEGAMMA samplers), for every format that has an sRGB twin, RGBA8 included. RADV is unaffected. @frankea, could you check whether this case returns 60.00 on the 4090 with VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT removed from the imageInfo.flags line in Texture::Texture? If it does, NVIDIA blends mip levels differently for every mutable-format texture, and the fix belongs in setting that flag only where an sRGB view is actually needed, not in relaxing this test. cc @Pipodi

[frankea]

@mitul72 Ran it. Removing VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT does not change the 4090's result, and neither does reverting #4487 as a whole, so the flag is not the cause.

Windows 11 (26200), RTX 4090 (NVIDIA 616.92), MinGW-w64 GCC 15.2.0 r7 (UCRT), Release, BUILD_TESTING=ON, agc_driver_image_plane_address_on_line with --repeat until-pass:3:

Tree	Result
main 31cbb55	fails 3 of 3: thread 12 blends the levels to 67.501945, expected 60.000000
main 31cbb55 with the SrgbTwinFormat(...) ? VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT : 0u term removed from imageInfo.flags in Texture::Texture (Texture.cpp:274; the two other MUTABLE_FORMAT sites untouched)	fails 3 of 3, same 67.501945
e52e140 (the #5583 merge) with #4487 reverted (git revert -m 1 afc8541d1, clean, 8 files)	fails 3 of 3, same 67.501945
main 31cbb55 + this PR's head a0142ae	passes 3 of 3

So on this card the value is stable at 67.501945 whatever the image's create flags, and the only thing that changes the verdict is the check itself. Two more facts that narrow where to look:

• The PR's test and recompiler change are byte-identical before and after its rebase: a98b065 (parent d167000) and e52e140 (parent 4808d9c) differ only in docs/dev/debt/shader.md (fetched a98b065's patch from the GitHub API, the object is no longer reachable). So @tibzejoker's pass at a98b065 and the fail at e52e140 bracket 411 first-parent merges of main between d167000 and 4808d9c, not a change in fix(shader): read explicit-LOD 2D samples through 1D T#s as measured #5583 itself.
• Walking that range with the PR's test and recompiler change applied on top (git apply of the test file plus the two-line flatLineExplicitLod change, identical to the PR's) gives the same 67.501945, 3 of 3 each time, at every point: d167000 (a98b065's own parent), 9a22507 (just before fix(shader): read 1D T#s through 3D image_sample and image_load accesses #5375), 31d951e (fix(shader): read 1D T#s through 3D image_sample and image_load accesses #5375 merged), 2077b53 (fix(shader): compare through 2D image_sample_c on 1D T#s #5456 merged), and e52e140 itself. So on this 4090 the linear-mip check never passed at any base; nothing in main flipped it. The one 4090 pass on record is @tibzejoker's run of a98b065 on fix(shader): read explicit-LOD 2D samples through 1D T#s as measured #5583 (same driver, 616.92, a machine that also has an Intel UHD 770 and picks GPUs with ANYPS5_GPU); I cannot reproduce it here, and I do not know what differs. Everything on this box says the 10 + 40 * LOD weight is AMD's and this driver blends 1D mips at 0.4375 for LOD 1.25, which is what this PR's DIM 1D comparison accepts.

Side finding from the same runs: with the flag removed, agc_driver_image_sample_reduction also failed, but it fails on plain main 31cbb55 too (min, 2x anisotropic bilinear, point mip: thread 0 sampled 5.000000, expected 17.000000, 2 of 2), so that is a separate NVIDIA failure from #5821, reported there.

AI-assisted: yes (Claude Code).