Comprehensive ROCm helper for centralized Windows package integration and installation support#1629
Comprehensive ROCm helper for centralized Windows package integration and installation support#1629NeuralFault wants to merge 17 commits intoLykosAI:mainfrom
Conversation
- Add initial ROCm helper structure - Set up ROCm helper foundation Compile test sucessful.
- Add initial ROCm helper calls/config - Removed pre-existing Windows ROCm blocks which will be obsolete following helper implementation
- Windows ROCm install/bootstrap logic into shared ROCm helper - Add gfx-family mapping for Windows-native TheRock ROCm URLs - Route ComfyUI Win Rocm installs through helper-resolved ROCm runtime, rocm-sdk, and pytorch setup - Prevent requirements.txt from overwritting helper-installed ROCm torch packages - Add helper-owned post-install torch verification and improve unsupported GPU failure handling
…ntime/install/environment API and simplify the ROCm profile/context models around the helper’s real responsibilities - add a centralized Windows ROCm support map so GPU detection, architecture support checks, and package index resolution all use the same source of truth - expand AMD architecture detection to cover additional RDNA4, Steam Deck, RDNA1, and Vega-class GPUs used by the Windows ROCm support path - add a helper-managed Windows ROCm bootstrap flow that installs the ROCm runtime, initializes/reinitializes the SDK, aligns rocm-sdk-devel with the resolved torch build, and verifies both torch ROCm metadata and runtime availability - centralize ROCm launch environment construction in the helper, including default MIOpen, allocator, flash-attention, and AOTriton settings plus legacy SDP fallback, RDNA1 overrides, and user env override layering - switch ComfyUI to helper-driven Windows ROCm compatibility and launch env handling, and default legacy Windows ROCm GPUs to quad cross-attention while keeping Comfy-specific MIOpen enablement as a preset - integrate Wan2GP with the shared Windows ROCm helper for install and launch flows, while updating its Linux ROCm path to use upstream rocm7.2 torch/vision/audio installs - wire the ROCm helper through package construction and add focused test coverage for ROCm build/version parsing, runtime failure classification, and Windows ROCm support/index resolution
- centralize Windows ROCm architecture classification and legacy-attention fallback policy in WindowsRocmSupport - move ComfyUI-specific MIOpen env handling out of the helper and into package-owned ROCm config - reuse shared ROCm policy for ComfyUI quad-attention defaults and helper-managed AOTriton / math SDP / RDNA1 gates - remove dead ROCm preset plumbing and trim unused RocmPackageProfile surface - rename helper/package methods for clearer default-policy semantics
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request centralizes Windows ROCm support by introducing a shared IRocmPackageHelper service and associated models, refactoring ComfyUI and Wan2GP to use this new framework. The changes include expanded GPU architecture detection and standardized installation and environment configuration logic. Feedback identifies a missing dependency injection for Wan2GP in the factory and a configuration regression in ComfyUI's memory allocation settings. Further suggestions focus on optimizing the helper by reducing redundant hardware probing, avoiding unnecessary hardware refreshes, and using more appropriate exception types.
Was used during debugging and was unintentionally left on.
Add helper-managed ROCm torch compatibility profiles for Windows packages Enable ComfyUI to use shared ROCm dependency fallback behavior Add shared Windows ROCm launch notice and experimental-support messaging Align Wan2GP Windows ROCm disclaimer text with the shared helper messaging Lower helper-managed MIOPEN_FIND_ENFORCE default from 3 to 1 Add gfx103x borrowed dependency fallback using ROCm-hosted setuptools and mpmath from gfx103x-dgpu due to -all index missing compatible versions Add helper preinstall and supplemental dependency handling for ROCm torch installs Add temporary environment override support for helper-owned install steps
- generalize the ROCm helper install path around a new multi-arch TheRock nightly repo index flow - unify ROCm and PyTorch installation into a single command that automatically selects the correct PyTorch build for the user's GPU architecture - centralize Windows ROCm GPU and architecture resolution behind one shared helper machine-state path - trim the ROCm helper API and remove obsolete package-side ROCm install/runtime duplication - deleted no longer used torch compatibility model since A3WebUI/reForge work was rolled back and abandoned to be visited again in the future for intergration
…upport. - extract the shared Windows ComfyUI ROCm profile from package-local code - reuse the shared ROCm helper/profile for both direct ComfyUI launch behavior and SwarmUI self-launch pass-through - inject Windows ROCm ComfyUI env vars into SwarmUI launching so they propagate to the self-launched backend - Modified Torch ROCm AOTriton activation EnVar to exclude gfx1152/1153 due to no support yet.
…lityMatrix into universal-rocm Deleted stale models from previous implementation state.
|
@gemini-code-assist recheck |
|
Thank you for the recheck request. I have reviewed the changes in this pull request, which introduces a centralized |
|
Refactored installation path to use the new multi-arch index, simplifying the torch install handling to a single command which the gfxarch for the user's GPU is pulled and integrated into the command used from resolved gfxarch, installing PyTorch modules and ROCm runtime in one go. Centralized most of ComfyUI’s Windows ROCm handling into the shared helper domain to make launch environment variable generation and reuse more consistent, and to support env-var passthrough for ComfyUI self-launch backends in SwarmUI. That Swarm-side integration is intentionally gated behind the expected operating environment and Windows ROCm compatibility checks, and is limited to launch-time passthrough rather than expanding Swarm’s install behavior. As part of that, a shared Windows ROCm Comfy profile was extracted so direct ComfyUI launches and Swarm-managed self-launches follow the same ROCm-specific behavior. Added global notice message sent to console output of Comfy and future integrated packages notifying user of experimental state of the Windows ROCm configuration and on issue reporting for triage so unnecessary issue reports get submitted upstream for if the issue has nothing to do with the WebUI package itself. (Used package install disclaimer instead for Wan2GP due to not being able to successfully getting it to show in console) Added a temporary exclusion for gfx1152 and gfx1153 from the AOTriton experimental EnVar passing since those architectures are not currently supported just yet from upstream, and added post-install torch verification so helper-managed installs confirm that the resulting torch build actually reports usable ROCm metadata after installation. Integration with the helper for reForge (and A3WebUI since it inherits a lot from it) was worked on and got functional, but required rather large dedicated functions for override and fallbacks due to missing modules in the 103x-all index and incompatibility with certain extension that comes with reforge, and setuptools issue. So rolled all that back and gave up on it for the time being but can more easily revisit it due to switching to the multi-arch install handling as this should alleviate a lot of the bloating of the helper and package configs I had previously when they were part of the implementation. Tested and verified compatibility and function with both R9700 (RDNA4) and 6900XT (RDNA2). Could not test older generation due to not having my Vega 64 anymore, but the special handling for legacy GPUs are already in place. Last thing is to look over the consideration of the other attention mechanism builds and acceleration library (bnb), along with possible option for the user to install the ROCm SDK devel module for if they need or wish to compile modules or extensions against their installed ROCm, in the package command menu before marking ready for review. |
1 participant
Introduces significant improvements to AMD GPU (ROCm) support and consolidates Windows ROCm support behind a shared helper and expands AMD GPU coverage across the current Windows-native ROCm path. The result is a more consistent install and launch flow for ROCm-capable packages, less duplicated package-specific logic, and broader support from Vega/GCN5 through the entire RDNA lineup. It also establishes the shared ROCm helper foundation that
ComfyUIandWan2GPnow use directly, with the same model intended to be reused by other AMD/ROCm-capable packages going forward.ROCm Support Integration and Refactoring:
Introduced the
IRocmPackageHelperdependency toPackageFactory,ComfyUI, andWan2GP, so ROCm compatibility checks, runtime/install context resolution, Windows-native package installation, and launch environment construction all flow through the same shared service instead of being reimplemented per package. This centralizes the Windows ROCm path and makes it easier to extend the same behavior to additional packages later. [1] [2] [3] [4] [5] [6] [7] [8]Refactored the Windows ROCm path in
ComfyUIaround the shared helper and a package-ownedWindowsRocmProfile, replacing hardcoded install/index handling with shared compatibility, install, and environment policy. This keeps the package-specific behavior limited to the pieces that actually need to remain package-specific while letting the helper own the common ROCm workflow. [1] [2] [3]Updated ROCm support detection and launch environment injection to use the centralized helper throughout the package startup. This makes ROCm eligibility checks, EnVar defaults, and runtime-specific overrides consistent across packages, while still allowing package-owned extras such as ComfyUI-specific
COMFYUI_ENABLE_MIOPEN. [1] [2] [3]This also fixes user-set EnVars in SM settings/Environment Variables not overriding the package configured EnVars due to immutability coded in
comfyui.cs's original Windows-ROCm package specific handling. Environment Variable injection flow is as follows: Helper Defaults > Package config > User-set. So the user-set variables are added as last step pulling them from SettingsManager, before finally being set into the package's launch flow. Prioritizing user variables over any previously injected variable of the same key if the user wishes to disable or modify a default variable.GPU Architecture and Compatibility Improvements:
Extended the AMD GPU architecture detection matrix in
GpuInfoto cover a wider set of Vega/GCN5, RDNA1, RDNA2, RDNA3/3.5, related handheld/mobile variants, and adding handling support for R9600 RDNA4 Pro GPU that was previously absent. Improving Windows ROCm coverage across the supported lineup instead of limiting support to a narrower subset of cards, as TheRock ROCm Technical Preview PyTorch builds exist now for Vega dGPUs, RDNA1 dGPUs, and practically the entire RDNA2 family. From Vega 56 all the way to RX 9070/R9700. This still excludes Radeon Instinct Vega/CDNA HPC/Datacenter GPUs due no official driver support and/or needing custom hacked drivers for Windows. [1] [2]Refactored ROCm compatibility checks in
GpuInfoandHardwareHelperto use sharedWindowsRocmSupportlogic, removing duplicated support tables and consolidating both support detection and architecture-based policy decisions in one place as a single source of truth in the domain of the ROCm helper. KeepingGpuInfoandHardwareHelperspecifically handling just GPU-name > gfxarch translation, and extracting of hardware information from the OS for the GPU installed on the user's system respectively.Simplifying further addition of future released GPU gfxarch translation, along with installation indexes and special environmental handling, to 2 dedicated files which can be updated and automatically apply globally to packages wired into the ROCm helper's call paths. [1] [2]
Other Installation and Launch Improvements:
Adjusted ComfyUI launch defaults to account for Windows ROCm architecture differences, including defaulting to legacy Windows ROCm GPUs to Quad Cross-Attention where that remains the better default. This keeps package launch behavior aligned with the shared architecture policy without hardcoding that policy in multiple places. [1] [2]
Updated package launch environment injection to use ROCm helper-generated variables and shared defaults, so ROCm-enabled installs consistently receive the expected runtime configuration on Windows while still leaving room for package-specific additions where needed. [1] [2] [3]
In Progress / Considerations for further development while still Draft PR status
triton-windows. With potiential gating to RDNA2 and older. (AOTriton Flash Attn 2 in RDNA3+ is preferrable for modern arch's)Other future considerations