[GH-ISSUE #29] HIP/ROCm support for AMD GPUs — working port on RX 9070 (gfx1201) #11

New issue

Open

opened 2026-10-26 22:23:30 +00:00 by bsakaguchi · 15 comments

bsakaguchi commented 2026-10-26 22:23:30 +00:00

Owner

Copy link

Originally created by @spheenik on GitHub (Mar 26, 2026).
Original GitHub issue: https://github.com/Comfy-Org/comfy-aimdo/issues/29

Hi there! 👋

I stumbled across the Dynamic VRAM blog post today and got really excited — this is exactly what I've been needing for my AMD setup. The post mentions AMD support is planned for the future, but I couldn't wait, so I fired up my slop generator (Claude Code) and about an hour later it came back with a working HIP port.

What I did

The entire port lives in a single file change to src/plat.h — an #ifdef __HIP_PLATFORM_AMD__ block at the top that maps all CUDA Driver API types and functions to their HIP equivalents. All .c files remain completely unmodified.

Key points:

• CUdeviceptr kept as unsigned long long (matching CUDA) with cast macros for HIP APIs that expect void* — preserves all upstream pointer arithmetic
• cuMemAllocHost wrapped to supply HIP's extra flags parameter
• cuGetErrorString wrapped to adapt HIP's direct-return API style
• pyt-cu-plug-alloc-async.c excluded from the build (the cudaMalloc/cudaFree symbol interposition is not portable to HIP, but the VBAR path that ComfyUI uses doesn't depend on it)

Test results (RX 9070, gfx1201, ROCm 7.2)

All HIP VMM APIs work correctly:

• hipMemAddressReserve — zero VRAM cost, as expected
• hipMemCreate / hipMemMap / hipMemSetAccess — physical VRAM allocated and accessible
• hipMemUnmap / hipMemRelease — clean deallocation
• Full VBAR allocate → fault → unpin lifecycle works

ComfyUI startup log:

comfy-aimdo inited for GPU: AMD Radeon RX 9070 (VRAM: 16304 MB)
DynamicVRAM support detected and enabled

Workflows that previously crashed with OOM (multi-model, full 1 megapixel resolution) now complete successfully with dynamic weight eviction working as intended.

The fork

I've pushed the change to a branch on my fork: spheenik/comfy-aimdo@hip-rocm-support

Happy to open a PR if you're interested. I understand you might want to approach this differently for an official implementation (CI, wheel builds, etc.) — just wanted to share that the HIP VMM APIs are there and working on RDNA 4, in case it's useful for your roadmap.

Build instructions (for anyone who wants to try)

gcc -shared -fPIC -O2 -D__HIP_PLATFORM_AMD__ -Isrc \
    -I/opt/rocm/include -L/opt/rocm/lib \
    src/vrambuf.c src/model-vbar.c src/control.c src/hostbuf.c \
    src/debug.c src/pyt-cu-plug-alloc.c src-posix/model-mmap.c \
    -lamdhip64 -o aimdo.so

Then replace the CUDA aimdo.so inside the comfy_aimdo pip package directory and start ComfyUI with --enable-dynamic-vram.

Thanks for the great work on AIMDO — it's a game changer!

Originally created by @spheenik on GitHub (Mar 26, 2026). Original GitHub issue: https://github.com/Comfy-Org/comfy-aimdo/issues/29 Hi there! 👋 I stumbled across the [Dynamic VRAM blog post](https://blog.comfy.org/p/dynamic-vram-in-comfyui-saving-local) today and got really excited — this is exactly what I've been needing for my AMD setup. The post mentions AMD support is planned for the future, but I couldn't wait, so I fired up my slop generator (Claude Code) and about an hour later it came back with a working HIP port. ## What I did The entire port lives in a single file change to `src/plat.h` — an `#ifdef __HIP_PLATFORM_AMD__` block at the top that maps all CUDA Driver API types and functions to their HIP equivalents. All `.c` files remain completely unmodified. **Key points:** - `CUdeviceptr` kept as `unsigned long long` (matching CUDA) with cast macros for HIP APIs that expect `void*` — preserves all upstream pointer arithmetic - `cuMemAllocHost` wrapped to supply HIP's extra `flags` parameter - `cuGetErrorString` wrapped to adapt HIP's direct-return API style - `pyt-cu-plug-alloc-async.c` excluded from the build (the `cudaMalloc`/`cudaFree` symbol interposition is not portable to HIP, but the VBAR path that ComfyUI uses doesn't depend on it) ## Test results (RX 9070, gfx1201, ROCm 7.2) All HIP VMM APIs work correctly: - `hipMemAddressReserve` — zero VRAM cost, as expected - `hipMemCreate` / `hipMemMap` / `hipMemSetAccess` — physical VRAM allocated and accessible - `hipMemUnmap` / `hipMemRelease` — clean deallocation - Full VBAR allocate → fault → unpin lifecycle works ComfyUI startup log: ``` comfy-aimdo inited for GPU: AMD Radeon RX 9070 (VRAM: 16304 MB) DynamicVRAM support detected and enabled ``` Workflows that previously crashed with OOM (multi-model, full 1 megapixel resolution) now complete successfully with dynamic weight eviction working as intended. ## The fork I've pushed the change to a branch on my fork: [spheenik/comfy-aimdo@hip-rocm-support](https://github.com/spheenik/comfy-aimdo/compare/master...spheenik:comfy-aimdo:hip-rocm-support) Happy to open a PR if you're interested. I understand you might want to approach this differently for an official implementation (CI, wheel builds, etc.) — just wanted to share that the HIP VMM APIs are there and working on RDNA 4, in case it's useful for your roadmap. ## Build instructions (for anyone who wants to try) ```bash gcc -shared -fPIC -O2 -D__HIP_PLATFORM_AMD__ -Isrc \ -I/opt/rocm/include -L/opt/rocm/lib \ src/vrambuf.c src/model-vbar.c src/control.c src/hostbuf.c \ src/debug.c src/pyt-cu-plug-alloc.c src-posix/model-mmap.c \ -lamdhip64 -o aimdo.so ``` Then replace the CUDA `aimdo.so` inside the `comfy_aimdo` pip package directory and start ComfyUI with `--enable-dynamic-vram`. Thanks for the great work on AIMDO — it's a game changer!

bsakaguchi commented 2026-10-26 22:23:33 +00:00

Author

Owner

Copy link

@spheenik commented on GitHub (Mar 26, 2026):

A few clarifications to keep expectations honest:

What was actually tested:

• All HIP VMM APIs individually via a C smoke test (hipMemAddressReserve, hipMemCreate, hipMemMap, hipMemSetAccess, hipMemUnmap, hipMemRelease + readback verification)
• VBAR allocate → fault → unpin lifecycle through the Python ctypes bindings
• One real ComfyUI workflow that previously OOM'd — it completed at full resolution, which implies eviction is working (the model weights didn't fit in VRAM all at once)

What was NOT tested:

• Any GPU other than RX 9070 (gfx1201)
• Any ROCm version other than 7.2
• Long-running stability / memory leaks over many workflows
• The pyt-cu-plug-alloc-async.c path (excluded from build — the cudaMalloc symbol interposition doesn't have a straightforward HIP equivalent)

Build environment:

• Arch Linux host, gcc 15.1, ROCm 7.2 (hip-runtime-amd package)
• Built natively on the machine with the GPU — not tested in any CI or cross-compile setup

So this is very much a "works on my machine" proof of concept, but at least it shows the HIP VMM APIs are functional on RDNA 4 consumer hardware and the AIMDO architecture ports cleanly.

<!-- gh-comment-id:4134006843 --> @spheenik commented on GitHub (Mar 26, 2026): A few clarifications to keep expectations honest: **What was actually tested:** - All HIP VMM APIs individually via a C smoke test (`hipMemAddressReserve`, `hipMemCreate`, `hipMemMap`, `hipMemSetAccess`, `hipMemUnmap`, `hipMemRelease` + readback verification) - VBAR allocate → fault → unpin lifecycle through the Python ctypes bindings - One real ComfyUI workflow that previously OOM'd — it completed at full resolution, which implies eviction is working (the model weights didn't fit in VRAM all at once) **What was NOT tested:** - Any GPU other than RX 9070 (gfx1201) - Any ROCm version other than 7.2 - Long-running stability / memory leaks over many workflows - The `pyt-cu-plug-alloc-async.c` path (excluded from build — the `cudaMalloc` symbol interposition doesn't have a straightforward HIP equivalent) **Build environment:** - Arch Linux host, gcc 15.1, ROCm 7.2 (`hip-runtime-amd` package) - Built natively on the machine with the GPU — not tested in any CI or cross-compile setup So this is very much a "works on my machine" proof of concept, but at least it shows the HIP VMM APIs are functional on RDNA 4 consumer hardware and the AIMDO architecture ports cleanly.

bsakaguchi commented 2026-10-26 22:23:33 +00:00

Author

Owner

Copy link

@woct0rdho commented on GitHub (Mar 26, 2026):

Have you checked https://github.com/Comfy-Org/comfy-aimdo/pull/2 ?

<!-- gh-comment-id:4134774173 --> @woct0rdho commented on GitHub (Mar 26, 2026): Have you checked https://github.com/Comfy-Org/comfy-aimdo/pull/2 ?

bsakaguchi commented 2026-10-26 22:23:33 +00:00

Author

Owner

Copy link

@spheenik commented on GitHub (Mar 26, 2026):

I found it only afterwards. Sorry. But I did not have the problems mentioned in #2. And I found this approach to be less invasive, and wanted to share it anyway. FWIW.

I would be happy to improve this into something that also works on Windows, and does not monkey patch CUDA out.

<!-- gh-comment-id:4134980840 --> @spheenik commented on GitHub (Mar 26, 2026): I found it only afterwards. Sorry. But I did not have the problems mentioned in #2. And I found this approach to be less invasive, and wanted to share it anyway. FWIW. I would be happy to improve this into something that also works on Windows, and does not monkey patch CUDA out.

bsakaguchi commented 2026-10-26 22:23:33 +00:00

Author

Owner

Copy link

@rattus128 commented on GitHub (Mar 28, 2026):

Yeah this is well discussed and underway in #2. Ill catch up soon!

<!-- gh-comment-id:4146146211 --> @rattus128 commented on GitHub (Mar 28, 2026): Yeah this is well discussed and underway in #2. Ill catch up soon!

bsakaguchi commented 2026-10-26 22:23:33 +00:00

Author

Owner

Copy link

@jnolck commented on GitHub (Mar 31, 2026):

I don't think it's working as intended. If I enable it, it makes my generation times a bit longer on workflows that don't spill over. Maybe I'm doing something wrong. It compiled just fine and I manually moved the *.so over to the installation folder. '''Total VRAM 20464 MB, total RAM 63561 MB
pytorch version: 2.10.0+rocm7.13.0a20260330
Set: torch.backends.cudnn.enabled = False for better AMD performance.
AMD arch: gfx1100
ROCm version: (7, 13)
Set vram state to: NORMAL_VRAM
Disabling smart memory management
Device: cuda:0 AMD Radeon RX 7900 XT : native
Using async weight offloading with 2 streams
Enabled pinned memory 60382.0
DEBUG: C++ CK Backend successfully loaded and forced via env var.
Using CK Flash Attention
Python version: 3.12.13 (main, Mar 26 2026, 00:00:00) [GCC 16.0.1 20260321 (Red Hat 16.0.1-0)]
ComfyUI version: 0.18.1
comfy-aimdo version: 0.2.12
comfy-kitchen version: 0.2.8
ComfyUI frontend version: 1.42.8'''

<!-- gh-comment-id:4164556095 --> @jnolck commented on GitHub (Mar 31, 2026): I don't think it's working as intended. If I enable it, it makes my generation times a bit longer on workflows that don't spill over. Maybe I'm doing something wrong. It compiled just fine and I manually moved the *.so over to the installation folder. '''Total VRAM 20464 MB, total RAM 63561 MB pytorch version: 2.10.0+rocm7.13.0a20260330 Set: torch.backends.cudnn.enabled = False for better AMD performance. AMD arch: gfx1100 ROCm version: (7, 13) Set vram state to: NORMAL_VRAM Disabling smart memory management Device: cuda:0 AMD Radeon RX 7900 XT : native Using async weight offloading with 2 streams Enabled pinned memory 60382.0 DEBUG: C++ CK Backend successfully loaded and forced via env var. Using CK Flash Attention Python version: 3.12.13 (main, Mar 26 2026, 00:00:00) [GCC 16.0.1 20260321 (Red Hat 16.0.1-0)] ComfyUI version: 0.18.1 comfy-aimdo version: 0.2.12 comfy-kitchen version: 0.2.8 ComfyUI frontend version: 1.42.8''' <img width="1920" height="1080" alt="Image" src="https://github.com/user-attachments/assets/830fceef-1e64-4a88-b74c-5d18f203440f" />

bsakaguchi commented 2026-10-26 22:23:33 +00:00

Author

Owner

Copy link

@spheenik commented on GitHub (Mar 31, 2026):

Thanks for testing this! Looking at your log output though, I don't think the HIP VMM backend is actually active in your setup.

When AIMDO's memory manager initializes successfully, it prints a line like this:

aimdo: control.c:68:INFO:comfy-aimdo inited for GPU: AMD Radeon RX 7900 XT (VRAM: 20464 MB)

On our end (RX 9070, ROCm 7.2), we see this message followed by DynamicVRAM support detected and enabled:

aimdo: control.c:68:INFO:comfy-aimdo inited for GPU: AMD Radeon RX 9070 (VRAM: 16304 MB)
DynamicVRAM support detected and enabled

Both lines are missing from your log, which means init() was never called — so the HIP VMM interposition isn't running. The slowdown you're seeing is likely coming from something else.

Could you double-check:

• Where exactly you placed the .so file?
• Whether you set any environment variables to enable the HIP backend?

Also worth noting: this was only tested on gfx1201 (RX 9070) with ROCm 7.2, so there may be additional steps needed on gfx1100. Happy to help debug further!

<!-- gh-comment-id:4164718298 --> @spheenik commented on GitHub (Mar 31, 2026): Thanks for testing this! Looking at your log output though, I don't think the HIP VMM backend is actually active in your setup. When AIMDO's memory manager initializes successfully, it prints a line like this: ``` aimdo: control.c:68:INFO:comfy-aimdo inited for GPU: AMD Radeon RX 7900 XT (VRAM: 20464 MB) ``` On our end (RX 9070, ROCm 7.2), we see this message followed by `DynamicVRAM support detected and enabled`: ``` aimdo: control.c:68:INFO:comfy-aimdo inited for GPU: AMD Radeon RX 9070 (VRAM: 16304 MB) DynamicVRAM support detected and enabled ``` Both lines are missing from your log, which means `init()` was never called — so the HIP VMM interposition isn't running. The slowdown you're seeing is likely coming from something else. Could you double-check: - Where exactly you placed the `.so` file? - Whether you set any environment variables to enable the HIP backend? Also worth noting: this was only tested on gfx1201 (RX 9070) with ROCm 7.2, so there may be additional steps needed on gfx1100. Happy to help debug further!

bsakaguchi commented 2026-10-26 22:23:33 +00:00

Author

Owner

Copy link

@jnolck commented on GitHub (Mar 31, 2026):

I didn't notice that! I manually put mv aimdo.so ../../.venv/lib/python3.12/site-packages/comfy_aimdo/
aimdo.so host_buffer.py model_vbar.py torch.py
control.py model_mmap.py pycache/ _version.py . I copy pasted that after that crash, but it was enabled during it. I just tried to run a workflow at 1280x720, something I normally wouldn't try since I know it'll OOM.

'''Total VRAM 20464 MB, total RAM 63561 MB
pytorch version: 2.10.0+rocm7.13.0a20260330
Set: torch.backends.cudnn.enabled = False for better AMD performance.
AMD arch: gfx1100
ROCm version: (7, 13)
Set vram state to: NORMAL_VRAM
Device: cuda:0 AMD Radeon RX 7900 XT : native
Using async weight offloading with 2 streams
Enabled pinned memory 60382.0
DEBUG: C++ CK Backend successfully loaded and forced via env var.
Using CK Flash Attention (Forced)
aimdo: src/control.c:68:INFO:comfy-aimdo inited for GPU: AMD Radeon RX 7900 XT (VRAM: 20464 MB)
DynamicVRAM support detected and enabled
Python version: 3.12.13 (main, Mar 26 2026, 00:00:00) [GCC 16.0.1 20260321 (Red Hat 16.0.1-0)]
ComfyUI version: 0.18.1
comfy-aimdo version: 0.2.12
comfy-kitchen version: 0.2.8
ComfyUI frontend version: 1.42.8
[Prompt Server] web root: /home/jnolck/src/ComfyUI/.venv/lib64/python3.12/site-packages/comfyui_frontend_package/static
Asset seeder disabled'''
I did not set any env variables. If there's something I'm supposed to set let me know. I have no idea how any of this works, so I don't even know what to look at or look for.

<!-- gh-comment-id:4165194726 --> @jnolck commented on GitHub (Mar 31, 2026): I didn't notice that! I manually put mv aimdo.so ../../.venv/lib/python3.12/site-packages/comfy_aimdo/ aimdo.so host_buffer.py model_vbar.py torch.py control.py model_mmap.py __pycache__/ _version.py . I copy pasted that after that crash, but it was enabled during it. I just tried to run a workflow at 1280x720, something I normally wouldn't try since I know it'll OOM. '''Total VRAM 20464 MB, total RAM 63561 MB pytorch version: 2.10.0+rocm7.13.0a20260330 Set: torch.backends.cudnn.enabled = False for better AMD performance. AMD arch: gfx1100 ROCm version: (7, 13) Set vram state to: NORMAL_VRAM Device: cuda:0 AMD Radeon RX 7900 XT : native Using async weight offloading with 2 streams Enabled pinned memory 60382.0 DEBUG: C++ CK Backend successfully loaded and forced via env var. Using CK Flash Attention (Forced) aimdo: src/control.c:68:INFO:comfy-aimdo inited for GPU: AMD Radeon RX 7900 XT (VRAM: 20464 MB) DynamicVRAM support detected and enabled Python version: 3.12.13 (main, Mar 26 2026, 00:00:00) [GCC 16.0.1 20260321 (Red Hat 16.0.1-0)] ComfyUI version: 0.18.1 comfy-aimdo version: 0.2.12 comfy-kitchen version: 0.2.8 ComfyUI frontend version: 1.42.8 [Prompt Server] web root: /home/jnolck/src/ComfyUI/.venv/lib64/python3.12/site-packages/comfyui_frontend_package/static Asset seeder disabled''' I did not set any env variables. If there's something I'm supposed to set let me know. I have no idea how any of this works, so I don't even know what to look at or look for.

bsakaguchi commented 2026-10-26 22:23:33 +00:00

Author

Owner

Copy link

@spheenik commented on GitHub (Mar 31, 2026):

That looks much better — AIMDO is active now!

On my machine, this is exactly what made the difference: workflows that previously OOM'd ran through successfully with DynamicVRAM enabled. No extra env variables needed.

In my case, it always crashed during VAE decode. Since the HIP patch, AIMDO evicts older allocations at that point and the workflow completes cleanly.

Did the 1280x720 workflow complete this time?

<!-- gh-comment-id:4165837149 --> @spheenik commented on GitHub (Mar 31, 2026): That looks much better — AIMDO is active now! On my machine, this is exactly what made the difference: workflows that previously OOM'd ran through successfully with DynamicVRAM enabled. No extra env variables needed. In my case, it always crashed during VAE decode. Since the HIP patch, AIMDO evicts older allocations at that point and the workflow completes cleanly. Did the 1280x720 workflow complete this time?

bsakaguchi commented 2026-10-26 22:23:34 +00:00

Author

Owner

Copy link

@jnolck commented on GitHub (Apr 8, 2026):

I ended up porting it myself because I thought there was something something wrong with your port and in the process discovered that only the standard comfyui nodes work with aimdo (until those other nodes wrap things around ModelVBAR, like the comfy ones do). I was using a gguf loader so aimdo wouldn't get activated. I couldn't use fp8 or fp16 standard models I'd have to use gguf q6 or less to not crash amdgpu. That's what happened. Now I can even run ltx 2.3.

Use standard ComfyUI nodes if you want to try this.

<!-- gh-comment-id:4208930990 --> @jnolck commented on GitHub (Apr 8, 2026): I ended up porting it myself because I thought there was something something wrong with your port and in the process discovered that only the standard comfyui nodes work with aimdo (until those other nodes wrap things around ModelVBAR, like the comfy ones do). I was using a gguf loader so aimdo wouldn't get activated. I couldn't use fp8 or fp16 standard models I'd have to use gguf q6 or less to not crash amdgpu. That's what happened. Now I can even run ltx 2.3. Use standard ComfyUI nodes if you want to try this.

bsakaguchi commented 2026-10-26 22:23:34 +00:00

Author

Owner

Copy link

@asagi4 commented on GitHub (Apr 13, 2026):

Are you running this on Windows only? If not, this'll have the same memory leak issue that I found in my port unless you're using a fixed version of hipruntime already (the bug is not in AIMDO, but in the HIP runtime), but I don't think the fix is in a release yet.

<!-- gh-comment-id:4236382687 --> @asagi4 commented on GitHub (Apr 13, 2026): Are you running this on Windows only? If not, this'll have the same memory leak issue that I found in my port unless you're using a fixed version of hipruntime already (the bug is not in AIMDO, but in the HIP runtime), but I don't think the fix is in a release yet.

bsakaguchi commented 2026-10-26 22:23:34 +00:00

Author

Owner

Copy link

@spheenik commented on GitHub (Apr 13, 2026):

Good catch — Linux only, ROCm 7.2.1 on Arch.

I just ran a reproducer based on your test from ROCm/ROCm#6021 and can confirm: hipMemUnmap + hipMemRelease without hipMemAddressFree does not free any VRAM on my system. The 1 GiB stays allocated even though all API calls return hipSuccess. So yes, the AIMDO eviction path is silently broken here.

My original testing only covered single-workflow runs where eviction happened once (VAE decode), so I wouldn't have noticed the leak across multiple cycles.

The fix in rocm-systems#4363 was merged April 1st — do you know if it's in TheRock nightlies yet? I'm on the Arch rocm-hip-sdk package (7.2.1) so I'll need to either rebuild libhsa-runtime64 from the patched source or wait for it to land downstream.

<!-- gh-comment-id:4236698348 --> @spheenik commented on GitHub (Apr 13, 2026): Good catch — Linux only, ROCm 7.2.1 on Arch. I just ran a reproducer based on your test from ROCm/ROCm#6021 and can confirm: `hipMemUnmap` + `hipMemRelease` without `hipMemAddressFree` does **not** free any VRAM on my system. The 1 GiB stays allocated even though all API calls return `hipSuccess`. So yes, the AIMDO eviction path is silently broken here. My original testing only covered single-workflow runs where eviction happened once (VAE decode), so I wouldn't have noticed the leak across multiple cycles. The fix in rocm-systems#4363 was merged April 1st — do you know if it's in TheRock nightlies yet? I'm on the Arch `rocm-hip-sdk` package (7.2.1) so I'll need to either rebuild `libhsa-runtime64` from the patched source or wait for it to land downstream.

bsakaguchi commented 2026-10-26 22:23:34 +00:00

Author

Owner

Copy link

@asagi4 commented on GitHub (Apr 13, 2026):

@spheenik building the hip runtime by yourself is not too difficult, but as a workaround you can just add a manual mmap call: https://github.com/Comfy-Org/comfy-aimdo/pull/2/changes/9719699d3a37c91aa675bc9f41fe88f943fc1346
That does the same thing as the proper fix.

<!-- gh-comment-id:4236777525 --> @asagi4 commented on GitHub (Apr 13, 2026): @spheenik building the hip runtime by yourself is not too difficult, but as a workaround you can just add a manual mmap call: https://github.com/Comfy-Org/comfy-aimdo/pull/2/changes/9719699d3a37c91aa675bc9f41fe88f943fc1346 That does the same thing as the proper fix.

bsakaguchi commented 2026-10-26 22:23:34 +00:00

Author

Owner

Copy link

@0xDELUXA commented on GitHub (Jul 22, 2026):

@spheenik Is this issue still relevant?

<!-- gh-comment-id:5045119670 --> @0xDELUXA commented on GitHub (Jul 22, 2026): @spheenik Is this issue still relevant?

bsakaguchi commented 2026-10-26 22:23:34 +00:00

Author

Owner

Copy link

@spheenik commented on GitHub (Oct 4, 2026):

I am unsure because I didn't test it in a while but you can close it. I will open another one if it is still relevant. Thank you.

<!-- gh-comment-id:5981115123 --> @spheenik commented on GitHub (Oct 4, 2026): I am unsure because I didn't test it in a while but you can close it. I will open another one if it is still relevant. Thank you.

bsakaguchi commented 2026-10-26 22:23:35 +00:00

Author

Owner

Copy link

@0xDELUXA commented on GitHub (Oct 4, 2026):

I am unsure because I didn't test it in a while but you can close it. I will open another one if it is still relevant. Thank you.

I don’t have write permissions, so pinging @rattus128 here since this issue is no longer relevant and can be closed.

<!-- gh-comment-id:5982811882 --> @0xDELUXA commented on GitHub (Oct 4, 2026): > I am unsure because I didn't test it in a while but you can close it. I will open another one if it is still relevant. Thank you. I don’t have write permissions, so pinging @rattus128 here since this issue is no longer relevant and can be closed.

bsakaguchi referenced this issue 2026-10-26 22:24:12 +00:00

[PR #11] [MERGED] model_vbar: Add vbars_analyze to get VBAR VRAM #60

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

master

prs/cuda-not-ready-retry

prs/vbar-writeback

dev/windows-integrated-cuda

prs/mcdm-dxcore

dev/mcdm-dxcore

prs/null-guard-phys-free

dev/windows-integrated-ram

chore/node-runtime-refresh-2026-09-28

dev/alias-range-search-review

dev/disk-id

dev/non-graph-free

comfyanonymous-patch-1

prs/memory-compiler-abort

dev/malloc-graph-rogues

prs/memory-compiler

dev/malloc-graph-capture-finalize

dev/malloc-graph-stream-debug

prs/nvml-512

dev/nvml-pressure-headroom-768mb

fix/cla-api-failure-handling

dev/memory-graph-compiler-review-v2

dev/nvml-pressure-headroom-1gb

dev/nvml-pressure-headroom-512mb

dev/memory-graph-cuda-graphs

dev/memory-graph-scope-diagnostics

dev/cuda-capture-pressure-fix

dev/memory-graph-variable-calls

dev/memory-graph-linked-events

dev/competition-green

dev/competition-blue

dev/competition-yellow

dev/primary-load-default-stream

dev/threaded-loaded-errors

dev/remove-legacy-cla

dev/async-clamp

dev/nvml

dev/loop-graph-cache-series

dev/loop-malloc-compiler

dev/detail

dev/no-sequential-scan-benchmark

dev/threaded-loader-2

dev/protected-mem

dev/threaded-loader-3

alexisrolland-patch-2

alexisrolland-patch-1

dev/xpu-support

xpu-support

add-cla-workflow

dev/double-sync

dev/simple-miss-alloc

dev/mem-exp

dev/vbar-waterbug

dev/set-watermark

dev/multi-gpu-ring-split

dev/threaded-mmap

dev/direct-read

dev/mark-cold

dev/hostbuf-truncate-0-fix

dev/v4-cleanup

dev/sync-prewarm

dev/hostbuf-unreg

dev/dgx-spark

dev/unified-memory

stable-0.2

multigpu-thread-safety

multigpu-phase6

dev/213-general

dev/no-win-cudart

dev/vanilla-cuda-malloc

dev/memcpy

dev/threaded-gc

dev/lock-async-list

dev/vbar-virt-lead

dev/vbars-analyze

dev/less-throttle

dev/mallocs

prs/cleanup

dev/empty-cache

dev/torch-gc

dev/rattus/rbar

v0.6.0

v0.5.6

v0.5.5

v0.5.4

v0.5.3

v0.5.2

v0.5.1

v0.5.0

v0.4.15

v0.4.14

v0.4.13

v0.4.12

v0.4.11

v0.4.10

v0.4.9

v0.4.8

v0.4.7

v0.4.6

v0.4.5

v0.4.4

v0.4.3

v0.4.2

v0.4.1

v0.4.0

v0.3.0

v0.2.14

v0.0.214

v0.0.213

v0.2.12

v0.2.11

v0.2.10

v0.2.9

v0.2.8

v0.2.7

v0.2.6

v0.2.5

v0.2.4

v0.2.3

v0.2.2

v0.2.1

v0.2.0

v0.1.8

v0.1.7

v0.1.6

v0.1.5

v0.1.4

v0.1.3

v0.1.2

v0.1.1

v0.1.0

v0.0.4

v0.0.3

v0.0.2

v0.0.1

v0.0.0

Labels

Clear labels   

pull-request

Mirrored from GitHub Pull Request

No labels

pull-request

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

Comfy-Org/comfy-aimdo#11

No description provided.