[alfalfa-star]

What

PS5 shaders usually run with f32 denormals flushed to zero (the float mode in the shader registers). The recompiler emulates this by flushing the result of every f32 operation in SPIR-V, which adds compares and selects around most ALU instructions. In GPU-heavy titles such as Kena: Bridge of Spirits (PPSA01802) this makes the shaders noticeably more expensive.

With APS5_NATIVE_F32_FTZ=1, on a device that supports DenormFlushToZero for 32-bit floats (VK_KHR_shader_float_controls), a shader whose float mode flushes f32 denormals declares the DenormFlushToZero execution mode instead of emulating the flush. Shaders whose float mode keeps denormals are unchanged, and so is everything when the device lacks the capability. Shader validation now accepts the mode as a float-controls execution mode. APS5_NATIVE_F32_FTZ_PIXEL_ONLY=1 limits it to pixel shaders.

Off by default.

Tested

AMD Radeon RX 9070 XT (RADV GFX1201), Mesa 26.2.4, Arch Linux (kernel 7.2.9), Kena: Bridge of Spirits (PPSA01802).

• ctest: no new failures (agc_driver_tessellation segfaults on main without this change; guest_kernel_fcntl is flaky under load and passes on rerun).
• Kena: used in our local test build (RADV, RX 9070 XT) that runs the forest scene at about 24 fps, with no rendering differences seen. A measurement of this change alone on top of main will follow in a comment.

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 (performance of PPSA01802)
• GPUs tested: AMD Radeon RX 9070 XT (RADV GFX1201), Mesa 26.2.4, Arch Linux (kernel 7.2.9)
• AI-assisted: yes

🤖 Generated with Claude Code

[github-actions]

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.

Pull request	Conflicting files (lines on main)	Same exports	Same new files
PR 6767	core/shader/recompiler/SpirvBackend/src/SpirvMemory/SpirvModuleSetup.cpp L329-331
PR 6941	core/shader/recompiler/Recompiler.cpp L533
PR 6947	core/shader/recompiler/Recompiler.cpp L533

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.

Pull request	Shared files not compared
PR 1395	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 4040	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 4048	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp core/shader/recompiler/Recompiler.cpp core/shader/recompiler/SpirvBackend/include/SpirvBackend/SpirvEmitter.hpp core/shader/recompiler/SpirvBackend/include/SpirvBackend/SpirvEmitterState.hpp core/shader/recompiler/SpirvBackend/src/SpirvEmitter.cpp
PR 4072	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp core/libs/prx/libSceAgcDriver/Graphics/src/ShaderValidation.cpp core/shader/recompiler/Recompiler.cpp core/shader/recompiler/Translation/include/Translation/InstructionTranslator.hpp core/shader/recompiler/Translation/include/Translation/TranslationContext.hpp core/shader/recompiler/Translation/src/InstructionTranslator.cpp
PR 4339	core/shader/recompiler/Recompiler.cpp core/shader/recompiler/SpirvBackend/include/SpirvBackend/SpirvEmitterState.hpp core/shader/recompiler/SpirvBackend/src/SpirvEmitter.cpp
PR 4472	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 4650	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp core/shader/recompiler/Recompiler.cpp core/shader/recompiler/SpirvBackend/include/SpirvBackend/SpirvEmitter.hpp core/shader/recompiler/SpirvBackend/include/SpirvBackend/SpirvEmitterState.hpp core/shader/recompiler/SpirvBackend/src/SpirvEmitter.cpp
PR 4891	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 5021	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp core/shader/recompiler/Recompiler.cpp core/shader/recompiler/SpirvBackend/include/SpirvBackend/SpirvEmitterState.hpp core/shader/recompiler/SpirvBackend/src/SpirvEmitter.cpp
PR 5390	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 5431	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 5441	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 5480	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 5499	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 5500	core/shader/recompiler/Recompiler.cpp
PR 5609	core/shader/recompiler/Recompiler.cpp
PR 5925	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 6177	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp core/shader/recompiler/Recompiler.cpp core/shader/recompiler/SpirvBackend/include/SpirvBackend/SpirvEmitter.hpp core/shader/recompiler/SpirvBackend/include/SpirvBackend/SpirvEmitterState.hpp core/shader/recompiler/SpirvBackend/src/SpirvEmitter.cpp
PR 6188	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 6222	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp core/libs/prx/libSceAgcDriver/Graphics/src/ShaderValidation.cpp core/shader/recompiler/Recompiler.cpp core/shader/recompiler/SpirvBackend/include/SpirvBackend/SpirvEmitter.hpp core/shader/recompiler/SpirvBackend/include/SpirvBackend/SpirvEmitterState.hpp core/shader/recompiler/SpirvBackend/src/SpirvEmitter.cpp
PR 6235	core/libs/prx/libSceAgcDriver/Graphics/src/ShaderValidation.cpp
PR 6259	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 6412	core/shader/recompiler/Recompiler.cpp
PR 6416	core/shader/recompiler/SpirvBackend/include/SpirvBackend/SpirvEmitterState.hpp core/shader/recompiler/SpirvBackend/src/SpirvEmitter.cpp
PR 6503	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp core/libs/prx/libSceAgcDriver/Graphics/src/ShaderValidation.cpp core/shader/recompiler/Recompiler.cpp core/shader/recompiler/SpirvBackend/include/SpirvBackend/SpirvEmitter.hpp core/shader/recompiler/SpirvBackend/include/SpirvBackend/SpirvEmitterState.hpp core/shader/recompiler/SpirvBackend/src/SpirvEmitter.cpp core/shader/recompiler/SpirvBackend/src/SpirvMemory/SpirvModuleSetup.cpp core/shader/recompiler/Translation/include/Translation/InstructionTranslator.hpp core/shader/recompiler/Translation/include/Translation/TranslationContext.hpp core/shader/recompiler/Translation/src/InstructionTranslator.cpp core/shader/recompiler/Translation/src/VectorInstructions.cpp
PR 6539	core/shader/recompiler/Recompiler.cpp
PR 6612	core/libs/prx/libSceAgcDriver/Graphics/src/ShaderValidation.cpp core/shader/recompiler/Recompiler.cpp core/shader/recompiler/SpirvBackend/include/SpirvBackend/SpirvEmitterState.hpp core/shader/recompiler/Translation/src/InstructionTranslator.cpp
PR 6718	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 6751	core/shader/recompiler/SpirvBackend/include/SpirvBackend/SpirvEmitterState.hpp core/shader/recompiler/SpirvBackend/src/SpirvEmitter.cpp
PR 6762	core/shader/recompiler/Recompiler.cpp
PR 6879	core/shader/recompiler/Recompiler.cpp

