[AIROCMLIR-1077] Fix intermittent f32 attention tuning verification false-fail in Tune rocMLIR#2431
Draft
bogdan-petkovic wants to merge 2 commits into
Draft
[AIROCMLIR-1077] Fix intermittent f32 attention tuning verification false-fail in Tune rocMLIR#2431bogdan-petkovic wants to merge 2 commits into
bogdan-petkovic wants to merge 2 commits into
Conversation
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.
Motivation
The weekly
Tune rocMLIRstage (tuningRunner.py --op attention) intermittently fails f32 attention configs on gfx90a and gfx942 during CPU verification. The verifier reports[1 1 0]: only the relDiff check fails while RMS and absDiff pass. The GPU output is numerically sound — the failure is a benign accumulation-order divergence between the GPU flash / online-softmax reduction and the sequential CPU reference, which the strictrelDiff_threshold=1e-4over-penalizes on a small fraction of elements. It surfaces intermittently because tuningRunner verifies only the fastest (winning) perf_config per problem, and that winner varies by architecture and from run to run.The goal of this PR is to stop these false-fails without weakening real regression detection.
Technical Details
Root cause:
tuningRunner.py's CPU verification emits-pv -relDiff_threshold=0.0001 -RMS_threshold=0.15uniformly for every op. For f32 attention, a small fraction of output elements (~0.05–0.45%) exceed the 1e-4 relDiff threshold (observed maxRelDiff ranged from ~1.6e-3 up to ~1.5e-2) while RMS and average relDiff stay ~1e-3 or better. This is benign: the GPU computes genuine f32 throughout (amdgpu.mfma ... : f32, f32, vector<4xf32>,softmaxType = f32, no f16/bf16 downcast), and re-running the exact failing config with a relaxed relDiff yields[1 1 1]with identical GPU output. rocmlir-gen already disables relDiff for f16/bf16 and i8 attention uses integer verification, so only f32 attention is affected.The verifier (
mcpuVerifyinmlir/lib/ExecutionEngine/conv-validation-wrappers.cpp) already supports an allclose-style gate: when-absDiff_thresholdis passed, relDiff is ignored for elements whose absolute difference is within tolerance, while RMS and absDiff still gate correctness. This mechanism is already used for f32 attention inmlir/utils/performance/parameterSweeps.pyandmlir/test/e2e/PrAttentionF32.toml, but it was never wired intotuningRunner.py.This PR adds
attention_cpu_verify_flags()intuningRunner.py, which appends-absDiff_threshold 5e-2for f32 attention CPU verification, invoked fromverify_perfconfig(user-supplied--rocmlir-gen-flagsstill take precedence). RMS (0.15) remains the primary correctness metric and absDiff still bounds gross per-element errors. The 5e-2 tolerance covers the largest observed benign divergence (~1.5e-2 on gfx90a) with margin, while a genuinely wrong element (abs error on the order of 0.1–1 for bounded attention output) still fails absDiff and RMS. Only f32 attention is affected; all other dtypes and ops are unchanged. Configs that previously passed had maxAbsDiff ~1e-4 (implied by the strict relDiff), so they remain passing.Affected configs reproduced during investigation (all f32, transK=true, split_kv=1):
g=8 seq_len=14400 head_dim=40with perf_configattn:v3:32,96,192,4,32,48,16,4,1,1,1,0,1on gfx942;g=8 seq_len=3600 head_dim=80with perf_configattn:v3:64,64,48,4,16,48,16,4,1,2,1,2,1on gfx942; andg=1 seq_len=14400 head_dim=512with perf_configattn:v3:64,64,48,16,16,48,16,4,1,1,2,0,1on gfx90a.Test Plan
pytest mlir/utils/performance/tests/test_tuningRunner.py, including 4 new tests forattention_cpu_verify_flags(f32 attention gets the gate; f16/bf16/i8 and non-attention ops do not; gpu/none verify modes do not).flake8(with the CI ignore list) andyapf --diffon the changed files.rocmlir-gen | rocmlir-driver -c | mlir-runner) on gfx942 (MI300X) for the failing configs, comparing the strict threshold against the new absDiff gate.tuningRunner.py --op attentionon a previously failing f32 config, confirming the emitted verification command and the tuning outcome.Test Result
-t f32 ... -g 8 -seq_len_q 3600 -seq_len_k 3600 -head_dim_qk 80 -head_dim_v 80(gfx942):Tuning completed successfully. The generated verification command included-absDiff_threshold 5e-2, and the winning perf_configattn:v3:64,64,48,4,16,48,16,4,1,2,1,2,1(the exact config that fails in CI) passed, producing a valid tuning DB entry.seq_len=14400 head_dim=40perf_configattn:v3:32,96,192,4,32,48,16,4,1,1,1,0,1, andseq_len=3600 head_dim=80) return[1 1 1]with the gate; they return[1 1 0]with the previous strict threshold. The gfx90a config (head_dim=512) is not runnable on gfx942 hardware but is covered by the same mechanism (observed abs diff ~1.5e-2 < 5e-2).Submission Checklist