Repository navigation
fix(shader): return 0 for 8-bit UNORM color comparison - #4267
Merged
oneandonlydean merged 1 commit intoOct 12, 2026
Merged
oneandonlydean merged 1 commit into
oneandonlydean merged 1 commit into
Conversation
9 tasks done
10 tasks done
image_sample_c on an 8-bit UNORM T# returns 0 for every compare function on gfx1035, as on 8-bit sRGB (measured on the hardware oracle in the review of boykopovar#3438), but the emulated comparison still compared the red channel. 8, 8_8 and 8_8_8_8 UNORM now return 0 like 8-bit sRGB. Every texel comparison of those formats is 0, so a bilinear cube without DISABLE_CUBE_WRAP and an anisotropic S# cannot change the result; both are accepted for them, as the cube already was for 8-bit sRGB. Other formats keep both refusals. The test rows that check real comparisons move to 16_16 UNORM.
EagleBearerYS
force-pushed
the
fix/shader-color-compare-8bit-unorm-zero
branch
from
October 12, 2026 19:07
69f585a to
a9c625a
Compare
10 tasks done
10 tasks done
|
Other open pull requests touch the same code. Merging one will break the other, or both implement the same thing. If this one builds on them, list them in Depends on.
|
10 tasks done
11 tasks done
Closed
11 tasks done
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Planet of Lana (PPSA19450) aborts on
mainbefore its first frame is presented:The shader does an LOD-zero comparison (
EmulatedCompareflags 0) on a 1x18_8_8_8_UNORMcube with one level, through an anisotropic bilinear S#:MAX_ANISO_RATIO3,XY_MAG_FILTER=XY_MIN_FILTER= 3,DEPTH_COMPARE_FUNC6 (GREATER_EQUAL),DISABLE_CUBE_WRAP0. Descriptors as printed by a local diagnostic:In the review of #3438, adriadam10 measured on the hardware oracle (gfx1035) that
image_sample_con an 8-bit sRGB "(and 8-bit UNORM)" T# returns 0 for every compare function over references -0.5..1.5 and texel codes 0..255. #3438 implemented that for sRGB and left 8-bit UNORM comparing, because the existing tests pinned a real compare. TechnicalDebt has recorded the difference since then.colorCompareReferencenow returnsReferenceZeroforFormat8UNorm,Format8_8UNormandFormat8_8_8_8UNorm, as it does for 8-bit sRGB. InemulatedCompareState, formats with that constant result skip two refusals:DISABLE_CUBE_WRAP, already skipped for 8-bit sRGB since fix(shader): return 0 for an 8-bit sRGB bilinear cube comparison #3540;Every texel comparison of these formats is 0, so neither the selected cube face nor any filter weighting can change the result. All other formats keep both refusals. The addressing, border-table, reduction and unnormalized-coordinate checks are unchanged for every format. The anisotropic S# was not measured, and TechnicalDebt says so.
Changes to the test,
agc_driver_emulated_color_compare:16_16_UNORMinstead of8_8_8_8_UNORM. Red is written as r8 * 257, so the expected values are unchanged. This covers point, bilinear, wrap, border, offsets, channels, the cube withDISABLE_CUBE_WRAP, and the bilinear-cube and anisotropic refusals.8_8_8_8_UNORMcube withoutDISABLE_CUBE_WRAP, for all 8 compare functions;8_8_8_8_UNORMcube with GREATER_EQUAL;8_8_8_8_UNORMfor all 8 compare functions, with point, bilinear and anisotropic bilinear filters;8_UNORMand8_8_UNORMwith LESS_EQUAL and the same three filters.Both color-comparison entries in TechnicalDebt now list the 8-bit UNORM formats.
No open pull request changes these checks. #907 also edits this test, and its real-compare rows use
8_8_8_8_UNORM. If it lands after this change, those rows need a format that compares, such as the16_16_UNORMused here.Tested
Windows 11 Home (10.0.26300), MinGW-w64 GCC 15.2.0 (WinLibs r7), Release, NVIDIA GeForce RTX 3070 Laptop GPU.
main'sResourceMaterializer.cpp,agc_driver_emulated_color_comparefails at the first new row:bilinear cube comparison requires DISABLE_CUBE_WRAP to avoid seamless face filtering.agc_driver_emulated_color_compareandagc_driver_emulated_color_compare_srgb_decodepass 3 runs in a row onmaind371ed3.agc_driver_emulated_color_comparepasses again onmaind146ec1, in a build that also had feat(pad): hold the sticks from the controller command file #4032's unrelated pad change.mainwithout the fix: the stop above, on a11c8f7 and d371ed3.0x20474343(an uncaught host C++ exception). It is still being investigated.python tools/check_conventions.py --base origin/mainpasses.The full suite was not run. Not tested on Linux, macOS or AMD GPUs.
Checklist
main; no other open PR implements the same functionsNotImplemented_nid_no_patch); silent stubs are listed in TechnicalDebt (no unimplemented paths or stubs added).mdfiles or images added to the repository (attach them to this PR)