Comprehensive ROCm helper for centralized Windows package integration and installation support

[NeuralFault]

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 ComfyUI and Wan2GP now 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 IRocmPackageHelper dependency to PackageFactory, ComfyUI, and Wan2GP, 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 ComfyUI around the shared helper and a package-owned WindowsRocmProfile, 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 GpuInfo to 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 GpuInfo and HardwareHelper to use shared WindowsRocmSupport logic, 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. Keeping GpuInfo and HardwareHelper specifically 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

• [SD WebUI Reforge Implemented] Expand the shared Windows ROCm helper wiring into additional packages, particularly A3 WebUI and SDForge variants (Forge / reForge), so they can reuse the same compatibility checks, package selection, install flow, and launch environment defaults now used by ComfyUI and Wan2GP. Adding the expansive support provided by the ROCm helper to these most popular additional packages.
• [Implemented] Improve SwarmUI Windows ROCm integration so the default ROCm launch environment is passed through when SwarmUI starts its self-launched ComfyUI backend, while also layering in user-set variables in SM Settings. This never happened previously, only user set variables were passed from SettingsManager, So variables that were hardcoded in original Win/ROCm handling in ComfyUI never got passed to the SwarmUI Comfy Self-Start backend leading to degraded performance unless the user specifically set them in SM Settings.
• [Implemented] Evaluate adding Flash Attention 2 support for legacy-architecture installs through AMD AITER using custom builds by 0xDELUXA, either as a default path where stable enough or as an optional Package Command action. With consideration for gating to RDNA2 and older. (RDNA3+ gets its own FA2 via AOTriton which is enabled by default if using modern arch's)
• [Implemented] Evaluate adding Sage Attention 1.0 as an optional Package Command install, including any required ops patching (sourced from ComfyUI-Zluda installation scripting needed for the Windows ROCm environment along with triton-windows. With potiential gating to RDNA2 and older. (AOTriton Flash Attn 2 in RDNA3+ is preferrable for modern arch's)
• [ROCm runtime implemented by default] Consider defaulting Windows ROCm installs to the runtime-only ROCm module set rather than the full ROCm + SDK module set, with fuller SDK components installable later through Package Commands if needed. The full SDK stack modules add considerable footprint to the overall size of the venv, installing just the ROCm core runtime modules can be preferrable but needs testing to verify. Potentially making installation of the SDK modules optional if the user intends to compile/build modules needing it at any point.
• [Implemented] Consider offering an optimized ROCm-aware bitsandbytes install path through the Package Command menu for packages and workflows that benefit from it. These would be prebuilt optimized wheels by 0xDELUXA that cover the entire Win-ROCm supported GPU lineup. Improves low quantization performance for GPUs that support it (needs verification of support variance)

Other future considerations

• Refactoring and package integration for future Linux install support for passing the same default environment variables for better user experience and performance when using AMD GPUs in a Linux environment with Stability Matrix.
• Expanding package integration to include other WebUI packages such as InvokeAI, AI Toolkit, Trainers, etc.
• [Implemented] Refactor build index decision and handling to use new multi-arch url format from TheRock. Consolidating the ROCm/PyTorch installation URLs to a single universal index and have the gfxarch applied in the pip command for the current GPU.

[gemini-code-assist]

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.

[NeuralFault]

@gemini-code-assist recheck

[gemini-code-assist]

Thank you for the recheck request. I have reviewed the changes in this pull request, which introduces a centralized IRocmPackageHelper to streamline Windows ROCm support across multiple packages like ComfyUI, Wan2GP, and future integrations. The refactoring effectively consolidates compatibility checks, installation logic, and environment variable management, reducing code duplication and improving maintainability. The extension of the GPU architecture detection matrix to include RDNA4 and additional Vega/RDNA variants is a significant improvement for broad hardware support. The implementation appears robust and follows the established architectural patterns of the project. No further issues identified.

[NeuralFault]

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. "torch[device-gfx###]" "torchvision[device-gfx###]" torchaudio --index-url https://rocm.nightlies.amd.com/whl-staging-multi-arch/

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.

[NeuralFault]

@gemini-code-assist recheck

[gemini-code-assist]

Thank you for the update and for providing such a comprehensive overview of the refactoring and improvements. The consolidation of the Windows ROCm logic into IRocmPackageHelper and the introduction of the multi-arch index handling are significant steps forward for maintainability and broad hardware support. The addition of the experimental notice and the post-install verification steps are also excellent additions for robustness. Since you have verified compatibility with RDNA2 and RDNA4 and addressed the environment variable passthrough for SwarmUI, this looks very solid. I have no further concerns at this time.

[NeuralFault]

Would also like to note, and possibly good for changelog if merged and hits release, that PyTorch TunableOp is intentionally disabled by default. Any user who has a cache database for it and wishes to continue using it and compile further optimized GEMM kernels will need to add PYTORCH_TUNABLEOP_ENABLED with a value of 1 to their environment variables in SM settings.

[NeuralFault]

The full ReadyToRun build exposed a latent runner bug that blocked installation of the ROCm development SDK module for the SageAttention and ROCm SDK package commands when it was not already installed in the ComfyUI venv, because pip show “not found” results were being raised as exceptions instead of being treated as a missing package state (null).

This change to pyrunner/uvrunner should be safe for other calls as the other call sites for it handle null intentionally and don't assume a non-null result without checking.

[NeuralFault]

@gemini-code-assist recheck

[gemini-code-assist]

Hi @mohnjiles, thank you for the detailed feedback. You've correctly identified that RocmPackageHelper.InstallWindowsNativePackageAsync and BaseGitPackage.StandardPipInstallProcessAsync share a significant amount of logic, which does introduce a risk of drift.

I agree that refactoring to keep the StandardPipInstallProcessAsync as the primary driver while allowing the RocmPackageHelper to own only the ROCm-specific installation steps (like the multi-arch torch install and verification) is a cleaner, more maintainable approach. This aligns with the existing SkipTorchInstall = true pattern and would definitely reduce the maintenance burden for future updates to the pip process.

I will look into refactoring the helper to provide a BuildWindowsPipInstallConfig method and a dedicated InstallWindowsRocmTorchAsync method, allowing packages to compose their installation flow as you suggested. This should resolve the duplication concern while keeping the ROCm-specific logic encapsulated.

[NeuralFault]

Implementation is complete with the initial WebUI package support for ComfyUI, SD WebUI Reforge, InvokeAI, SwarmUI, and Wan2GP.
Tested various GPU install configurations at install and launch time ensuring expected behavior for AMD GPU and Nvidia environments.

It is now in an intended state of general use and for future package support expansion.

Unless something else stands out that can be changed, ready for merge.

[ionite34]

Hi, so looking at the abstractions of the profiles and the creation of the static specific profiles, few things I want to note.

Swarm self-launching a Comfy backend means the profile has to be reachable outside ComfyUI class, and pulling COMFY_ENABLE_MIOPEN etc. out of the config, so ROCm stuff being in a designated place, not inlined per package seems fine, no pushback on that.

But the per-package static class pattern vs. just carrying the data or inheritance seems a bit like complexity and more code without any of the actual abstraction or inheritance benefits.

So a couple things:

1. The forwarders are basically indirecting code with negative value since the caller already holds the helper objects they pass in

// InvokeAiWindowsRocmProfile

public static bool HasSupport(IRocmPackageHelper? rocmPackageHelper)
{
    return GetCompatibility(rocmPackageHelper).IsCompatible;
}

public static IReadOnlyDictionary<string, string> BuildLaunchEnvironment(
    IRocmPackageHelper? rocmPackageHelper
)
{
    return rocmPackageHelper?.BuildLaunchEnvironment(Profile) ?? new Dictionary<string, string>();
}

These take the helper as an arg only to call a method on that same arg. The caller in InvokeAI already has rocmPackageHelper to pass it in, so it could just write rocmPackageHelper.BuildLaunchEnvironment(InvokeAiProfile) without needing the wrapper. Same for HasSupport, BuildLaunchEnvironment, ShouldUseWindowsNativeInstall, GetLaunchNoticeLines across reForge + Invoke, they're the package's own static class re-exposing the helper's methods pre-bound to a Profile static property.

2. The nullable + the ?? new Dictionary<>() guarding against it is kind of self-inflicted. PackageFactory injects a non-null IRocmPackageHelper into every package (PackageFactory.cs:65–294). StableSwarm and Wan2GP ctors correctly take it non-nullable. But ComfyUI/InvokeAI/Reforge declare IRocmPackageHelper? rocmPackageHelper = null, and InvokeAI.cs:302 then throws an "internal configuration error" to handle a null the factory never passes. The ?./?? in every forwarder exists only to service that impossible null. Drop the = null default → the nullable goes away → the defensive coalescing goes away → the throw goes away.

Which leads to the bigger structural bit:

3. It seems we built an instance abstraction and then bolted a static façade onto the side of it instead of through it.

RocmPackageProfile is already an instance type with init props, designed to be instantiated and subclassed. Wrapping it in static class XWindowsRocmProfile { static Profile { get; } = new()... } plus loose static methods means the per-package layer can't be polymorphic, injected, overridden, or substituted in tests.

And looking at the 8 members on InvokeAiWindowsRocmProfile, the only thing InvokeAI-specific is CreateInstallProfile (the py3.12 bitsandbytes-wheel branch). GetCompatibility, HasSupport, ShouldApplyLaunchEnvironment, BuildLaunchEnvironment, GetLaunchNoticeLines are byte-for-byte the same logic as reForge's (ReforgeWindowsRocmProfile). 5 identical forwarders in two different package-named static classes. That's the copy and paste the static pattern produces.

So my suggestion - I think instance subclasses of RocmPackageProfile is the pattern this was reaching for. Profile as an instance, package-specific behavior as a virtual override, shared dispatch is on the helper:

// base carries data + virtuals for the bits that actually vary per package
public class RocmPackageProfile
{
    public PipInstallConfig InstallConfig { get; init; } = new();
    public RocmEnvironmentOptions EnvironmentOptions { get; init; } = new();

    // package-specific hooks; default = no-op / inherit
    public virtual IReadOnlyDictionary<string, string> BuildExtraEnvironment(RocmRuntimeContext ctx) =>
        new Dictionary<string, string>();
}

// InvokeAI's profile is an instance subclass, only the genuinely specific bit lives here
public class InvokeAiRocmProfile : RocmPackageProfile
{
    private const string TritonWindowsPackage = "triton-windows";
    private const string BitsAndBytesWheelUrl = "https://github.com/0xDELUXA/...whl";

    public InvokeAiRocmProfile(PyVersion pyVersion)
    {
        var postTorch = pyVersion is { Major: 3, Minor: 12 }
            ? new[] { TritonWindowsPackage, BitsAndBytesWheelUrl }
            : [TritonWindowsPackage];
        InstallConfig = new PipInstallConfig { PostTorchInstallPipArgs = [.. postTorch] };
    }
}

and all the forwarders that are identical across packages move onto the helper, taking the profile instance as an arg perhaps:

// IRocmPackageHelper

bool ShouldApplyLaunchEnvironment(TorchIndex selectedTorchIndex);

IReadOnlyList<string> GetLaunchNoticeLines(TorchIndex selectedTorchIndex);

// BuildLaunchEnvironment(RocmPackageProfile) already exists

Call site then collapses from InvokeAiWindowsRocmProfile.BuildLaunchEnvironment(rocmPackageHelper) to rocmPackageHelper.BuildLaunchEnvironment(profile).

For Comfy's COMFYUI_ENABLE_MIOPEN (the modern-arch env that Swarm needs to pick up), that becomes the BuildExtraEnvironment override on ComfyRocmProfile, and Swarm just holds/references the same ComfyRocmProfile instance, making that work without a behavior-bearing static class.

Actual package specific stuff can be overrides: reForge's ApplyWindowsRocmLaunchDefaults (CUDA Malloc/Stream disabling, Reforge.cs:61) and GetPreferredCrossAttentionArgument are virtual members on the base overridden in ReforgeRocmProfile. So we just need to move the five identical ones to the helper, make the package specific ones overrides.

[NeuralFault]

@ionite34 The requested changes have been addressed. Let me know if there is anything further needed.

[mohnjiles]

Thank you!