fix(ck): build gfx1250-only conv instances only for gfx1250 by afagaj · Pull Request #12883 · ROCm/rocm-libraries

afagaj · 2026-10-01T22:27:07Z

Fixes AICK-2468. Unblocks ALMIOPEN-2820.

Problem

Any build combining gfx1250 with another target fails at link:

ld.lld: error: local memory (131552) exceeds limit (65536) in function
'kernel_grouped_conv_fwd_grouped_gemm_wmma_cshuffle_v3'

Reproduced locally at bc47ae72ea8: 108 local memory errors and 13 static assertion failed
across 5 objects, LDS 65648..197104 B against a 65536 B limit. All ten distinct LDS sizes
match MIOpen develop nightly #1589. Nightlies #1589-#1592 are red.

Root cause

The gfx1250 grouped-conv instances added in #10620 are gated on CK_USE_GFX1250, which
CMakeLists.txt:511 defines globally when the target list contains gfx1250. HIP compiles
each TU once per --offload-arch, so every device pass sees the same preprocessor state, and
the kernel bodies are guarded only by __gfx11__ || __gfx12__ — true on gfx1101/gfx1151. A host
macro cannot express "this offload architecture", so tiles sized for the 320 KB LDS of gfx1250
are emitted for 64 KB parts.

Not caught by CI because no job anywhere builds gfx1250 next to another family: ck.groovy:1492
(the only multi-arch CK configure) omitted gfx1250, and TheRock GHA builds one family per job.

Change

Move every gfx1250-exclusive instance list into dedicated *_gfx1250*.cpp TUs, and compile those
TUs only for gfx1250. Every other instance TU keeps exactly the architectures it has on develop.

Restricting a TU to gfx1250 needs `--no-offload-arch`

CK's per-source filter in library/src/tensor_operation_instance/gpu/CMakeLists.txt sets
--offload-arch= flags on each TU via set_source_files_properties. Those flags are additive.

CMakeLists.txt:361-365 unsets GPU_TARGETS before find_package(hip) only when the caller
used GPU_ARCHS. When the caller sets GPU_TARGETS instead, hip::device injects
--offload-arch for every target globally, and the per-source flags are appended afterwards —
so they can only widen the arch set, never narrow it.

CK CI uses GPU_ARCHS (ck.groovy:1492) → the filter works.
MIOpen uses GPU_TARGETS (Dockerfile:425) → the filter has no effect.

Same TU, clang 24 and clang 22:

--offload-arch=gfx1101 --offload-arch=gfx1250                            -> local memory (131552) exceeds limit (65536)
--offload-arch=gfx1101 --offload-arch=gfx1250 --no-offload-arch=gfx1101  -> exit 0

What the PR does

Restricts _gfx1250 sources with --no-offload-arch=all. For those sources only,
add_instance_library emits --no-offload-arch=all followed by their gfx1250 targets. =all also
clears archs hip::device took from GPU auto-detection or a stale CMake cache, which no explicit
exclusion list can see. Every other source's flags are unchanged from develop.
Drops _gfx1250 sources when gfx1250 is not targeted. The filter matches the file name, not
the full path: generate_sharded_instantiations produces absolute paths, so matching the path
would restrict every shard whenever the build directory contains gfx1250.
Gates registrations on a macro consumers can see. The instance-factory headers
(grouped_convolution_*.hpp, gemm_universal.hpp and their .inc files) are installed, so their
guards are compiled by downstream consumers. Each gfx1250 registration sits under
CK_HAS_GFX1250_INSTANCES, exported through config.h.in and set only when the gfx1250 TUs are
built. CK_USE_GFX1250 cannot serve: it is build-local, and exporting it would make the host and
device halves of CK_ENABLE_CLUSTER_LAUNCH (ck/ck.hpp:205) disagree.
Checks the device at run time inside each gfx1250 add_ function with
ck::is_gfx125_supported(), as …_data_cache_prefetch_instance.cpp already does. A
gfx1200;gfx1250 build contains the gfx1250 TUs but no gfx1200 code object for them, so they must
not register on a gfx1200 card.
Keeps gfx1250-only objects in MIOpen's per-arch unbundler (MIOPEN_CK_UNBUNDLE_PER_ARCH=ON,
projects/miopen/cmake/unbundle_archive.cmake): an object with no code for the arch is kept
rather than dropped, and an object that thinning would not shrink is kept rather than failing.
Restricting the XDL pipev1 TUs to gfx1250 also removes the gfx9 wave64 offload passes, which
is where the threadwise_tensor_slice_transfer_v6r1.hpp:60 CShuffle static_assert fires — so
that object builds too.
Fails safe if an oversized WMMA conv tile ever reaches a small-LDS architecture again. The four
WMMA conv kernels (fwd, fwd large-tensor, bwd-data, bwd-weight) place their __shared__ array and
body inside if constexpr(LDS_size <= get_lds_size(get_device_arch())), so such a tile compiles to
an empty kernel on that architecture instead of failing the device link. The host side matches:
GridwiseGemm_wmma_cshuffle_v3_base::CheckValidity rejects an instance whose LDS footprint exceeds
the running device's, so an emptied kernel is never selected. Device code for every tile that fits
is unchanged. This is a second barrier, independent of the _gfx1250 file split and CMake flags.
Design by Enrico Degregori (co-author of that commit).

All 13 gfx1250 entry points carry a _gfx1250 token, so git grep 'add_device_.*gfx1250' audits
the set.

Test Plan / Test Results

Built locally against TheRock 10.2.0a20260929 (AMD clang 24.0.0git),
32-core host, gfx1151 GPU. This PR (7d4e581998e) against develop — bc47ae72ea8 (where the failure was reproduced) for
Test A; the merge base df07597821b for Test E — with an identical configure:
GPU_TARGETS="gfx908;gfx90a;gfx942;gfx950;gfx1101;gfx1151;gfx1250;gfx1250-strict" — GPU_TARGETS
rather than GPU_ARCHS is required to reproduce, for the reason given under Change.

	develop `bc47ae72ea8`	this PR
`local memory` errors	108	0
`static assertion failed`	13	0
failing objects	5 of 5	0

All ten distinct develop LDS sizes match MIOpen develop nightly #1589.

