Repository navigation
perf(shader): keep native f16 conversion NaN results when a startup probe matches RDNA - #11351
Merged
Merged
Conversation
Contributor
Author
|
AMD runs would be the most useful check here: on RADV both directions are expected to match RDNA, which no GPU I have can show. If you try it, the line to look for at device creation is |
Contributor
|
I verified the release contains both summary assets, both traces and both digest outputs. I reran |
Contributor
Author
|
@MarcZX10 thanks for rerunning the digests. Agreed on the reading: the RTX 4090 pair is only the no-change control. I can't produce an in-title run on a native-path device here: the only one I have is the UHD 770, and Grand Theft Auto V's largest affected shader ( |
|
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.
Some comparisons could not be completed because a pull request conflicts with the base branch. Review these shared files manually before concluding that there is no overlap.
|
Contributor
Author
|
On the overlap table: none of these implements the same thing. #9193, #10069, #10194, #10652, #10846 and #11297 add their own field, probe or flag next to the lines this PR adds ( |
MarcZX10
suggested changes
Oct 26, 2026
MarcZX10
left a comment
MarcZX10
left a comment
Contributor
There was a problem hiding this comment.
Reviewed exact head 1081e2351a4b81d84ad1ce2ad627e6d29ab8368f. I found one blocking replay correctness issue:
VulkanDevice::Target() now sets float16WidenNans and float16NarrowNans, and those values control which SPIR-V the live driver emits. Shader captures go through Driver::dumpRequest() and RequestSerializer::Serialize(), but the serializer remains at format version 46 and writes neither field; Deserialize() likewise leaves both false. A captured request from a device that selected the native path therefore silently replays with the emulated NaN repair unless the user manually supplies the new agc_shader_replay flags. Those flags are a useful override, but they do not preserve the captured request's selected target behavior.
Please append both fields in a versioned serializer update and add round-trip coverage (including backward compatibility for older request versions). Keep the CLI switches if they are useful for explicit overrides.
The branch is also about 142 main commits behind its merge base. The current-main merge preview is clean; the two shared paths have unrelated adjacent changes in CMakeLists.txt and docs/dev/BUILD.md. Please sync to current main and rerun conventions and the focused AGC checks against the refreshed base. The existing GPU and trace results are useful historical evidence, but they were produced from the older base.
Contributor
|
@tibzejoker, a RADV run: head
With Setup
Probe on RADV Every device creation in the focused set logs the same line (53 per run): The probe takes 88-118 ms (median 92) without the validation layer, and about 105 ms with it.
Focused tests, Command:
These runs are on the old base that MarcZX10's review mentions. Once the refreshed head with the serializer change is pushed, I can rerun the same set on the 860M. AI assisted: yes |
Contributor
Author
|
@Lander0606 thank you, this is exactly the run the PR needed, and the NIR check pins it down. You're right on both points:
@MarcZX10 the serializer point is right too: the next push saves both fields in the request (format 47, older versions read them as false, round-trip coverage), keeps the replay flags as explicit overrides, and is rebased on current |
tibzejoker
force-pushed
the
perf/f16-convert-probe
branch
from
October 26, 2026 09:50
1081e23 to
f2300fd
Compare
Contributor
Author
|
Pushed
@Lander0606, if you have time for the same 860M run on this head, the line to check is |
Contributor
Author
|
A related question for AMD owners (@Lander0606, @tablefrogpillow, @wachi35676), separate from this PR: on RADV, I can't test it here (the RTX 4090 and UHD 770 report ALL). Test branch on my fork, on top of this PR: If you can, on that branch, with and without the variable (
If it holds on RADV, I'll propose it as its own PR with those results. Thanks! |
Contributor
|
Thanks for the substantial update. It addresses the serializer persistence issue (format 47, older-version defaults and four flag combinations) and the reported toward-zero fold by removing the f32→f16→f32 conversion pair. The reported RADV/NVIDIA findings and corrected path-specific result are useful. Please refresh the branch from current After rebasing, please rerun the focused serializer and AGC f16/SPIR-V checks on the exact new head. The linked performance release does contain both summary files, traces and digest outputs, but its changed-arm summary is for ancestor |
Contributor
|
@tibzejoker, both runs on the 860M. @MarcZX10, the first part is the post-fix RADV run that the description lists as pending. Setup
This PR at
|
main 4e43321bd6 |
this PR f2300fd2d2 |
|
|---|---|---|
| RADV, without the layer | 59/59, 59/59, 59/59 | 61/61, 61/61, 61/61 |
| RADV, with the layer | 59/59, 59/59, 59/59 | 61/61, 61/61, 61/61 |
| lavapipe, with the layer | 59 pass, 2 of them skipped | 61 pass, 2 of them skipped |
RADV, full ^agc (-j8, without the layer) |
1029 of 1030 | 1031 of 1032 |
- Validation: the layer was inserted 53 times per run on
mainand 54 on this PR. No log containswas not found but was requested by env var VK_INSTANCE_LAYERS, and no run logs aVUID-line. - Full
^agcrun: on both trees, the only failure isagc_driver_tessellation, the Mesa 26.2.5 crash, with the same 15 skips. - lavapipe:
agc_driver_float16_nativeandagc_driver_packed_float16_nativeskip there on both trees. Its probe logs no native conversion in either direction. - Probe time: 89-115 ms (median 92) without the layer.
test/coupled-f16-f64-denorms at fe10c0205c
The set is ctest -j1 -V -R "^agc.*(f16|float16|f64|convert|pack|interpolation)" -E "^agc_driver_bda_device$": 76 tests, 15 more than above (the f64 tests, interpolation_modes and pixel_exec_interpolation).
| without the variable | APS5_COUPLED_F16_F64_DENORMS=1 |
|
|---|---|---|
| RADV, with the layer | 76/76, 76/76, 76/76 | 76/76, 76/76, 76/76 |
| RADV, without the layer | not run | 76/76 |
RADV, full ^agc (-j8, without the layer) |
1031 of 1032 | 1031 of 1032 |
[float-controls] lines on RADV, the same in every one of the 67 device creations per run:
Without the variable:
[float-controls] f16 to f32 NaN results: emulated (no native conversion); f32 to f16 NaN results: native (0 of 220032 probe results differ)
With the variable:
[float-controls] f16 and f64 denormals share one mode on this device: DenormPreserve 16 and 64 are declared together
[float-controls] f16 to f32 NaN results: native (0 of 262144 probe results differ); f32 to f16 NaN results: native (0 of 220032 probe results differ)
With the variable, agc_driver_float16_conversion_probe adds v_cvt_f32_f16 native vs emulated: 0 of 65536 differ (quiet NaN 0, signalling NaN 0, not NaN 0); the device uses the native result. It ends with f16 conversion probe tests passed (f16 to f32 compared, f32 to f16 compared).
- f16 -> f32: RADV now probes this direction, and every result matches. With the variable, both directions are native.
- f64 DenormPreserve on: the 13 f64 tests in the set pass with it, among them
f64_fma_subnormals,f64_rounding_denormal_modesanddiv_fixup_f64_denormal_modes. So do the two interpolation tests. - Validation: no run logs a
VUID-line. The layer was inserted 68 times per run, and no log contains the not-found line. - Full
^agcrun: with and without the variable, the only failure isagc_driver_tessellation, with the same 15 skips as above. - Probe time with the variable: 118-138 ms (median 120) without the layer, against about 92 ms without the variable. Probing f16 -> f32 adds about 28 ms per device creation.
- lavapipe, with the variable and the layer: no
share one modeline, because that device doesn't report32_BIT_ONLY. 76 pass, 3 of them skipped:f64_fma_subnormals,float16_nativeandpacked_float16_native.
A limit of the zero VUID- result. I checked whether the layer would catch an uncoupled declaration:
- I made a local change, since removed, that drops the f64 half of
EmitF16DenormPreserve. Modules without f64 then declare onlyDenormPreserve 16. - With the variable and the layer,
agc_driver_float16_conversion_probestill logged noVUID-line. - The layer has
VUID-RuntimeSpirv-denormBehaviorIndependence-06289, but here it doesn't flag a missing 64-bit mode. So the zero count above doesn't by itself show that the modes are coupled. - What does show it is the code: on this branch, the only 16- and 64-bit
DenormPreservedeclarations are inEmitF16DenormPreserveandEmitF64DenormPreserve(git grep ExecutionModeDenorm), and each of the two declares the other.
Not checked: SPIR-V size or performance with the variable, and no title was run.
AI assisted: yes
MarcZX10
suggested changes
Oct 26, 2026
MarcZX10
left a comment
MarcZX10
left a comment
Contributor
There was a problem hiding this comment.
Re-reviewed exact head f2300fd. The serializer blocker is resolved: format 47 stores both flags, older requests default them to false, four flag combinations round-trip, truncation is rejected, and the cache key includes both flags. The new RADV 860M results on this exact head also address the previously pending focused GPU run. Current main advanced beyond the branch base, but none of the 42 intervening main paths overlap the PR's changed files and the merge preview is clean, so I found no new source-integration issue.
One required performance-report item remains. This PR is labeled , but its attached summary pair is for main commit and PR commit , not the final head . That trace pair also uses an RTX 4090 where the report says both native flags stay disabled, so it checks that the tested scene does not regress but does not measure the optimization. Please provide the required same-title/scene/machine main-and-final-head captures with output from a run that exercises the native path, or update the performance claim and follow the repository's reporting rule for the resulting scope. Please also bring the new RADV 860M exact-head result from the discussion into the Tested section, which still describes that rerun as pending.
MarcZX10
suggested changes
Oct 26, 2026
MarcZX10
left a comment
MarcZX10
left a comment
Contributor
There was a problem hiding this comment.
Re-reviewed exact head f2300fd2d20dc81095448ef7fe920f711f00a7f8. The serializer blocker is resolved: format 47 stores both flags, older requests default them to false, four flag combinations round-trip, truncation is rejected, and the cache key includes both flags. The new RADV 860M results on this exact head also address the previously pending focused GPU run. Current main advanced beyond the branch base, but none of the 42 intervening main paths overlap the PR's changed files and the merge preview is clean, so I found no new source-integration issue.
One required performance-report item remains. This PR is labeled perf, but its attached summary pair is for main commit 14c99b52ace3 and PR commit 1081e2351a4b, not the final head f2300fd2d2. That trace pair also uses an RTX 4090 where the report says both native flags stay disabled, so it checks that the tested scene does not regress but does not measure the optimization. Please provide the required same-title, same-scene, same-machine main-and-final-head captures with tools/trace_digest.py output from a run that exercises the native path, or update the performance claim and follow the repository's reporting rule for the resulting scope. Please also bring the new RADV 860M exact-head result from the discussion into the Tested section, which still describes that rerun as pending.
tibzejoker
force-pushed
the
perf/f16-convert-probe
branch
from
October 26, 2026 11:10
f2300fd to
20a660b
Compare
Contributor
Author
|
@MarcZX10 refreshed: head
|
Contributor
Author
|
For the AMD question above: |
MarcZX10
previously requested changes
Oct 26, 2026
MarcZX10
left a comment
MarcZX10
left a comment
Contributor
There was a problem hiding this comment.
Re-reviewed exact head 20a660bea49eb726e84a3ebfe4a3a92a28e2b7b4 against current main 4e38e2388219e065eba52461f2e59234fcb57b13. Two blockers remain:
-
Current-main serializer integration. Since the branch was refreshed from
5b5d24cb22,mainaddedColorExportPacking::Uintand updatedreadColorExportPackingto accept it. This head still caps that decoder atUnorm4_4_4_4; after merging currentmain, valid requests usingUintwould be rejected unless the new bound is retained alongside format 47’s two f16 flags.mainalso changed the shared AGC CMake and SPIR-V module-emitter files. Please merge currentmain, preserve both changes, and rerunrequest_serializerplus the focused f16 tests on the resulting head. -
Performance evidence does not exercise the optimized path. The body’s final-head GTA V pair is on an RTX 4090 where both native flags remain disabled and the replayed modules are word-for-word unchanged. That is useful as a no-regression control, but does not measure the claimed native-conversion optimization. The body also still says the RADV 860M rerun on this head is pending, although later comments report it. Please provide a same-title/main/final-head trace and digest on a device where the probe selects the changed path, or get maintainer direction for an applicable tooling/performance report and update the claim accordingly. Move the exact-head RADV result into
Testedas well.
The policy checks pass, but the PR’s product jobs are skipped by path policy; these integration and GPU checks therefore need evidence on the refreshed head before approval.
Contributor
Author
|
@Lander0606 thank you, that settles both questions: on RADV this PR now takes native f32 -> f16 with 0 differences, and with the coupled modes both directions are native, all 76 f16/f64/interpolation tests pass and the f64 denormal tests still hold. Your check of the layer (it doesn't flag an uncoupled declaration) is useful too; I'll put that in the coupled PR's body and add a SPIR-V check that every module declaring one of the two modes declares the other, rather than rely on the layer. I'll open the coupling as its own PR with your numbers. @MarcZX10 understood on both points: I'll merge current |
Contributor
|
@tibzejoker, I have no title to run on the 860M, so I can't give that load-window pair. Once the head with current |
Contributor
Author
|
@Lander0606 thanks, understood. I'll ping you here once the head with current |
tibzejoker
force-pushed
the
perf/f16-convert-probe
branch
from
October 26, 2026 16:17
20a660b to
6e17eb4
Compare
12 tasks done
tibzejoker
force-pushed
the
perf/f16-convert-probe
branch
from
November 2, 2026 21:06
0ac8ccd to
32cc90d
Compare
Contributor
Author
|
@adriadam10 @MarcZX10 rebased onto current
On both trees the one UHD failure is
I also updated the note on #11483: it takes 54 once this lands. AI-assisted: yes (Claude Code) |
github-actions
Bot
added
needs rebase
Contributor
✅ NVIDIA GPU test: passedPR head
Unstable on main (3, these also failed in recent main runs on this machine; not counted against this PR)Failing on main too (3, not counted against this PR)Validated but not compared (1, not in the main baseline's validation pass)Validation IDs already present on main (4 IDs in 516 tests)Skipped (45)ReproduceAutomated build and test on a contributor's NVIDIA machine; it does not replace upstream CI. A new comment is posted for each new push. Full logs. |
12 tasks done
tibzejoker
force-pushed
the
perf/f16-convert-probe
branch
from
November 3, 2026 18:25
32cc90d to
b0a7aef
Compare
Contributor
Author
|
@adriadam10 @MarcZX10 rebased again onto
Focused set, same command as the body. Validation layer inserted in every run (84 / 85),
The one UHD failure is AI-assisted: yes (Claude Code) |
Contributor
✅ NVIDIA GPU test: passedPR head
Unstable on main (4, these also failed in recent main runs on this machine; not counted against this PR)Failing on main too (3, not counted against this PR)Validated but not compared (1, not in the main baseline's validation pass)Validation IDs already present on main (4 IDs in 518 tests)Skipped (48)ReproduceAutomated build and test on a contributor's NVIDIA machine; it does not replace upstream CI. A new comment is posted for each new push. Full logs. |
Contributor
✅ AMD GPU test: passedPR head
Unstable on main (1, these also failed in recent main runs on this machine; not counted against this PR)Failing on main too (9, not counted against this PR)Validated but not compared (1, not in the main baseline's validation pass)Validation IDs already present on main (4 IDs in 518 tests)Skipped (59)ReproduceAutomated build and test on a contributor's AMD machine; it does not replace upstream CI. A new comment is posted for each new push. Full logs. |
12 tasks done
…robe matches RDNA Native OpFConvert and UnpackHalf2x16 round and handle denormals as RDNA does under RoundingModeRTE and DenormPreserve 16, but Vulkan leaves the NaN they return to the driver, so every conversion rebuilds RDNA's NaN with integer selects (about 55 words per f32 to f16 conversion, 29 per f16 to f32). ProbeFloat16Conversions runs when the device is created: v_cvt_f32_f16 over all 65,536 halves and v_cvt_f16_f32, v_cvt_pkrtz_f16_f32 and a round trip over every NaN payload class, signalling NaNs, denormals, ties and overflow, under four float modes, each compiled with the rebuilt NaN and with the native result, inputs read from a buffer. SpirvTarget::float16WidenNans and float16NarrowNans are set per direction only when every result matches; both are in the recompile cache key. APS5_NO_NATIVE_F16_NANS skips the probe. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PHJtpJ4hw3KWJhobipK8ia
…ults --f16-widen-nans and --f16-narrow-nans set float16WidenNans and float16NarrowNans on a saved request's target, as --robust2 does for its feature, so the SPIR-V of a device whose probe matched can be measured. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PHJtpJ4hw3KWJhobipK8ia
SpirvTarget::float16WidenNans and float16NarrowNans shape the emitted SPIR-V, but the request serializer did not write them, so a request saved on a device whose probe matched replayed with the emulated NaN rebuild. Format version 54 writes both flags after the shader image minimum LOD flag; versions 53 and older read them as false. agc_shader_replay's --f16-widen-nans and --f16-narrow-nans still force them on. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PHJtpJ4hw3KWJhobipK8ia
…integer arithmetic The toward-zero pack corrects the nearest-even half when it widens back above the input. Once the f32 to f16 NaN rebuild is skipped, that half is the OpFConvert result itself and RADV and NVIDIA fold the f32 -> f16 -> f32 pair, so the correction disappeared (140,763 of 280,480 probe inputs rounded to nearest even). NoContraction on the widening is enough on RADV but not on NVIDIA. With float16NarrowNans the half is now widened with integer operations (exact multiply for denormals), which no driver can fold; without it the NaN rebuild still separates the two conversions and the module is unchanged. Co-authored-by: Lander0606 <109523124+Lander0606@users.noreply.github.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PHJtpJ4hw3KWJhobipK8ia
…N fields Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
tibzejoker
force-pushed
the
perf/f16-convert-probe
branch
from
November 4, 2026 18:39
b0a7aef to
6740167
Compare
Contributor
Author
|
@adriadam10 @MarcZX10 rebased onto The conflicts were all "keep both sides" next to code that landed meanwhile:
I re-ran the focused set with the same command as the body. The validation layer was inserted in every run (84 / 85) with
The earlier Intel AI-assisted: yes (Claude Code) |
Contributor
✅ NVIDIA GPU test: passedPR head
Unstable on main (4, these also failed in recent main runs on this machine; not counted against this PR)Failing on main too (3, not counted against this PR)Validated but not compared (1, not in the main baseline's validation pass)Validation IDs already present on main (13 IDs in 549 tests)Skipped (50)ReproduceAutomated build and test on a contributor's NVIDIA machine; it does not replace upstream CI. A new comment is posted for each new push. Full logs. |
12 tasks done
Contributor
✅ AMD GPU test: passedPR head
Unstable on main (1, these also failed in recent main runs on this machine; not counted against this PR)Failing on main too (9, not counted against this PR)Passed on retry (1, failed in the parallel run, passed when re-run with a 360 s timeout; not counted against this PR)Validated but not compared (1, not in the main baseline's validation pass)Validation IDs already present on main (4 IDs in 558 tests)Skipped (60)ReproduceAutomated build and test on a contributor's AMD machine; it does not replace upstream CI. A new comment is posted for each new push. Full logs. |
adriadam10
approved these changes
Nov 6, 2026
adriadam10
dismissed
MarcZX10’s stale review
November 6, 2026 10:27
Dismissing a stale review: the requested changes were addressed after it (new head) and the merge queue blocks on it. Please request changes again if anything is still open.
Collaborator
|
Re-checked on the current head against current |
12 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
Step 3 of #11183. Native f16 conversions keep their own NaN result when a startup probe shows it is already RDNA's.
On a device with Float16,
RoundingModeRTE16 andDenormPreserve16,v_cvt_f16_f32and friends are oneOpFConvert, andv_cvt_f32_f16reads are oneUnpackHalf2x16(#1252, #7698). Rounding, denormals and infinities are fixed by those execution modes; the NaN is not (Vulkan lets the driver return any NaN). So every conversion rebuilds RDNA's NaN with integer ops:0x7e00 | payload >> 13): 11 extra instructions, about 52 words;ProbeFloat16Conversions(Execution/src/Float16ConversionProbe.cpp) runs when the device is created, likeProbeFloat32FlushToZero(#6503). It compiles small RDNA programs twice, with the rebuilt NaN (today's code) and with the native result, dispatches both and compares every dword:v_cvt_f32_f16over all 65,536 halves (garbage in the upper 16 bits);v_cvt_f16_f32,v_cvt_pkrtz_f16_f32andv_cvt_f16_f32followed byv_cvt_f32_f16, over 18,336 f32 values: every top-10 payload of quiet and signalling NaNs of both signs (with 4 low-bit patterns), every exponent with 16 mantissa patterns (ties, sticky bits, overflow to infinity, the largest finite values), and ties at every shift of the f16 denormal range;IEEE_MODE, and a directed f16 rounding mode withFP16_OVFL;SpirvTarget::float16WidenNans/float16NarrowNansare set per direction only when every result matches; the emitter then returns theOpFConvert/UnpackHalf2x16result directly. Both fields are in the recompile cache key. The probe runs on each device creation, so a driver update is probed again.APS5_NO_NATIVE_F16_NANSskips it. The round trip and the toward-zero programs are there because they putOpFConvertnext toOpFConvert. That caught a real problem (found by @Lander0606 on RADV, and the same on NVIDIA):v_cvt_pkrtz_f16_f32corrects the nearest-even half when it widens back above the input, and without the NaN rebuild between them the drivers folded the f32 -> f16 -> f32 pair, so 140,763 of 280,480 inputs came out nearest-even.NoContractionon the widening fixed RADV but not NVIDIA; withfloat16NarrowNansthe half is now widened with integer operations (shift, exact multiply for denormals), which leaves nothing to fold, and without it the module ismain's (the NaN rebuild still separates the two conversions): 0 differences on both GPUs here, and--verify-spirvrequires that this program has no wideningOpFConvert.Both fields are saved in recompile requests (serializer format 54, after main's shader image minimum LOD flag of format 53; 50 stays rejected as on
main; older requests read them as false, round trips of the four combinations inrequest_serializer), so a dumped request replays with the conversions of the device that wrote it. Landing order with #11483: both append to the request format; this PR lands first with 50 and #11483 then takes 51 (agreed there).agc_shader_replay --f16-widen-nans / --f16-narrow-nansforce them on as explicit overrides, so the sizes below can be reproduced.Probe results
0x7fffffff(2,046 of 65,536 halves per mode)0x7fff(9,233 of 280,480 in the test)0x7c01->0x7fc02000, RDNA gives0x7f802000), 1,022 halves; quiet NaNs, denormals and the rest match| Radeon 860M (RADV, Mesa 26.2.5, run by @Lander0606) | not probed:
float16DenormPreserveneedsdenormBehaviorIndependenceALL and RADV reports 32_BIT_ONLY | native: 0 of 220,032 probe results differ, 0 of 280,480 in the test for each of the three programs |So on the RTX 4090 nothing changes, and the f32 -> f16 direction changes on Intel and RADV.
Tested
Windows 11 Pro, MinGW-w64 GCC 15.2.0 (WinLibs r7), Ninja, Release,
BUILD_TESTING=ON,ANYPS5_ENABLE_SPIRV_TOOLS=ON(spirv-val on every module), this head6740167447onmain9ab6a281ea.New test
agc_driver_float16_conversion_probe(tests/execution/Float16ConversionProbe.cpp):agc_driver_float16_conversion_probe_spirv(--verify-spirv, no device needed): with each field set, the conversion loses exactly its NaN select and keeps oneOpFConvert;agc_driver_float16_conversion_probe, on the device: the emulated results are checked against a CPU model of RDNA (v_cvt_f32_f16for all halves,v_cvt_f16_f32and the round trip for the probe set plus 2^18 random f32 values), the native results are compared with them per class (quiet NaN, signalling NaN, not NaN), and the test fails if the device chose the native path for a direction where any result differs. It does not exist onmain.Focused tests,
main9ab6a281ea(this head's base) vs this PR (6740167447),ctest -R "(^agc.*(f16|float16|f64|convert|pack|interpolation|denorm)|request_serializer|shader_memory|agc_float16_conversion)" -E "^agc_driver_bda_device$" -V,VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validationwithVK_LOADER_DEBUG=layer(84 / 85 layer insertions, nowas not foundline),ANYPS5_NO_SHADER_CACHE=1,ANYPS5_REQUIRE_VULKAN=1:mainVUID-lines (main / PR)Both sides pass on both GPUs. The f64 tests skip there (no Float64). Probe lines: RTX 4090 f16->f32 emulated (8184 of 262144), f32->f16 emulated (98484 of 220032); UHD 770 f16->f32 emulated (4088), f32->f16 native (0 of 220032).
RADV, Radeon 860M (Mesa 26.2.5, Fedora 44, GCC 13.3), by @Lander0606 on
f2300fd2d2(the toward-zero fix, before it was made conditional onfloat16NarrowNans) against its basemain4e43321bd6,ANYPS5_REQUIRE_VULKAN=1 ANYPS5_NO_SHADER_CACHE=1, validation layer 1.4.341, three runs each:main^agc(-j8)Every device creation logs
f32 to f16 NaN results: native (0 of 220032 probe results differ); the three programs of the probe test match on all 280,480 inputs. NoVUID-line, 53 / 54 layer insertions. The only full-suite failure isagc_driver_tessellation(Mesa 26.2.5 crash) on both trees. Probe time 89-115 ms. The rerun on6e17eb4b75is offered and will be posted in the comments; the change sincef2300fd2d2only affects devices withoutfloat16NarrowNans.Serializer and probe tests on this head:
request_serializer,agc_shader_memory(both updated for format 54),agc_driver_float16_conversion_probeand_spirvpass.Full agc suite on the RTX 4090, on
9f386f3a29before the rebase (ctest -R "^agc" -E "^agc_driver_bda_device$" -j12): 1061 of 1063 passed; the 2 failures (agc_host_import_cut_lifetime,agc_driver_depth_plane_partial_store) also fail onmain. Every test that opens a device now runs the probe.Size, Grand Theft Auto V compute shaders (the requests from perf(shader): compute v_pk_fma_f16 and v_pk_fmac_f16 with OpFmaKHR #11265, saved on the RTX 4090, replayed with
agc_shader_replay --spvon this head; with no flag the output is word-for-wordmain's). On currentmain78 of them recompile;0x25b390800no longer does (reads or writes a converted float image with 16-bit data, which is not implemented, frommain's eb68ad3 / ede33d5, the same with and without this PR):main, and this PR on NVIDIA (identical modules)Per shader, f32 -> f16 native:
0x25b393000(RCAS) 90,558 -> 73,594 (-18.7 %), both 66,544 (-26.5 %); 5 of 78 shaders change with f32 -> f16 native, 7 with both. On5b5d24cb22, where0x25b390800still recompiled, it went 503,403 -> 419,089 (-16.7 %) with f32 -> f16 native.Startup cost: the probe takes 60-80 ms when run alone (150 ms with the four float modes on either GPU, 236 ms on Intel while 4 tests ran in parallel), on every device creation.
In game (performance form), current
main1db077e876, RTX 4090 (NVIDIA 616.92), no-change control: the open-world load of Grand Theft Auto V from the same save,APS5_TRACE_SECONDS=40:80,APS5_MIMALLOC=1, an emptyANYPS5_SHADER_CACHE_DIRper run, in the order base, PR, base again. On plainmainthe game stops before the menu (GTA V (PPSA04264) stops before the menu: color export format 4 into an unsigned integer target is unsupported #11513), then ~60 s into Story (GTA V (PPSA04264) stops when the save loads: compute shader reads or writes a converted float image with 16-bit data #11425), so both arms carry fix(shader): load and store 16-bit data of converted packed images #11580 and a revert of fix(libSceAgcDriver): export raw 32-bit values into UINT color targets as integers #9789 and nothing else: base0eb521ce4e, PRa02cac6c3d(= base +2b25bd1641), on the fork astest/cvt5-base/test/cvt5-pr. Traces, summaries and full digests (currentmain'strace_digest.py): fork release perf-11351-20261029.Vulkan.ComputePipeline(0x25b390800)On this GPU the probe keeps today's path, so the modules are
main's and the pair is neutral; the probe itself took 138 ms at device creation. The 17.9-18.7 s max frame of each run is the load'sDriver.Packet.memory_wait, not a compile. The first base trace dropped queue worker 0x0 events after 78.4 s, after its compile slice (+55.0 s).{"commit":"0eb521ce4ed3","dirty":false,"env":{"APS5_MIMALLOC":"1","APS5_TRACE_DIR":"","APS5_TRACE_SECONDS":"40:80"},"gpu":"NVIDIA GeForce RTX 4090","driver":"NVIDIA 616.92","os":"Windows 10.0.26200","cpu":"13th Gen Intel(R) Core(TM) i9-13900K","cpu_threads":32,"memory_mib":65295,"title_id":"PPSA04264","title":"Grand Theft Auto V","content_version":"01.005.000","resolution":"3840x2160","window":{"spec":"seconds 40:80","first_present":416,"ms":80021.538},"presents":2006,"frame_ms":{"p50":16.819,"p90":34.585,"p99":123.235,"max":17859.073},"gpu_busy_ms_per_present":3.029,"worker_busy_pct":{"queue worker 0x0":72.895,"queue worker 0x38":23.607,"queue worker 0x20":9.176,"queue worker 0x30":4.826,"queue worker 0x28":4.224},"top_phases_ms_per_frame":{"Driver.Packet":45.128,"Driver.Packet.memory_wait":16.790,"VideoOut.Flip":13.457,"Graphics.Draw":11.570,"VideoOut.Flip.vblank_wait":11.530,"Graphics.Draw.draw_and_resource_release":10.694,"Driver.Packet.rendering_wait":9.274,"Driver.Packet.draw":9.198},"trace_dropped":true,"trace_dropped_threads":{"queue worker 0x0":{"events_full_after_s":78.429,"events_lost":32143,"totals_full":false}},"trace":"aps5-trace-0eb521ce4ed3-6904.json.gz"}
{"commit":"a02cac6c3d21","dirty":false,"env":{"APS5_MIMALLOC":"1","APS5_TRACE_DIR":"","APS5_TRACE_SECONDS":"40:80"},"gpu":"NVIDIA GeForce RTX 4090","driver":"NVIDIA 616.92","os":"Windows 10.0.26200","cpu":"13th Gen Intel(R) Core(TM) i9-13900K","cpu_threads":32,"memory_mib":65295,"title_id":"PPSA04264","title":"Grand Theft Auto V","content_version":"01.005.000","resolution":"3840x2160","window":{"spec":"seconds 40:80","first_present":455,"ms":80038.353},"presents":1897,"frame_ms":{"p50":16.805,"p90":33.589,"p99":203.153,"max":18680.495},"gpu_busy_ms_per_present":2.523,"worker_busy_pct":{"queue worker 0x0":72.994,"queue worker 0x38":1.010,"queue worker 0x20":28.604,"queue worker 0x28":10.702,"queue worker 0x30":2.442},"top_phases_ms_per_frame":{"Driver.Packet":48.503,"Driver.Packet.memory_wait":18.055,"VideoOut.Flip":17.665,"VideoOut.Flip.vblank_wait":15.721,"Graphics.Draw":13.106,"Graphics.Draw.draw_and_resource_release":12.376,"Driver.Packet.draw":11.764,"Driver.Draw":11.742},"trace_dropped":false,"trace":"aps5-trace-a02cac6c3d21-3276.json.gz"}