# Season of Commits 2026: Porting ROCm to gfx90c / gfx902 **URL:** \ **Category:** Season of Commits\ **Created:** [21 July 2026 19:50 UTC](https://forum.fossunited.org/t/season-of-commits-2026-porting-rocm-to-gfx90c-gfx902/8517 "2026-07-21T19:50:20Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![Soham\_Kulkarni](https://forum.fossunited.org/letter_avatar_proxy/v4/letter/s/a88e4f/32.png) [@Soham\_Kulkarni](https://forum.fossunited.org/u/Soham_Kulkarni)\ **Post date:** [21 July 2026 19:50 UTC](https://forum.fossunited.org/t/season-of-commits-2026-porting-rocm-to-gfx90c-gfx902/8517/1 "2026-07-21T19:50:20Z")
As discussed with @rahulporuri and @ansh I will be working on building a generalisable pipeline for enabling ROCm support on consumer GPUs. Mr. Bhooshan Agalgatti, Sr. Director at Nvidia is the industry mentor for this project. I will keep track of my progress with milestones in this thread. The entire process is being documented at my [Substack](https://netherquark.substack.com/) under CC-BY-SA 4.0, and any miscellaneous code I write (for benchmarking / plotting / etc.) will be provided under GPL-v3 at the project’s [GitHub](https://github.com/Netherquark/backrocm) repo. I wish to upstream all of my work, however if it is rejected (AMD intentionally doesn’t support these GPU targets), I plan to open source my work and create an automated CI/CD pipeline which will build and publish custom ROCm / PyTorch with my patches. I have already written 6 articles, hope you’ll enjoy them : ) ([#1](https://netherquark.substack.com/p/amd-vis-a-vis-gpus-1) [#2](https://netherquark.substack.com/p/amd-vis-a-vis-gpus-2) [#3](https://netherquark.substack.com/p/amd-vis-a-vis-gpus-3) [#4](https://netherquark.substack.com/p/amd-vis-a-vis-gpus-4) [#5](https://netherquark.substack.com/p/amd-vis-a-vis-gpus-5) [#6](https://netherquark.substack.com/p/amd-vis-a-vis-gpus-6)). **Completed milestones:** 1. Native ROCm 6.4.4 on gfx90c 2. HIP hello-world on gfx90c 3. GPU programming article serving as educational groundwork for the rest of the project. 4. gfx900 spoofing on gfx90c was tested successfully. 5. Spoofing benchmarks demonstrating that spoofing works, but is not production-grade. 6. rocm-examples subset benchmarked on gfx90c 7. Packaging/path issues with ROCm from Fedora were resolved to run benchmarks. **Latest completed milestone:** Failure analysis of benchmark results from running 113 tests from rocm-examples on gfx90c **Pending** 1. Compile rocm-examples from source and compare against Fedora-packaged binaries 2. Resolve each failing case for rocm-examples 3. Port gfx900-targeted assembly / kernels to gfx90c where needed 4. Write explainer articles for GPU internals — GPU assembly, Vega ISA, SGPRs, scratch, memory, scheduling, LDS, LLVM AMDGPU, etc. 5. Update rocBLAS library for gfx90c by adding the missing kernels 6. Generate Tensile data for gfx90c 7. Update any other incompatible libraries to add compatibility for gfx90c 8. Compile ROCm 6.4.4 with patched components and ensure native HIP execution on gfx90c 9. Port HIPify/runtime fixes for gfx90c 10. Benchmark real-world HIP workloads natively on gfx90c vs spoofing gfx900 11. Compare native gfx90c, Mojo, ZML, and other universal runtimes 12. Port PyTorch Docker images to gfx90c by modifying bundled ROCm 13. Port native PyTorch to gfx90c by modifying bundled ROCm 14. Repeat the full process on gfx902 15. Evaluate TheRock as a cleaner build path 16. Test whether bleeding edge ROCm 7.1 can be ported 17. CI/CD pipeline for automatic ROCm / PyTorch / Dockerized PyTorch builds I am trying to publish 2-3 articles a week, but due to the experimental nature, I get stuck sometimes. ---
**Author:** ![Soham\_Kulkarni](https://forum.fossunited.org/letter_avatar_proxy/v4/letter/s/a88e4f/32.png) [@Soham\_Kulkarni](https://forum.fossunited.org/u/Soham_Kulkarni)\ **Post date:** [14 August 2026 00:28 UTC](https://forum.fossunited.org/t/season-of-commits-2026-porting-rocm-to-gfx90c-gfx902/8517/2 "2026-08-14T00:28:40Z")
Oops didn’t give an update recently, my bad. Articles [#7](https://netherquark.substack.com/p/amd-vis-a-vis-gpus-7) [#8](https://netherquark.substack.com/p/amd-vis-a-vis-gpus-8) [#9](https://netherquark.substack.com/p/amd-vis-a-vis-gpus-9) up now. Recently presented this project to college faculty, [slides](https://github.com/Netherquark/backrocm/blob/main/docs/progress%20reports/IIP_CA1_Presentation_Soham_Kulkarni_23070126129.pdf) on the project GitHub. Article 7 through 9 focus more on the theoretical background for this project. Studying the ISA manual has been time consuming but I think I’ve got a good grasp of the memory/compute hierarchy, and I’m able to go through HIP assembly now. **Completed milestones:** - Port gfx900-targeted assembly / kernels to gfx90c where needed. - Write explainer articles for GPU internals — GPU assembly, Vega ISA, SGPRs, scratch, memory, scheduling, LDS, LLVM AMDGPU, etc. **Milestones in progress:** - Resolve each failing case for rocm-examples (Successfully ported 35/115 tests from rocm-examples) ![hip_basic_rpm_vs_source](https://forum.fossunited.org/uploads/default/original/2X/6/698e9afc3ad3d89bcc4eb75632602b7b4104b85c.png) **Pending milestones:** - Compile rocm-examples from source and compare against Fedora-packaged binaries - Update rocBLAS library for gfx90c by adding the missing kernels - Generate Tensile data for gfx90c - Update any other incompatible libraries to add compatibility for gfx90c - Compile ROCm 6.4.4 with patched components and ensure native HIP execution on gfx90c - Port HIPify/runtime fixes for gfx90c - Benchmark real-world HIP workloads natively on gfx90c vs spoofing gfx900 - Compare native gfx90c, Mojo, ZML, and other universal runtimes - Port PyTorch Docker images to gfx90c by modifying bundled ROCm - Port native PyTorch to gfx90c by modifying bundled ROCm - Repeat the full process on gfx902 - Evaluate TheRock as a cleaner build path - Test whether bleeding edge ROCm 7.1 can be ported - CI/CD pipeline for automatic ROCm / PyTorch / Dockerized PyTorch builds ---
**Author:** ![Soham\_Kulkarni](https://forum.fossunited.org/letter_avatar_proxy/v4/letter/s/a88e4f/32.png) [@Soham\_Kulkarni](https://forum.fossunited.org/u/Soham_Kulkarni)\ **Post date:** [1 September 2026 00:07 UTC](https://forum.fossunited.org/t/season-of-commits-2026-porting-rocm-to-gfx90c-gfx902/8517/3 "2026-09-01T00:07:33Z")
15 day update: Since the last update on 14 Aug, I have published five more articles covering the source-build, execution, failure-triage, and ROCm library-porting stages of the project. - 15 Aug 2026: [AMD vis-à-vis GPUs #10](https://netherquark.substack.com/p/amd-vis-a-vis-gpus-10), “Adding support for gfx90c in rocm-examples & a LLVM digression.” Added the missing `gfx90c` assembly generation path to `rocm-examples`, successfully ported `assembly_to_executable` and `llvm_ir_to_executable`. Also repaired the missing `hipify-perl` path, allowing the source build to proceed into additional HIP-Basic examples. - 24 Aug 2026: [AMD vis-à-vis GPUs #11](https://netherquark.substack.com/p/amd-vis-a-vis-gpus-11), “rocm-examples compiles!” Repaired the `glad.cpp` linker failure by enabling position-independent code, after which the full `rocm-examples` source tree compiled successfully. Moved benchmark execution to a TTY because GPU resets during graphical execution were killing the desktop session. Reached a 141-binary source-built corpus. - 25 Aug 2026: [AMD vis-à-vis GPUs #12](https://netherquark.substack.com/p/amd-vis-a-vis-gpus-12), “Experimental setup & GPU reduction.” Isolated GPU benchmark instability caused by simultaneous display, CPU, RAM, UMA and GPU load. Continued execution from TTY and analysed the reduction benchmarks, including `ItemsPerThread`, VGPR pressure and occupancy. Added 26 source-built examples, of which 20 passed automatically, increasing the reported passing count from 46 to 65. - 27 Aug 2026: [AMD vis-à-vis GPUs #13](https://netherquark.substack.com/p/amd-vis-a-vis-gpus-13). Built an automated benchmark triage pipeline using shell, CSV, regex, Python and matplotlib. Investigated the dominant return-code-127 failure class using `AMD_LOG_LEVEL=3` and `HIP_LAUNCH_BLOCKING=1`. Inspected ELF shared objects and embedded HIP fatbins using `readelf` and `llvm-objcopy`, confirming that the Fedora ROCm 6.4.4 builds of `rocBLAS`, `rocSolver` and `rocSPARSE` do not contain `gfx90c:xnack+` code objects. This established the runtime-library layer as the current compatibility boundary. - 01 Sep 2026: [AMD vis-à-vis GPUs #14](https://netherquark.substack.com/p/amd-vis-a-vis-gpus-14), “Porting librocsparse for gfx90c.” Compiled `librocsparse` from source with `GPU_TARGETS=gfx90c`, built its benchmark and test clients, and successfully produced a target-specific shared library. `rocsparse-bench` detects and executes on the native `gfx90c` device. The full test harness contains 310,983 tests across 370 suites; 216,388 tests executed successfully, the suite abruptly stopped with a GPU hang caused by performance limitations (iGPU GPU couldn’t allocate 2GB VRAM), not due to a runtime error. The resulting `librocsparse` build is now functionally ported to `gfx90c`. ![hip_overall_progress_report4](https://forum.fossunited.org/uploads/default/original/2X/8/859ce2f5ce6fd1793db2a4007175cafc5fab9e73.png) **Completed milestones:** 1. Native ROCm 6.4.4 on gfx90c 2. HIP hello-world on gfx90c 3. GPU programming article serving as educational groundwork for the rest of the project. 4. gfx900 spoofing on gfx90c was tested successfully. 5. Spoofing benchmarks demonstrating that spoofing works, but is not production-grade. 6. rocm-examples subset benchmarked on gfx90c 7. Packaging/path issues with ROCm from Fedora were resolved to run benchmarks. 8. Failure analysis of benchmark results from running 113 tests from rocm-examples on gfx90c 9. rocm-examples successfully compiled from source for gfx90c 10. Target-specific assembly generation and architecture enumeration issues were resolved in the source build 11. HIPIFY build path issues were resolved 12. Full 141-binary rocm-examples source build completed 13. TTY-based execution and GPU crash isolation workflow established 14. Automated benchmark execution, logging, failure classification and plotting pipeline established 15. Confirmed missing gfx90c code objects in Fedora rocBLAS / rocSolver / rocSPARSE 16. ELF / fatbin inspection workflow established for ROCm runtime libraries 17. librocsparse compiled natively for gfx90c 18. librocsparse benchmark client successfully executed on gfx90c 19. librocsparse test suite reached 216,388 / 310,983 tests before a GPU hang **Learned about & discussed:** 1. LLVM IR, target triples, register allocation, AMDGPU lowering 2. Relocation / PIC / PIE 3. GPU reduction algorithms 4. TTY execution and low-level Linux / GPU crash troubleshooting 5. Binary inspection and reverse engineering using `readelf`, `llvm-objcopy`, `llvm-objdump`, `xxd`, `od`, `dd`, `sed`, `zstd`, `compgen`, `clang-offload-bundler`, `clang-offload-packager` etc 6. CMake and library-scale build systems ![03_sankey_crash](https://forum.fossunited.org/uploads/default/original/2X/e/e651f7de0a10d3c21fabf81b57e513c81c4a0cba.jpeg) **Latest completed milestone:** Functionally ported `librocsparse` to native `gfx90c` and reached 216,388 / 310,983 tests in its upstream test harness before a GPU hang. **Pending** 1. Finish triage of the remaining `librocsparse` failure modes 2. Port `COMPILER_HAS_TARGET_ID_gfx90c` into the librocsparse build configuration 3. Port `/usr/lib64/librocblas.so.4.4` 4. Port `/usr/lib64/librocsolver.so.0.4` 5. Generate `TensileLibrary.dat` for gfx90c 6. Resolve the remaining `rocm-examples` failure classes 7. Resolve `applications_monte_carlo_pi` 8. Resolve `hip_opengl_interop` 9. Compile ROCm 6.4.4 from source / get TheRock working 10. Add automatic GPU detection and target selection to the rocm-examples build system 11. Benchmark real-world HIP workloads natively on gfx90c vs gfx900 spoofing 12. Compare source-built gfx90c results against the Fedora-packaged binaries 13. Benchmark PyTorch on the recovered stack 14. Rebuild PyTorch against the patched ROCm stack 15. Port PyTorch Docker images to gfx90c 16. Repeat the recovery process on gfx902 17. Evaluate whether the same methodology generalises across additional unsupported AMD GPUs 18. Test bleeding-edge ROCm 7.1 19. Investigate LLVM support boundaries for GPUs outside the currently supported target set 20. Build the automated CI/CD pipeline for ROCm / PyTorch / Dockerised PyTorch builds I am compiling large ROCm components and running very large test suites on a 6c/12t CPU & 7-CU iGPU, so some experiments take hours, but the remaining parts of this project are largely just repeating the solutions I’ve built for various libraries. ---
**Author:** ![jefferson\_rodrigues](https://forum.fossunited.org/letter_avatar_proxy/v4/letter/j/eada6e/32.png) [@jefferson\_rodrigues](https://forum.fossunited.org/u/jefferson_rodrigues)\ **Post date:** [6 September 2026 13:50 UTC](https://forum.fossunited.org/t/season-of-commits-2026-porting-rocm-to-gfx90c-gfx902/8517/4 "2026-09-06T13:50:10Z")
Hi Soham, My name is Jefferson. I am one of the countless users daily driving a **gfx90c** APU who wants to see ROCm running natively. Your work on Season of Commits is outstanding and easily the most promising initiative out there right now. While I am still sharpening my programming skills and cannot contribute directly with low-level C++ or LLVM compilation patches, I have dedicated machine time and hardware available to test and crunch data. Looking at your recent failure triage milestones (resolving rocm-examples and tracing missing code objects), would it be viable to set up a **grammar-based / guided fuzzing pipeline** to validate ISA coverage? - **Grammar-guided coverage:** Generate and test instruction sets systematically based on the AMDGPU GFX9 LLVM ISA specifications (testing valid register ranges, DPP/SDWA modifiers, and packed math combinations). - **Dockerized client for volunteers:** Package the harness into a headless/TTY Docker image or standalone runner that volunteers like me can pull, run in the background, and have it automatically log results/anomalies to a central server or GitHub issue. - **Automated triage:** Use an LLM/scripted pipeline to classify return codes (like error 127, memory hangs, or invalid opcodes) against the documentation rules to narrow down exact compiler gaps. This could offload hours of repetitive local bench testing from your 6c/12t rig and accelerate library parity, while letting the community actively support your roadmap with raw hardware hours. Thanks again for taking on this challenge for the entire APU community! ---
**Author:** ![Soham\_Kulkarni](https://forum.fossunited.org/letter_avatar_proxy/v4/letter/s/a88e4f/32.png) [@Soham\_Kulkarni](https://forum.fossunited.org/u/Soham_Kulkarni)\ **Post date:** [7 September 2026 03:43 UTC](https://forum.fossunited.org/t/season-of-commits-2026-porting-rocm-to-gfx90c-gfx902/8517/5 "2026-09-07T03:43:59Z")
Hey Jefforson! Thanks for the support, really appreciate it. Having dedicated machine time & hardware would be extremely beneficial, as I currently use the same machine for dev & testing. I’ll take you up on the offer as soon as feasible. I’d like to clarify that this project is multi-purpose: 1. Creating open-commons educational content regarding ROCm / GPUs / Compilers / porting, since there’s very few comprehensive existing high quality resources (as you must’ve found!). Studying these dense topics directly can be quite tough, and simply documenting my progress porting ROCm would only be relevant to FOSS United folks for documentation + `gfx9` users like you & me. In my opinion, explaining these siloed concepts through the narrative of hardware bring-up increases the target audience. 2. I’m currently a student pursuing my B.Tech. I want to eventually work full-time in the compilers domain, this is intended as a gateway show-and-tell project. 3. As shared in the beginning of the thread the final work-product is to "build an automated CI/CD pipeline which will build and publish custom ROCm / PyTorch with my patches. " This might provide some insight on why I’ve done everything by hand till now. While this choice slows down Goal 3, it helps immensely with Goal 1 and Goal 2. I am using LLMs for mundane work like writing scripts & also for generating figures. But I’m opposed to outsourcing _cognitive loads_ to LLMs hence I’ll likely avoid automated triage in this project. I’d rather write a regex based categorisation script with AI than use an AI to classify errors directly. Hope that makes sense! Regarding grammar guided coverage, I will look into this! I was able to port `rocsparse` by changing the build targets, same for `rocfft` and `rocrand`. I just finished porting Tensile by doing kernel tuning, which is the biggest milestone I was worried about. As far as I’m aware, these signals indicate that we don’t need to worry too much about ISA coverage for _functionality_. Another reason I haven’t looked into correctness extensively is that `gfx900`, and `gfx90c` have the exact same ISA, which was discused in [#3](https://netherquark.substack.com/p/amd-vis-a-vis-gpus-3): > The MI25 (`gfx900`) was a GCN5.0 16GB workstation GPU released by AMD in 2017. Internally, its based on a Vega 10 GPU. The ISA may be mostly identical between `gfx900` and `gfx90c`, but the silicon design is different! One was designed & optimised for HBM2 (High Bandwidth Memory), whereas the other shares DDR4 (Double Data Rate 4) RAM with the CPU. The difference in bandwidth is a factor of 10 (~400GB/s vs 30-40GB/s). This does mean focusing on _correctness_ case-by-case after focusing on _functionality_ universally, but I think that’s a reasonable compromise as a single dev. As per your suggestion, I think its an excellent idea to create a runner (whether Dockerised or not) which can automatically run test suites for the remaining binaries (`rocfft`, `rocrand`, essentially everything under the AMD ROCm GitHub org) with results automatically logged and shared to a central resource. Running these verification suites on community devices would definitely help speed up this project’s timeline. An initial prototype I use on my system is available [here](https://github.com/Netherquark/backrocm/blob/main/graphs/gpus-14/rocsparse_test_logging.sh), I’ll work on making it universal with automatic compilation of the library which is being tested. After reaching Milestone 12: comparing source-built `gfx90c` with Fedora binaries, I am planning to build the following and triage user submitted issues case-by-case via GitHub: 1. Initially, the runner for automated test suite execution, logging, central reporting. Iterate, get all the failing ROCm components fixed. 2. Then, ship native ROCm binaries 3. PyTorch + ROCm 4. Dockerised PyTorch + ROCm 5. Optionally, Dockerised native ROCm binaries (not sure how many users have this workflow) By the way, AMD has recently upstreamed preliminary `gfx90c` support with native ROCm & PyTorch + ROCm both available via theRock / ROCm 7.x. You can download and use them from [here](https://rocm.nightlies.amd.com/tarball/). Unfortunately, its conceptually identical to spoofing `HSA_OVERRIDE_GFX_VERSION=9.0.0`. `gfx900` is `vega10`, `gfx90c` is [Green Sardine](https://git.zx2c4.com/linux-rng/tree/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c?id=9bac1bd6e6d36459087a728a968e79e37ebcea1a). You can view the Tensile `gfx90c`code [here](https://github.com/ROCm/rocm-libraries/blob/develop/shared/tensile/Tensile/Common.py): ```auto Relevant: 'gfx900':'vega10', 'gfx900:xnack-':'vega10', 'gfx90c':'vega10' Full: 321 architectureMap = { 'all':'_', 'gfx000':'none', 'fallback':'hip', 'gfx803':'r9nano', 'gfx900':'vega10', 'gfx900:xnack-':'vega10', 'gfx90c':'vega10', 'gfx906':'vega20', 'gfx906:xnack+':'vega20', 'gfx906:xnack-':'vega20', 'gfx908':'arcturus','gfx908:xnack+':'arcturus', 'gfx908:xnack-':'arcturus', 'gfx90a':'aldebaran', 'gfx90a:xnack+':'aldebaran', 'gfx90a:xnack-':'aldebaran', 'gfx942':'aquavanjaram942', 'gfx942:xnack+':'aquavanjaram942', 'gfx942:xnack-':'aquavanjaram942', 'gfx950':'gfx950', 'gfx950:xnack+':'gfx950', 'gfx950:xnack-':'gfx950', 'gfx1010':'navi10', 'gfx1011':'navi12', 'gfx1012':'navi14', 'gfx1030':'navi21', 'gfx1031':'navi22', 'gfx1032':'navi23', 'gfx1033':'van gogh', 'gfx1034':'navi24', 'gfx1035':'rembrandt', 'gfx1036':'raphael', 'gfx1100':'navi31', 'gfx1101':'navi32', 'gfx1102':'navi33', 'gfx1103':'gfx1103', 'gfx1150':'strixpoint', 'gfx1151':'strixhalo', 'gfx1152':'gfx1152', 'gfx1153':'gfx1153', 'gfx1200':'gfx1200', 'gfx1201':'gfx1201', 'gfx1250':'gfx1250' } ``` This is support & compatibility for the sake of it. I’m going to continue work on this ROCm fork. PS: The test suites are _incredibly_ bandwidth heavy on APUs. They can easily make the DE crash / push all CPU workloads to swap / cause kernel ring failures etc. This is why I usually run them on a TTY with all competing CPU/GPU processes eliminated. Please close any critical tasks before running them! ---
**Author:** ![jefferson\_rodrigues](https://forum.fossunited.org/letter_avatar_proxy/v4/letter/j/eada6e/32.png) [@jefferson\_rodrigues](https://forum.fossunited.org/u/jefferson_rodrigues)\ **Post date:** [9 September 2026 13:40 UTC](https://forum.fossunited.org/t/season-of-commits-2026-porting-rocm-to-gfx90c-gfx902/8517/6 "2026-09-09T13:40:11Z")
Hi Soham, ​Thanks for the thoughtful reply and for sharing the broader context behind your work. ​Throughout my professional career, I have coordinated multidisciplinary engineering teams. In leadership, my principle has always been to understand the foundational mechanics deeply enough to guide and mentor, even when time constraints prevent me from writing every line or getting hands-on with every detail. ​That shapes how I view working with AI. Modern LLMs have an encyclopedic recall of syntax and isolated logic, but they still lack the high-level intuition required to design and steer complex project architecture. In many ways, they behave like eager apprentices: capable of rapid execution, but entirely dependent on human guidance to define the roadmap, structure the flow, and catch structural flaws. I may not write complex Python or low-level C++ daily, but systems architecture, workflow optimization, and finding the bottlenecks are second nature to me. ​That is also why I admire your hands-on approach. Building that mental muscle and compiler intuition from first principles is what turns an engineer into a true systems architect. ​That Tensile mapping revelation really underscores why your independent effort matters so much: ‘gfx900’:‘vega10’, ‘gfx900:xnack-’:‘vega10’, ‘gfx90c’:‘vega10’ Seeing AMD simply map gfx90c directly to vega10 without memory-aware kernel tuning confirms they settled for a superficial fix. Your tuned fork is the real solution the hardware actually deserves. ​As soon as you have the runner prototype ready for external nodes, let me know or drop the instructions here. I have hardware ready and can allocate clean TTY time to run the verification suites and log the outcomes without desktop interference. ​Best of luck on Milestone 12! ​Best regards, Jefferson ---
**Author:** ![Soham\_Kulkarni](https://forum.fossunited.org/letter_avatar_proxy/v4/letter/s/a88e4f/32.png) [@Soham\_Kulkarni](https://forum.fossunited.org/u/Soham_Kulkarni)\ **Post date:** [15 September 2026 14:50 UTC](https://forum.fossunited.org/t/season-of-commits-2026-porting-rocm-to-gfx90c-gfx902/8517/7 "2026-09-15T14:50:56Z")
As discussed prior, > AMD has recently upstreamed preliminary `gfx90c` support with native ROCm & PyTorch + ROCm both available via theRock / ROCm 7.x. You can download and use them from here. Unfortunately, its conceptually identical to spoofing `HSA_OVERRIDE_GFX_VERSION=9.0.0`. `gfx900` is vega10, `gfx90c` is Green Sardine. The following milestones would thus be duplicating upstream work: - Finish triage of the remaining librocsparse failure modes - Port `COMPILER_HAS_TARGET_ID_gfx90c` into the librocsparse build configuration - Port `/usr/lib64/librocblas.so.4.4` - Port `/usr/lib64/librocsolver.so.0.4` - Resolve the remaining rocm-`examples` failure classes - Resolve `applications_monte_carlo_pi` - Resolve `hip_opengl_interop` - Compile ROCm 6.4.4 from source / get TheRock working - Add automatic GPU detection and target selection to the `rocm-examples` build system - Benchmark real-world HIP workloads natively on `gfx90c` vs `gfx900` spoofing - Compare source-built `gfx90c` results against the Fedora-packaged binaries - Benchmark PyTorch on the recovered stack - Rebuild PyTorch against the patched ROCm stack - Port PyTorch Docker images to `gfx90c` - Repeat the recovery process on `gfx902` - Evaluate whether the same methodology generalises across additional unsupported AMD GPUs - Test bleeding-edge ROCm 7.1 - Investigate LLVM support boundaries for GPUs outside the currently supported target set - Build the automated CI/CD pipeline for ROCm / PyTorch / Dockerised PyTorch builds The upstream change does not erase the educational work from the first 14 articles. Taken together, they form a progression through ROCm installation and compatibility, HIP execution, GPU architecture, execution and memory hierarchy, AMDGPU assembly, LLVM IR and register allocation, target triples and CMake, ELF relocation and PIC/PIE, benchmark methodology, experimental failure analysis, automation, and source-built ROCm components. The final articles then connect those concepts to an actual 200k+ test library validation. These articles document the mechanisms, experiments and debugging decisions required to understand the stack from first principles. However, the crux of the project remained unsolved by upstream: - Generate `TensileLibrary.dat` for `gfx90c` I haven’t had the time to write an article about my work the past 15 days yet, so I’m providing a high level explanation here. Tensile is the benchmark-driven kernel-library generator behind `rocBLAS`. Rather than providing one fixed kernel for a GEMM operation, it generates a large set of candidate solutions by varying parameters such as MacroTile, ThreadTile, WorkGroup, DepthU, VectorWidth, prefetching, GlobalSplitU and WorkGroupMapping. Those candidates are compiled for the target ISA, benchmarked on the hardware, and reduced into library logic which records which solution should be selected for each problem shape. `TensileCreateLibrary` then packages that logic and the corresponding code objects into the final library artifact. Adding `gfx90c` to the compiler and runtime establishes that the architecture can execute native kernels. The shipped `gfx900` Tensile library contains 28 family/pattern libraries and 3,066 highly specialized kernels, with extensive shape coverage and per-kernel feature configurations. This is missing for `gfx90c`, `gfx902` and all of the other GPUs this project has targeted from day 1. The goal has been: match the shipped `gfx900` footprint of 3,066 kernels across 28 families and four contraction patterns with native `gfx90c` equivalents. For tackling this, I initially designed a prototype shell script (ended up being ~4k lines of AI slop) to run experiments and figure out the appropriate approach from 1 September through 12 September. It started as an experimental benchmark runner and progressively I implemented all the necessary features. The final script evolved into a full experimental harness for exploring the Tensile search space and for identifying the failure modes that a persistent tuning system would have to handle. This helped me establish several constraints for the new design. I derived the gfx90c realistic and theoretical ceilings (based on ALU/DDR limitations) from the hardware specifications: 1. 7 CUs 2. 448 FP32 lanes 3. Wave64 execution 4. 280 maximum wavefront slots 5. 64 KiB LDS per CU 6. no MFMA. The approximate theoretical ceilings are: 1. 1613 GFLOPS for FP32, BF16, Complex FP32, and the HPA families 2. 3226 GFLOPS for packed FP16 3. 101 GFLOPS for FP64 and Complex FP64 4. 1613 GOPS for INT8. These are the baseline for my `TensileLibrary.dat`. There was approximately ±23–31% fluctuation across ALU-bound runs due to the APU’s thermal and clock variation. This means raw GFLOPS are unsuitable for comparing experiments. I designed a normalised benchmarking system which helps isolate tuning gains from thermal/DVFS noise. All code/logs/benchmark results from the initial prototype and its supporting experiments are available on [GitHub](https://github.com/Netherquark/backrocm/tree/main/porting_tensile/attempt1). After finalising the design on 13 September, I built the `v0` Python implementation. The flow is divided into manifest execution, candidate generation, benchmark execution, adaptive repetition, analytics and registry management, library synthesis, and final acceptance reporting. Semantic selectors allow the runner to target a specific family, contraction pattern, shape or stage without modifying the underlying manifest. The kernel tuning search space here is too big to explore blindly. Adding an agent makes sense, hear me out `:D` The LLM acts as a hypothesis engine, consuming the experiment database, current winners, failed configurations, profiling/telemetry and hardware constraints. It proposes a small set of specific parameter mutations for the next generation of candidates. This collapses the enormous Tensile search space into evidence-driven local neighbourhoods rather than enumerating combinations blindly. I believe its a suitable constrained application for agentic AI being inherently neurosymbolic. The neural component supplies learned, probabilistic hypotheses which can be cheaply evaluated and iterated against a symbolic system which supplies explicit parameter semantics, validity rules, compilation, correctness tests, benchmarking, deduplication and selection. Every iteration shrinks the viable search frontier instead of letting either Tensile or the agent wander through the full combinatorial space. The implemented agentic loop is as follows: 1. observe spoof & native performance (Suite & Tensile) 2. propose mutations (Agent) 3. validate (Tensile) 4. benchmark (Suite + Tensile) 5. retain winners (Suite) 6. mutate the winners (Agent + Suite) 7. Repeat I ran it overnight from 14 Sept to 15th Sept. Here are the highlights from crunching results vs the 13 Sep initial Python prototype: 1. Ran for 7.7 hours across five iterations 2. 2,400 raw measurements and accumulated 1,652 registry records 3. Candidate mutation was functional 4. HH family improved from 1127.8 to 1732.0 GFLOPS (+53.6%) 5. +89%-650% coverage across families, 185% increase in explored cells overall 6. Already at 91.3% of theoretical limit on DD 7. Crossed original realistic limit for HH\_HPA, 73.4% of theoretical Ooh also I designed a very pretty auto-updating IBM Carbon design system style dashboard for the tuning suite progress report, you can view the latest results in this image: ![image](https://forum.fossunited.org/uploads/default/original/2X/5/55462a319586d82d7f48d39b1788cd9f0c7e78d3.png) I plan to create a separate repository for the new agentic kernel-tuning suite so that its independent from the code I use for plotting graphs etc for my articles. Completed milestones: - 14 article series on ROCm, HIP, GPU architecture, GPU execution and memory hierarchy, AMDGPU assembly, LLVM IR and register allocation, ELF relocation and PIC/PIE, etc. - Study Tensile, experiment with kernel tuning - Design agentic Python kernel tuning suite - First autonomous benchmark run. Ongoing - Generate `TensileLibrary.dat` for `gfx90c` Next milestones: 1. Build out the agentic search engine: Improve candidate generation, mutation strategies, evidence extraction, scheduling, novelty accounting, convergence detection and persistent experiment memory 2. Maximise `gfx90c` against its hardware ceilings: Expand beyond the initial search regions, explore the remaining Tensile parameter space systematically, and drive each workload family toward the theoretical ceilings established from the hardware and measurements. 3. Validate the methodology on `gfx902`: Apply the complete pipeline to an unsupported architecture and determine which parts of the system can be derived from hardware constraints, ISA capabilities and Tensile semantics without requiring an existing upstream target. 4. Refactor so that a new AMD GPU can be described through explicit hardware constraints that the suite can natively reason against. 5. Package the workflow so any tester can invoke it easily with an API key and generate a tuned `TensileLibrary.dat` for their hardware. (Jefferson will be able to help with this) 6. Attempt to upstream the resulting `gfx90c` configuration and tuning data, and investigate a corresponding upstream path for `gfx902`. 7. Benchmark the resulting custom `TensileLibrary.dat` against the available upstream `gfx90c` support path under reproducible conditions. 8. Generalise the tuning engine to additional AMD architectures after `gfx90c` convergence. 9. Publish the suite under an open license so the broader community can extend the approach to additional AMD architectures. 10. Keep publishing informative educational articles about various complex topics I come across during this effort, such as GPU kernels, Tensile, kernel tuning, GPU features like MFMA, neurosymbolic agentic implementations, agentic approaches to kernel tuning, picking winner kernels, geometry of GPU GEMMs, tracing architectural compatibility through Tensile, YAML to TensileLibrary.dat, postmortems for any runs, interesting failure modes, deriving theoretical & realistic peaks for any GPU, etc. ---
**Author:** ![jefferson\_rodrigues](https://forum.fossunited.org/letter_avatar_proxy/v4/letter/j/eada6e/32.png) [@jefferson\_rodrigues](https://forum.fossunited.org/u/jefferson_rodrigues)\ **Post date:** [17 September 2026 12:51 UTC](https://forum.fossunited.org/t/season-of-commits-2026-porting-rocm-to-gfx90c-gfx902/8517/8 "2026-09-17T12:51:25Z")
Hi Soham, What an incredible breakthrough. This is engineering at its finest! Pivoting to an **agentic neurosymbolic loop** for the Tensile parameter space is pure brilliance. Using the LLM as a hypothesis generator while letting the symbolic harness enforce the compiler/ISA rules and hardware ground truth completely eliminates the risk of hallucinations. Seeing a **+53.6% gain on HH** and hitting **91.3% of the theoretical ceiling on DD** in an overnight run proves the architecture works. You were spot on to discard the raw upstream duplication. What AMD did in ROCm 7.x was merely cosmetic spoofing; what you are doing with `TensileLibrary.dat` is extracting the true physical potential of the silicon. Thank you for the shout-out in the milestone roadmap! I am fully on board to help **test and validate the packaged workflow** once you have that CLI/API harness ready. My APU is prepped, and I will be glad to run the tuning engine to help generate, stress-test, and verify the library records. Looking forward to the dedicated repository drop and your next article on GPU GEMM geometry! Best regards, Jefferson ---
**Author:** ![Soham\_Kulkarni](https://forum.fossunited.org/letter_avatar_proxy/v4/letter/s/a88e4f/32.png) [@Soham\_Kulkarni](https://forum.fossunited.org/u/Soham_Kulkarni)\ **Post date:** [30 September 2026 14:19 UTC](https://forum.fossunited.org/t/season-of-commits-2026-porting-rocm-to-gfx90c-gfx902/8517/9 "2026-09-30T14:19:37Z")
Completed milestones: - Generate `TensileLibrary.dat` for `gfx90c` - Publish the suite under an open license so the broader community can extend the approach to additional AMD architectures. > _oto_ is licensed GPLv3, however it is currently private. I will make the repository public once the codebase is stable & the Tensile gfx90c / gfx902 PRs are opened against [GitHub - ROCm/rocm-libraries: super repo for rocm libraries · GitHub](https://github.com/ROCm/rocm-libraries) - Build out oto: Improve evidence extraction, scheduling, convergence detection and persistent experiment memory > 100% coverage of shipped gfx900 2285 kernel library (38 different dtype/shape combinations) completed. TensileLibrary.dat gfx90c version generated is functional. Ongoing milestones: - Build out the agentic search engine: Improve candidate generation, mutation strategies - Keep publishing informative educational articles about various complex topics I come across during this effort, such as GPU features like MFMA, deriving theoretical & realistic peaks for any GPU > MFMA article is ready, drafting theoretical / realistic peaks one to publish it first. Have brainstormed & prepared a list of 17 articles I’m planning to publish in October. - Refactor so that a new AMD GPU can be described through explicit hardware constraints that the suite can natively reason against. > Currently the code is fully modular, just need to validate against gfx902 - Maximise `gfx90c` against its hardware ceilings: Expand beyond the initial search regions, explore the remaining Tensile parameter space systematically, and drive each workload family toward the theoretical ceilings established from the hardware and measurements. > Currently the custom gfx90c equivalents are achieving upto 2.7x performance of the spoof SOTA approach. DD, HH\_HPA and HS\_HPA are achieving ~90% percent of their theoretical limit. > > ![article15_ab_snapshot](https://forum.fossunited.org/uploads/default/original/2X/5/5f85ff3c22df7854e0dc7d5a95bb3894cf666838.png) Next milestones: 1. Package the workflow so any tester can invoke it easily with an API key and generate a tuned `TensileLibrary.dat` for their hardware. (Jefferson will be able to help with this) 2. Validate the methodology on `gfx902`: Apply the complete pipeline to an unsupported architecture and determine which parts of the system can be derived from hardware constraints, ISA capabilities and Tensile semantics without requiring an existing upstream target. 3. Attempt to upstream the resulting `gfx90c` configuration and tuning data, and investigate a corresponding upstream path for `gfx902`. 4. Benchmark the resulting custom `TensileLibrary.dat` against the available upstream `gfx90c` support path under reproducible conditions. 5. Generalise the tuning engine to additional AMD architectures after `gfx90c` convergence. 6. Mojo deep dive: The project mentor, Mr. Bhooshan Agalgatti said that extending this work to be vendor-agnostic is the appropriate direction. Accordingly, I’m planning a Mojo deep dive in October. Mojo was recently open sourced, it was designed by Modular AI (Chris Lattner’s startup, creator of LLVM). Mojo allows developers to write GPU code that works across GPU vendors. There’s a lot of fast moving changes in Mojo, and ROCm support in Mojo is constantly evolving. [Mojo doesn’t support gfx90c](https://forum.modular.com/t/how-to-get-mojo-to-detect-amd-integrated-gpu-apu/2727 "Mojo doesn't support gfx90c") very well currently AFAIK, so step 1 will be porting it. 7. Keep publishing informative educational articles about various complex topics I come across during this effort, such as GPU kernels, Tensile, kernel tuning, neurosymbolic agentic implementations, agentic approaches to kernel tuning, picking winner kernels, geometry of GPU GEMMs, tracing architectural compatibility through Tensile, YAML to TensileLibrary.dat, postmortems for any runs, interesting failure modes, LLVM/PyTorch/XLA/TF comparison for same GEMM, discussing the nuances of oto design (telemetry adjusted winners, sysfs GPU, etc), discuss existing agentic kernel tuning frameworks, deep dive into how a new AMD GPU is added to LLVM, XNACK/memory pressure deep dive, RDNA/CDNA vs GCN architecture deep dive, Deep dive comparing various approaches to GPU Reduction, Using OpenGL/Vulkan/RustiCL/etc for GPU computing, ZlUDA/ZML etc deep dive, Rust on AMD GPUs, hardware-controlled versus software-controlled memory management, Wave64/Wave32 performance comparison for HPC workloads, etc. ---
**Author:** ![Soham\_Kulkarni](https://forum.fossunited.org/letter_avatar_proxy/v4/letter/s/a88e4f/32.png) [@Soham\_Kulkarni](https://forum.fossunited.org/u/Soham_Kulkarni)\ **Post date:** [15 October 2026 13:12 UTC](https://forum.fossunited.org/t/season-of-commits-2026-porting-rocm-to-gfx90c-gfx902/8517/10 "2026-10-15T13:12:51Z")
## October update: oto tuning and gfx90c performance Published two articles since my last update: - **AMD vis-à-vis GPUs** #16: **Establishing hardware capabiliites of gfx90c** (6 October): derived theoretical and realistic performance ceilings from the hardware specifications, accounting for compute throughput, memory bandwidth, occupancy and thermal constraints. - **AMD vis-à-vis GPUs** #17: **History of fused multiply-add** (9 October): covered FMA architecture, IBM POWER1, arithmetic datapaths and x86 FMA3/FMA4. ### Completed Milestones 1. Package the workflow so any tester can invoke it easily with an API key and generate a tuned `TensileLibrary.dat` for their hardware. > The gfx90c TensileLibrary.dat is ready with 100% coverage of the shipped gfx900, but I’m trying to optimise performance as much as possible prior to opening a PR in AMD’s repos. > > ![image](https://forum.fossunited.org/uploads/default/original/2X/6/690844d2ccb8e2b2f40826eecc8ccf11e2a62441.png) Convergence for `gfx90c` is taking longer than expected due to time taken to run each candidate. The harness is working well but testing winners & mutations is the time consuming part. Rewrote the codebase to be more modular / readable / resilient in the meanwhile. ~50 commits in past 15 days. ### oto development - Implemented per-cell winner resolution, reproducing configurations and results for all 38 tracked workload cells. The 10 October dataset records 19 wins, 18 ties and 1 loss against the spoof reference floor. - Fixed HH\_HPA/HS\_HPA family attribution and corrected complex-operation accounting using the BLAS-8 convention. - Reworked candidate generation, parameter forwarding and legality validation. The latest candidate manifest contains 308 phases with zero validation offenders. - Refactored the codebase into focused modules and consolidated obsolete research material into maintained documentation and archives. ### Next milestones 1. Validate the methodology on `gfx902`: Apply the complete pipeline to an unsupported architecture and determine which parts of the system can be derived from hardware constraints, ISA capabilities and Tensile semantics without requiring an existing upstream target. 2. Attempt to upstream the resulting `gfx90c` configuration and tuning data, and investigate a corresponding upstream path for `gfx902`. 3. Benchmark the resulting custom `TensileLibrary.dat` against the available upstream `gfx90c` support path under reproducible conditions. 4. Generalise the tuning engine to additional AMD architectures after `gfx90c` convergence. 5. Mojo deep dive: The project mentor, Mr. Bhooshan Agalgatti said that extending this work to be vendor-agnostic is the appropriate direction. Accordingly, I’m planning a Mojo deep dive in October. Mojo was recently open sourced, it was designed by Modular AI (Chris Lattner’s startup, creator of LLVM). Mojo allows developers to write GPU code that works across GPU vendors. There’s a lot of fast moving changes in Mojo, and ROCm support in Mojo is constantly evolving. [Mojo doesn’t support gfx90c](https://forum.modular.com/t/how-to-get-mojo-to-detect-amd-integrated-gpu-apu/2727 "Mojo doesn't support gfx90c") very well currently AFAIK, so step 1 will be porting it. 6. Keep publishing informative educational articles about various complex topics I come across during this effort, such as GPU kernels, Tensile, kernel tuning, neurosymbolic agentic implementations, agentic approaches to kernel tuning, picking winner kernels, geometry of GPU GEMMs, tracing architectural compatibility through Tensile, YAML to TensileLibrary.dat, postmortems for any runs, interesting failure modes, LLVM/PyTorch/XLA/TF comparison for same GEMM, discussing the nuances of oto design (telemetry adjusted winners, sysfs GPU, etc), discuss existing agentic kernel tuning frameworks, deep dive into how a new AMD GPU is added to LLVM, XNACK/memory pressure deep dive, RDNA/CDNA vs GCN architecture deep dive, Deep dive comparing various approaches to GPU Reduction, Using OpenGL/Vulkan/RustiCL/etc for GPU computing, ZlUDA/ZML etc deep dive, Rust on AMD GPUs, hardware-controlled versus software-controlled memory management, Wave64/Wave32 performance comparison for HPC workloads, etc. ---
**Author:** ![jefferson\_rodrigues](https://forum.fossunited.org/letter_avatar_proxy/v4/letter/j/eada6e/32.png) [@jefferson\_rodrigues](https://forum.fossunited.org/u/jefferson_rodrigues)\ **Post date:** [15 October 2026 16:44 UTC](https://forum.fossunited.org/t/season-of-commits-2026-porting-rocm-to-gfx90c-gfx902/8517/11 "2026-10-15T16:44:16Z")
Hi Soham, Outstanding progress on the October milestones! Seeing the dataset reach 19 wins, 18 ties, and only 1 loss with 100% deck coverage across all families proves that the per-cell winner resolution completely fixed the large-matrix bottlenecks. As you mentioned packaging the workflow for external testers, I want to confirm that I am fully ready to dedicate machine time to help accelerate candidate evaluation and convergence for **gfx90c**. Here are my hardware and environment specifications: - **Machine:** Acer Aspire 5 - **Processor & GPU:** AMD Ryzen 7 (5000 series) with integrated Radeon Graphics ( **gfx90c** ) - **Memory:** 36 GB RAM (plenty of headroom to avoid OOM/swap thrashing during heavy GEMM runs) - **Storage:** Ample fast NVMe/SSD space dedicated for datasets and build caches - **Operating Systems:** Dual-boot with **Pop!\_OS Linux** (primary development environment, ready to run headless in pure TTY) and Windows 11 LTSC. While low-level C++ compiler hacking isn’t my primary domain, my background is in engineering and multidisciplinary team management. I focus heavily on systems flow, structured algorithms, and reliable execution. A quick question regarding the API setup: - Which LLM provider / API endpoint does `oto` currently expect for candidate mutation (e.g., Google Gemini, OpenAI, Claude, or a custom local endpoint)? - Since `oto` is currently in a private repo, how would you prefer to share the runner/container with me to start running batches? Looking forward to putting this hardware to work on your pipeline! Best regards, Jefferson ---
**Author:** ![Soham\_Kulkarni](https://forum.fossunited.org/letter_avatar_proxy/v4/letter/s/a88e4f/32.png) [@Soham\_Kulkarni](https://forum.fossunited.org/u/Soham_Kulkarni)\ **Post date:** [15 October 2026 17:32 UTC](https://forum.fossunited.org/t/season-of-commits-2026-porting-rocm-to-gfx90c-gfx902/8517/12 "2026-10-15T17:32:51Z")
Hello Jefferson! I’ll revert once I come up with a good implementation for how the results can be collected & compiled across our devices. Will be in touch soon! Thanks once again for volunteering to help.