Test A — the five failing objects (as split here) plus their two base siblings, ninja -k 0: exit 0, counts above.
Test B / C — gfx1250;gfx1250-strict: 13 gfx1250 TUs, each built for exactly those two. gfx1101;gfx1151: 0 gfx1250 TUs, base TUs kept.
Test D — a consumer of the installed headers sees the gfx1250 registrations: 6 conv, 4 gemm.
Test E — configure-only, 10 target configurations (MIOpen's list, no targets, gfx90a + FP8, gfx942;gfx1100, gfx90a;gfx1030, …): every non-gfx1250 instance TU gets exactly develop's arch flags; all configure cleanly.
Test F — stale build dir and auto-detected GPU: no foreign arch reaches the gfx1250 tile TU; it compiles with 0 LDS errors.
Test G — on the gfx1151, a gfx1250 add_ function registers 0 ops.
Test H — MIOpen's per-arch unbundler keeps every CK object for gfx942, gfx1151 and gfx1250.
LDS safety net (before 408ed62b668 / after 7d4e581998e):
- Test J — the three gfx1250 tile TUs compiled for gfx1151 on purpose: link failed (131552–197104 B > 65536) → links, oversized kernels emptied.
- Test K — device code where tiles fit is byte-identical in 27 builds: those TUs on gfx1250, three normal conv TUs on gfx1151 and gfx1250, and one TU from each of the 18 WMMA families that have library instances.
- Test L — on the gfx1151, a gfx1250 tile that does not fit 64 KB was accepted by IsSupportedArgument → rejected ("Instance tile too large for LDS size of target device!"); 10 regular instances still accepted.
- Test M — all 18 WMMA families compile.
clang-format-18 clean.

Logs, scripts, repro commands and per-configuration detail:
https://gist.github.com/afagaj/fe34335e1f1ea4baf85d11dedddab531

Limits. No gfx9 or gfx1250 GPU here, so numerical correctness on gfx1250 still needs CI or real
hardware. Test A rebuilt 7 of the ~190 objects in these three libraries; Test E checks every instance
TU's flags but compiles nothing; Test K compares device code, not runtime behaviour — please run the full multi-arch
build in CI before merging.

🤖 Generated with Claude Code

Building CK for gfx1250 together with any gfx11 target fails at link: ld.lld: error: local memory (131552) exceeds limit (65536) in function 'kernel_grouped_conv_fwd_grouped_gemm_wmma_cshuffle_v3' 152 such errors across 5 objects, LDS 65648..197104 B against a 65536 B limit. Root cause: the gfx1250 grouped-conv instances added in #10620 are gated on CK_USE_GFX1250, a host-side macro that CMakeLists.txt defines globally whenever the target list contains gfx1250. HIP compiles each TU once per --offload-arch, so the preprocessor state is identical for every device pass; the kernel bodies are guarded only by `__gfx11__ || __gfx12__`, which is true on gfx1101/gfx1151. A host macro cannot express "this offload architecture", so tiles sized for the 320 KB LDS of gfx1250 are emitted for 64 KB parts. Move those instances into dedicated *_gfx1250*.cpp translation units and restrict them to --offload-arch=gfx1250* with the existing per-source filter in library/src/tensor_operation_instance/gpu/CMakeLists.txt (same mechanism already used to confine gemm_wmma_universal f8 to gfx12). CK_USE_GFX1250 is retained only on the host-side declarations and calls, where "this build includes gfx1250" is what it actually means. Also restores two bf16 bwd_weight instances that `#ifndef CK_USE_GFX1250` silently removed from gfx11 builds, and adds gfx1250 to the multi-arch Jenkins build that would have caught this. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

therock-pr-bot · 2026-10-01T22:29:09Z

✅ All Checks Passed — Ready for Review

Check	Status	Details
📝 PR Description	✅ Pass	—
⛔ Forbidden Files	✅ Pass	—
🧪 Unit Test	⚠️ Warning	Error: Source/code files changed without an accompanying unit test. Expected: add at least one test file named like `test_<name>.py` / `test_<name>.cpp` (or `<name>_test.`). Current:* code file(s) changed: `projects/composablekernel/include/ck/tensor_operation/gpu/device/impl/device_gemm_multiple_d_wmma_cshuffle_v3.hpp`, `projects/composablekernel/include/ck/tensor_operation/gpu/device/impl/device_grouped_conv_bwd_data_multiple_d_wmma_cshuffle_v3.hpp`, `projects/composablekernel/include/ck/tensor_operation/gpu/device/impl/device_grouped_conv_bwd_weight_wmma_cshuffle_v3.hpp`, `projects/composablekernel/include/ck/tensor_operation/gpu/device/impl/device_grouped_conv_fwd_multiple_abd_wmma_cshuffle_v3.hpp`, `projects/composablekernel/include/ck/tensor_operation/gpu/device/impl/device_grouped_conv_fwd_multiple_d_wmma_cshuffle_v3_large_tensor.hpp` (+27 more); no test file found
🔎 pre-commit	✅ Pass	—
🚫 Draft PR	🔜 To Be Enabled	—
🚩 Feature Flag	🔜 To Be Enabled	—
📊 Code Coverage	🔜 To Be Enabled	—
🤖 therock-pr-bot	✅ Pass	—

🎉 All checks passed! This PR is ready for review.

📖 Need help? See the Policy FAQ for details on every check and how to fix failures.

🙋 Wish to Override Policy?

therock-pr-bot · 2026-10-01T22:29:12Z

🎉 All checks passed! This PR is ready for review.

…e, real CI wiring Review of the first commit found three blockers; all fixed here. 1. The Jenkinsfile edit was a no-op. `execute_args` is never read by any groovy code; `ck.runBuildInstancesOnly` supplies its own hardcoded arch list at ck.groovy:1492. Reverted the Jenkinsfile and added gfx1250 where the list is actually consumed. 2. Removing `#ifndef CK_USE_GFX1250` from the bwd_weight WMMA list was wrong. That guard was a K-granularity exclusion, not an LDS one: the two instances it covers are the only ones with KPerBlock=48, and gridwise_gemm_wmma_cshuffle_v3.hpp:617 rejects KPerBlock % (KPerWmmaBlk * 2) != 0 on gfx12 (48 % 32 = 16). Restored the guard with a comment explaining why it exists. 3. The XDL large_k list was left behind at 196608 B of LDS -- the largest offender in the original incident, and the fifth failing object. Its two pipev1 TUs are now gfx1250-only, which also removes the gfx9 wave64 offload passes where the CShuffle static_assert fires. Also from review: - Export CK_USE_GFX1250 via config.h.in. It was only an add_definitions(), so every new guard in an installed public header compiled to off for downstream consumers, silently dropping all gfx1250 instances for MIOpen. - Gate the factory calls on ck::is_gfx1250_supported() as well as the macro. A gfx1200;gfx1250 build defines the macro but carries no gfx1200 code object for these TUs, which would fail at launch with hipErrorNoBinaryForGpu. - Match the CMake filter against the full source path with a (^|[_/]) boundary. - Use SUPPORTED_GPU_TARGETS, not GPU_TARGETS, for the -mllvm scheduler flags; GPU_TARGETS is empty in a GPU_ARCHS build. - Give all 13 gfx1250 entry points a _gfx1250 token so one grep audits them. - clang-format 18.1.3 clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

afagaj · 2026-10-01T23:54:21Z

Code review pass — 15 findings, 11 addressed in `f22a696`

Ran an adversarial review over the first revision. It found three blockers; the PR
as originally pushed would not have fixed the build. Fixed in place rather than
reopening, so most findings no longer apply to the current head.

Blockers (fixed)

#	Finding	Resolution
1	The `Jenkinsfile:728` change was a no-op — `execute_args` is never read by any groovy code, and `ck.runBuildInstancesOnly` supplies its own hardcoded list.	Jenkinsfile reverted; gfx1250 added at `ck.groovy:1492` where the list is consumed.
2	Deleting `#ifndef CK_USE_GFX1250` from the bwd_weight WMMA list re-enabled two instances that gfx1250 rejects. It was a K-granularity exclusion, not an LDS one: those two are the only `KPerBlock = 48` rows, and `gridwise_gemm_wmma_cshuffle_v3.hpp:617` rejects `KPerBlock % (KPerWmmaBlk * 2) != 0` on gfx12 (`48 % 32 = 16`).	Guard restored, with a comment stating why it exists.
3	The XDL `large_k` list — 196608 B, the largest offender in the incident and the fifth failing object — was left in shared TUs. Declared out of scope on the false premise that XDL tiles fit in 64 KB.	Its two `pipev1` TUs are now gfx1250-only. This also removes the gfx9 wave64 passes where the `threadwise_tensor_slice_transfer_v6r1.hpp:60` `static_assert` fires.

Also fixed

CK_USE_GFX1250 was only an add_definitions(), absent from config.h.in — so every new guard in an installed public header compiled to off for MIOpen, shipping the gfx1250 instances in the archive and never registering them. Now exported via #cmakedefine.
A gfx1200;gfx1250 build defines the macro but carries no gfx1200 code object for these TUs → hipErrorNoBinaryForGpu at launch. Factory calls now also test ck::is_gfx1250_supported().
CMake filter matched the basename only; now matches the full source path with a (^|[_/]) boundary, so a directory-based layout is covered.
-mllvm scheduler flags were keyed on GPU_TARGETS, which is empty in a GPU_ARCHS build. Now SUPPORTED_GPU_TARGETS.
Two entry points kept non-_gfx1250 names, so an audit grep missed them. All 13 now carry the token.
clang-format 18.1.3 clean (3 files reformatted).

Deliberate, called out

device_grouped_conv2d_bwd_data_xdl_v3_..._bf16_gfx1250_instance.cpp pre-dates this PR and is narrowed to gfx1250 by the new filter. That is intended — it is a gfx1250-only instance list — and its call site is guarded accordingly.

Open, deferred to follow-ups

Three CK_USE_GFX1250-gated lists remain in shared TUs (device_grouped_conv_fwd_xdl_instance.hpp:126, device_exp_gemm_wmma_universal_km_kn_mn_instance.hpp:105, gemm_universal.hpp:489). Same anti-pattern; none exceeds 64 KB so none breaks the build. Listed in the description.
The four new gfx1250 lists omit the #ifndef ONE_INSTANCE_PER_LIST tail-trim that sibling lists carry, so that compile-time-reduction knob still instantiates the largest kernels.
//clang-format on (missing space) is a pre-existing typo in device_grouped_conv_bwd_weight_v3_wmma_instance.hpp; the new blocks match the file's existing spelling rather than introducing a large reformat.

Checked clean

Preprocessor nesting in all touched files; CMake NOT ... AND ... precedence; INST_TARGETS cannot be emptied by the new filter and is re-set() per iteration; no instance row duplicated between a base list and its gfx1250 sibling; row counts conserved across all five splits; template parameter lists match the aliases they were split from; declarations byte-match definitions; ConvSpec coverage preserved; no stale references to renamed lists or files; gfx1250-strict swept in by the regex is correct (CMakeLists.txt:207 maps it to the same 0x1250 device id, hence the same 320 KB LDS).

Still not compiled locally — no multi-arch toolchain available. CI remains the real check.

…ally binds Per-source --offload-arch flags are additive. When the caller sets GPU_TARGETS (rather than GPU_ARCHS) CMakeLists.txt:361-365 does not unset it before find_package(hip), so hip::device injects --offload-arch for every target globally and the per-source filtering in add_instance_library can only widen, never narrow. Emit --no-offload-arch for the excluded targets instead. Verified: a 131552-byte __shared__ built for gfx1101+gfx1250 fails, and succeeds with --no-offload-arch=gfx1101. Also from review: revert the filter to source_name (generate_sharded_instantiations appends absolute paths, so a build dir containing gfx1250 matched every shard); drop the config.h.in export of CK_USE_GFX1250 (it desynced CK_ENABLE_CLUSTER_LAUNCH, ck.hpp:205); use the pre-existing is_gfx125_supported() instead of a duplicate predicate; skip a TU whose target list is empty rather than compiling it for the default arch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The instance-factory headers (grouped_convolution_*.hpp and their .inc files) are installed, and this PR guarded their gfx1250 registrations with CK_USE_GFX1250. That macro is only an add_definitions() flag on CK's own build; it is not in config.h, so a downstream consumer compiling against the installed headers never sees it and every gfx1250 registration compiles out. Preprocessing grouped_convolution_forward.hpp as a consumer: 0 gfx1250 registration calls survive with the old guard, 6 with the new one. CK_USE_GFX1250 itself cannot be exported: ck/ck.hpp:205 keys the host half of CK_ENABLE_CLUSTER_LAUNCH on it and the device half on __gfx125__, so exporting it would desynchronise the two on every non-gfx1250 offload pass. Add CK_HAS_GFX1250_INSTANCES, set alongside CK_USE_GFX1250 and exported through config.h.in, meaning only "this CK build contains the gfx1250 instance TUs". Swap all 26 registration guards this PR added to it. The runtime is_gfx125_supported() check is unchanged. CK_USE_GFX1250 and CK_ENABLE_CLUSTER_LAUNCH are untouched. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

The stage runs only from the nightly cron, uses the standard CK image (gfx1250 stages use a separate image and compiler), and configures with GPU_ARCHS rather than the GPU_TARGETS path MIOpen uses. CI coverage for gfx1250 alongside other targets belongs in its own change. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

The empty-target skip and the --no-offload-arch subtraction in add_instance_library applied to every instance source. That changed the arch set of hundreds of unrelated TUs and broke configurations that worked before: configure failures with no GPU_TARGETS or with CK_USE_FP8_ON_UNSUPPORTED_ARCH=ON, dropped WMMA f8 TUs for gfx942;gfx1100, FP8 gemm TUs losing gfx90a, WMMA/XDL TUs losing archs that host code still queries ("invalid device function"), and MIOpen per-arch unbundling dropping objects. Only _gfx1250 sources are now restricted, by --no-offload-arch=all followed by their gfx1250 targets. =all also clears archs hip::device injected from auto-detection or a stale cache, which an explicit subtraction list could not see. Every other source's flags are identical to develop's. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

The extra compile options are set on _gfx1250 sources only, and add_instance_library already drops those sources when gfx1250 is not targeted, so the surrounding if(SUPPORTED_GPU_TARGETS MATCHES "gfx1250") re-derived a decision made elsewhere. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Each gfx1250 registration in the five installed grouped-conv factory headers was a 7-line block pairing #ifdef CK_HAS_GFX1250_INSTANCES with a runtime is_gfx125_supported() check, pasted 13 times, and evaluated the device query once per call site on every GetInstances(). Move the runtime check into the 13 add_..._gfx1250_instances() functions, as ..._data_cache_prefetch_instance.cpp already does. The headers keep only the compile-time guard and no longer include device_prop.hpp or make HIP runtime calls. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

gemm_universal.hpp and gemm_universal_xdl.inc are installed, but gated the gfx1250 v3 prefetch instances on CK_USE_GFX1250, which is only an add_definitions() flag on CK's own build. A consumer compiling against the installed headers never saw those registrations. The backing TU is built for every XDL target and checks is_gfx125_supported() internally. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

…o choice The comment on the retained #ifndef CK_USE_GFX1250 in the bf16 bwd-weight WMMA list said the two KPerBlock=48 instances stay available on gfx1100-gfx1201 and cited a line that is a closing brace. CK_USE_GFX1250 is build-wide, so in any build that includes gfx1250 the rows are removed for every architecture (preprocessing the gfx1101 device pass: 0 rows with the macro, 2 without). State what the guard actually does; behaviour is unchanged. Also record why CK_HAS_GFX1250_INSTANCES is not CK_GFX1250_SUPPORT: the ctypes dispatcher undefines and redefines the latter per target architecture. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

CK now builds some instance objects for gfx1250 only. With MIOPEN_CK_UNBUNDLE_PER_ARCH=ON, unbundle_archive.cmake mishandled them in two ways: - An object with no device code for ARCH was dropped entirely, host code included, so the per-arch CK plugin failed to dlopen with undefined add_device_*gfx1250* symbols. - For ARCH=gfx1250, the thin fatbin of a gfx1250;gfx1250-strict object came out larger than the original and the script stopped with FATAL_ERROR. Keep such objects unchanged in both cases. The device code that rides along is never launched on another architecture; CK registers these instances only when is_gfx125_supported(). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Whitespace and line breaks only; the token stream is unchanged. CK's static-checks stage runs clang-format-18 over every .h/.hpp/.cpp and fails on any diff. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Add a second barrier against the AICK-2468 failure mode, independent of the _gfx1250 file split and CMake flags: a WMMA conv tile too large for an architecture's LDS now compiles to an empty kernel there and is rejected at run time, instead of failing the device link with "ld.lld: local memory (N) exceeds limit (65536)". - Device: the four WMMA conv kernels (fwd, fwd large-tensor, bwd-data, bwd-weight) place the __shared__ array and body inside if constexpr(LDS_size <= get_lds_size(get_device_arch())). - Host: GridwiseGemm_wmma_cshuffle_v3_base::CheckValidity rejects an instance whose GetSharedMemoryNumberOfByteOnHost() exceeds the running device's LDS, so an emptied kernel is never selected. The helpers it needs become __host__ __device__. Tiles that fit are unaffected: device code for them is byte-identical on gfx1151 and gfx1250. Borrowed from Enrico Degregori's users/enricodeg/ck/multi-arch-conv (ef12db1), without its instance-guard removals, XDL changes, KPerBlock checks or LdsTranspose rejection. Adds the device_prop.hpp include that gridwise_gemm_xdl_cshuffle_v3.hpp already has; without it the b_scale, ab_scale and blockscale WMMA instances fail to compile. Co-Authored-By: Enrico Degregori <enrico@streamhpc.com> Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

github-actions · 2026-10-28T00:38:05Z

This pull request has been inactive for 25 days and will be marked as stale.

If you would like to keep this PR open, please:

Add new commits
Add a comment explaining why it should remain open

This PR will be automatically closed in 5 days if no further activity occurs.

github-actions · 2026-11-03T00:31:06Z

This pull request has been automatically closed due to inactivity (30 days with no updates).

If you'd like to continue working on this, feel free to reopen the PR or create a new one.

afagaj requested review from a team as code owners October 1, 2026 22:27

github-actions Bot added project: composablekernel ck: convolution Used to tag composablekernel PRs that require approval from CK convolution review team. labels Oct 1, 2026

afagaj requested review from EnricoDeg, JonathanLichtnerAMD and illsilin October 1, 2026 22:34

assistant-librarian Bot added the organization: ROCm label Oct 1, 2026

afagaj marked this pull request as draft October 2, 2026 01:33

afagaj marked this pull request as ready for review October 2, 2026 05:08

afagaj changed the title ~~fix(ck): build gfx1250-only conv instances only for gfx1250 (AICK-2468)~~ fix(ck): build gfx1250-only conv instances only for gfx1250 Oct 2, 2026

afagaj marked this pull request as draft October 2, 2026 05:36

afagaj and others added 9 commits October 1, 2026 23:53

style(ck): clang-format-18 the files this PR changes

408ed62

Whitespace and line breaks only; the token stream is unchanged. CK's static-checks stage runs clang-format-18 over every .h/.hpp/.cpp and fails on any diff. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

github-actions Bot added the project: miopen label Oct 2, 2026

JonathanLichtnerAMD mentioned this pull request Oct 2, 2026

feat(miopen): re-add gfx1250 to the MIOpen dev image #12986

Merged

github-actions Bot added the Stale PR has no activity for 25+ days label Oct 28, 2026

github-actions Bot closed this Nov 3, 2026

Navigation Menu

Repository navigation

fix(ck): build gfx1250-only conv instances only for gfx1250 - #12883

fix(ck): build gfx1250-only conv instances only for gfx1250#12883
afagaj wants to merge 13 commits into
developfrom
users/afagaj/AICK-2468-gfx1250-instance-isolation

afagaj commented Oct 1, 2026 •

edited

Loading

Uh oh!

therock-pr-bot Bot commented Oct 1, 2026 •

edited

Loading

Uh oh!

therock-pr-bot Bot commented Oct 1, 2026

Uh oh!

afagaj commented Oct 1, 2026

Uh oh!

github-actions Bot commented Oct 28, 2026

Uh oh!

github-actions Bot commented Nov 3, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

afagaj commented Oct 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Root cause

Change

Restricting a TU to gfx1250 needs --no-offload-arch

What the PR does

Test Plan / Test Results

Uh oh!

therock-pr-bot Bot commented Oct 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ All Checks Passed — Ready for Review

Uh oh!

therock-pr-bot Bot commented Oct 1, 2026

Uh oh!

afagaj commented Oct 1, 2026

Code review pass — 15 findings, 11 addressed in f22a696

Blockers (fixed)

Also fixed

Deliberate, called out

Open, deferred to follow-ups

Checked clean

Uh oh!

github-actions Bot commented Oct 28, 2026

Uh oh!

github-actions Bot commented Nov 3, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

afagaj commented Oct 1, 2026 •

edited

Loading

Restricting a TU to gfx1250 needs `--no-offload-arch`

therock-pr-bot Bot commented Oct 1, 2026 •

edited

Loading

Code review pass — 15 findings, 11 addressed in `f22a696`