Skip to content

Federate the six rocprof-compute skills - #285

Draft
feizheng10 wants to merge 7 commits into
mainfrom
users/feizheng10/federate-rocprof-compute-skills
Draft

feizheng10 wants to merge 7 commits into
mainfrom
users/feizheng10/federate-rocprof-compute-skills

Conversation

@feizheng10

Copy link
Copy Markdown
Collaborator

Summary

  • Register the six user-facing rocprofiler-compute skills on the existing ROCm/rocm-systems develop source. The projects/rocprofiler-compute approval is already in .github/skill_owners.json.
  • Vendor the generated skill directories from develop at f2b844211d55. Catalog names match the upstream folders, so no as aliases are used.
  • rocprof-compute-pc-sampling profiles with rocprof-compute. rocprofiler-pc-sampling drives rocprofv3 directly. Both can be vendored; they should not be treated as the same skill when a routing room contains both.

Readiness follow-up

Linux/MI300 runner metadata, explicit ROCm prerequisites, the gfx950 memory-analysis links, the rocprofv3 routing boundary, and structural Skillscope CI are in ROCm/rocm-systems#14099. That pull request needs review before it can reach develop. After it merges, the nightly federation bump brings those files into this catalog. This machine has no supported accelerator (rocprof-compute --specs reports no supported arch), so behavioral grading was not run here.

Test plan

  • uv run .github/scripts/federate_skills.py --check-catalog
  • ./.github/scripts/check.sh
  • Confirm the six generated directories and that documentation links were rewritten to the pinned develop commit
  • Routing across the six skills and rocprofiler-pc-sampling
  • Behavioral grading on a supported Instinct GPU after evals/machine.yml lands from the upstream pull request
  • Do not edit marketplace manifests in this pull request

Made with Cursor

The rocprofiler-compute project is already approved, and these skills stay owned on that repository's develop branch.

Co-authored-by: Cursor <cursoragent@cursor.com>
feizheng10 and others added 6 commits October 26, 2026 14:16
develop does not have those eval changes yet, so this import uses that pull request's head and keeps each skill's machine.yml here, where skillscope selects the MI300 runner.

Co-authored-by: Cursor <cursoragent@cursor.com>
Federation copies skill folders only, so ../../sample does not exist here. A fixture entry copies that tree once and retargets the vendored workspace paths.

Co-authored-by: Cursor <cursoragent@cursor.com>
…6c2.

develop does not have that pull request yet, so the skills and shared sample fixture are imported from its head while each skill keeps its machine.yml for MI300 runner selection.

Co-authored-by: Cursor <cursoragent@cursor.com>
The sample fixture copied the whole upstream sample tree (64 files), but the
six skills' eval workspaces and prompts only name nine root sources, the
gl2_backpressure case under membw_analysis_test_suite, and the
wmma_gemm_fp16 build. mega_kernel, conjugate_gradient, dynamic_shared, the
other membw cases, and the remaining root samples were never referenced.

A fixture now declares the files to vendor, and the importer copies, hashes,
and checks only those: the referenced sources, common.h (included by
vmem/occupancy/lds and wmma main.cpp), and the wmma_gemm_fp16 Makefile and
headers it needs to build. Workspace paths and the ../../sample rewrite are
unchanged, so every workspace still resolves to an existing directory.
Re-running the import against 7a1a96c2 reproduces the same 15 files and
reports the fixture as up to date.

Co-authored-by: Cursor <cursoragent@cursor.com>
The shared install section is gone, and each skill still keeps its MI300 runner file.

Co-authored-by: Cursor <cursoragent@cursor.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant