Repository navigation
fix(agc): take the dword pattern-fill kernel only through a 32-bit output format - #4605
Merged
oneandonlydean merged 1 commit intoOct 12, 2026
Conversation
…tput format The kernel boykopovar#2081 matches stores each pattern dword with buffer_store_format_x, so what lands in memory depends on the output descriptor's FORMAT (bits 12-18 of user[3]). Only 32_UINT, 32_SINT and 32_FLOAT (20-22) store the dword unchanged. Other formats convert it, and an 8- or 16-bit one writes 1 or 2 bytes of every 4-byte element, so a buffer fill would also overwrite the bytes in between. Such a dispatch now goes to the recompiler. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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
The dword pattern-fill kernel that #2081 runs as a buffer fill stores each pattern dword with
buffer_store_format_xthrough the V# inuser[0..3](e0102000in its code). The bytes that land in memory therefore depend on that descriptor's FORMAT field (user[3]bits 12-18). Only32_UINT,32_SINTand32_FLOAT(20, 21, 22) store the dword unchanged. Any other format converts the value first. An 8- or 16-bit format also writes only 1 or 2 bytes of each 4-byte element (the kernel requires stride 4), so the buffer fill would overwrite the bytes in between.MatchDwordPatternFillchecked stride, swizzle,add_tidand type, but not FORMAT.It now also requires FORMAT 20-22. Every other format leaves the dispatch to the recompiler. The 16-byte fill kernel (
matchesFillKernel, FORMAT0x4b) and the pattern-fill kernel (MatchesPatternFillKernel, exactuser[3]) already check the format.Format numbers:
IrBufferFormatinBufferFormat.hpp(Format32UInt = 20..Format32Float = 22), the GFX10 buffer format table. Store semantics: RDNA 2 ISA, MUBUFBUFFER_STORE_FORMAT_X("untyped buffer store 1 dword with format conversion").Tested
Head
4309bffdbonmaind592d54e1.agc_driver_dword_pattern_fillmatch checks: formats 21 and 22 match, as format 20 already did. 5 (8_UINT), 11 (16_UINT), 13 (16_FLOAT), 27 (16_16_UINT), 39 (10_11_11_USCALED) and 75 (32_32_32_32_UINT) don't. The execution cases are unchanged; they all use format 20.agc_driver_dword_pattern_fillincluded. Windows passes 973 of 973, with the GPU tests skipped for lack of a device.agc_driver_dword_pattern_fillandagc_driver_oversized_dispatchpass, with test binaries built on a second Windows 11 machine (MinGW GCC 15.2.0, Release). On that machine the non-GPU tests pass 618 of 619.log_macrosfails there on every branch and passes in CI.tools/check_conventions.py --base origin/mainpasses.Checklist
main; no other open PR implements the same functionsNotImplemented_nid_no_patch); silent stubs are listed in TechnicalDebt.mdfiles or images added to the repository (attach them to this PR)🤖 Generated with Claude Code