Repository navigation
Conversation
Merged
6 of 11 tasks
…nstead of failing enable_hipcc defaults to false, so an ordinary -Denable_hip=true build compiles the HIP host code but no device kernels. meson_options.txt documents that posture as reporting -ENOSYS, and every HIP parity test turns -ENOSYS into a skip. Four of them failed instead, for two independent reasons. float_vif_hip.c and integer_psnr_hvs_hip.c wrote their scaffold path as a call to vmaf_hip_kernel_submit_pre_launch() with a NULL readback buffer, returning its error before falling through to -ENOSYS. Rejecting a NULL rb is that helper's first statement, so the call always returned -EINVAL and the -ENOSYS after it was unreachable. The call did nothing else, so it is gone. test_hip_speed_singular_parity.c recognised -ENOSYS only at the vmaf_use_feature() site. speed_temporal_hip reports it from extract(), which surfaces through vmaf_read_pictures(): registration succeeds because only extract() knows there is no kernel. The file header already claimed the same skip contract as test_hip_speed_temporal_parity.c, which has always checked both sites; now this one does too. Diagnosed by tagging every 'return -E*' in the read path and the HIP runtime, which named core/src/hip/kernel_template.c's 'lc == NULL || rb == NULL' guard, and by printing the speed test's own error, which was -38. Default HIP fast suite goes from 173 ok / 4 fail to 177 ok / 0 fail, each of the four printing an explicit skip marker. With -Denable_hipcc=true the same four run against real gfx1036 kernels and pass: 183 ok / 0 fail.
lusoris
force-pushed
the
fix/hip-scaffold-enosys
branch
from
September 19, 2026 20:40
9bb3204 to
a5a9ec6
Compare
12 of 13 tasks
Contributor
Author
|
Absorbed into the integration train #1506, folded unchanged except where that PR's description says otherwise. This PR was green on its own; it and its three siblings kept knocking each other into conflict on |
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.
Summary
On an ordinary
-Denable_hip=truebuild, four HIP parity tests failed where they were meant to skip.master(551d35a63) on ROCm 7.2.4 / gfx1036: 173 ok, 4 fail.enable_hipccdefaults to false, so that build compiles the HIP host code but no device kernels.core/meson_options.txtdocuments the posture — extractors "fall back to-ENOSYS" — and every HIP parity test turns-ENOSYSinto[skip: …]and passes. Two independent things broke that.The extractor side
float_vif_hip.candinteger_psnr_hvs_hip.cwrote their scaffold path as:The call passes
rb == NULL, and rejecting a NULLrbis that helper's first statement, so it always returned-EINVALand the-ENOSYSbelow was dead code. The extractor reported "invalid argument" where the contract promises "not implemented", the tests' skip branch never matched, and they failed. The call did nothing else — it returned before touching anything — so it is gone.The test side
speed_temporal_hipreturns-ENOSYScorrectly, but fromextract(), which surfaces throughvmaf_read_pictures(): registration succeeds because onlyextract()knows there is no kernel.test_hip_speed_singular_parity.cchecked-ENOSYSonly at thevmaf_use_feature()site. Its own file header already claimed "the same skip contract astest_hip_speed_temporal_parity.c", and that sibling has always checked both sites — this one just never implemented the second.How it was found
Not by inspection.
AMD_LOG_LEVEL=1showed no HIP API error, and the extractor's own six-EINVALguards all log at ERROR and printed nothing atVMAF_LOG_LEVEL_DEBUG. Tagging everyreturn -E*in the read path and the HIP runtime with its__LINE__named the source in one run:core/src/hip/kernel_template.c, thelc == NULL || rb == NULLguard. The speed test's own error printed as-38, i.e.-ENOSYS— which is what pointed at the test rather than the extractor.Verification
Both configurations, because a fix that makes tests skip has to be shown not to be hiding a real failure.
-Denable_hip=true(default, no kernels)-Denable_hip=true -Denable_hipcc=true(real gfx1036 kernels)The four now print explicitly what they did:
and with
enable_hipcc=truethe same four run against real kernels and pass, so the skip is a genuine "not built", not a silenced failure. Both edits are inside#ifndef HAVE_HIPCC/ anerr == -ENOSYSbranch, so they are inert once kernels exist — the real-kernel run confirms that rather than asserting it.The remaining
test_hip_adm_parityunexpected pass and two expected fails in the real-kernel run are the staleshould_failmarkers PR #1493 removes, not this change.praetorctl auditpasses and the baseline tightens 1433 → 1415: deleting the dead call removed 18 findings. Re-recorded from a clean clone, branch verified.mkdocs build --strictexits 0;check-state-md-rowsOK.Type
fix— bug fixChecklist
make formatis green; pre-push hooks pass.assertAlmostEqual(...)score in the Netflix golden Python tests.docs/state.md: rowT-HIP-SCAFFOLD-ENOSYS-MASKED-2026-09-19added as closed.Deep-dive deliverables (ADR-0108)
## Alternatives considered, four options including relaxing the helper's NULL guard and marking the testsshould_fail.AGENTS.mdinvariant note —core/src/feature/hip/AGENTS.md, plusdocs/rebase-notes.md.changelog.d/fixed/hip-scaffold-enosys.md.docs/rebase-notes.md.Reproducer
Rebase hazard
Both shapes come back easily, and
docs/rebase-notes.mdpluscore/src/feature/hip/AGENTS.mdname them: a scaffold path returns-ENOSYSdirectly and never calls a kernel-submit helper with placeholder arguments, and a HIP parity test checks-ENOSYSat bothvmaf_use_feature()andvmaf_read_pictures(). Do not relax the helper's NULLrbguard to accommodate the old call — roughly twenty real callers depend on it.