[CnRJay]

Off by default, so the risk is limited to the switch, but it isn't ready to be made default and has gaps now.

• No test. The change alters the SPIR-V of every f32 shader when the switch is set, and nothing checks either the emitted OpExecutionMode ... DenormFlushToZero 32 or that results still match the emulated flush. A shader test that runs v_mul_f32/v_add_f32/v_mac_f32 on denormal inputs and outputs under both settings (the way agc_driver_mad_f32 does it) would show whether the driver flushes inputs as well as results. The execution mode lets the implementation flush operands too, which the emulated flush does not do for every instruction, so the results can differ on ops the old path left alone (conversions, min/max, compares).
• APS5_NATIVE_F32_FTZ_PIXEL_ONLY changes the emitted module but is read in nativeFloat32FlushToZero(request), outside the request. The first switch reaches the cache key through supportedCapabilities; this one doesn't, so a disk cache written with it off serves a module built without the mode when it's on, and the other way around. Take both from the request.
• state->capabilities.push_back(spv::CapabilityDenormFlushToZero) has no duplicate check, unlike the DenormPreserve line above it.
• The measurement "will follow in a comment". The point of the PR is shader cost, so it needs GPU time per dispatch/draw (APS5_PROFILE_GPU=1 is fine for that, as #5353 shows) and the summary lines of main and this PR on the same scene in PPSA01802, warm cache. "About 24 fps in our local test build" is not that.

[alfalfa-star]

Closing in favour of #6503, which does the same thing more safely. I compared the two on main 82ddae7 (Arch Linux, RX 9070 XT, RADV Mesa 26.2.4, Release):

• Correctness: with APS5_NATIVE_F32_FTZ=1, agc_driver_f32_denormal_flush (unchanged from main) gets 381 results wrong, against 0 without the switch. All of them are in instructions or rounding modes that perf(shader): flush f32 denormals in hardware when a startup probe matches the emulation #6503 leaves emulated: v_mul_f32 in directed rounding, v_fma_mix_f32, v_div_fixup_f32, v_mullit_f32, v_min_f32/v_med3_f32/v_max3_f32, frexp, v_mul_legacy_f32 and one compare. perf(shader): flush f32 denormals in hardware when a startup probe matches the emulation #6503's probe reports 0 of 5472 results differing, and the same test passes with it.
• Stability: Kena (PPSA01802) crashed 3 of 3 boots with this switch on, in LinkPipelineFromLibraries during the startup pipeline prebuild. It runs with APS5_NO_GPL=1 or with the flush limited to pixel shaders.
• Speed: Kena's forest title scene, APS5_NO_GPL=1 and APS5_PROFILE_GPU=1 for all sides, two runs each, alternating. GPU time of the 10 programs every side ran, weighted by main's calls: main 3603 ms, perf(shader): flush f32 denormals in hardware when a startup probe matches the emulation #6503 2744 ms (-24%), this PR 2442 ms (-32%). perf(shader): flush f32 denormals in hardware when a startup probe matches the emulation #6503 gets about three quarters of the saving, and the rest comes from the instructions above whose results differ.

AI-assisted: yes (Claude Code)