ROCMVAEPerformanceMonitor

The VAE is the codec that turns your latent into a viewable image, and on AMD it's a common source of grief - wrong precision, wrong tile size, and suddenly you're OOMing or getting banding you can't explain. This node is the ROCm Ninodes pack's VAE checkup. You connect a VAE, it inspects your GPU and the VAE's type, and returns three text reports telling you what precision and settings to use. It doesn't run a benchmark and it doesn't change anything - it reads your setup and advises.

What it tells you

Two inputs: vae (the VAE object from your loader) and test_resolution (default 1024) - a hint for the recommendations, not an actual test. Three STRING outputs, each wired to a Show Text node:

• DEVICE_INFO - device, VAE dtype, output device, VAE type, GPU name, architecture, and whether you're on an APU (unified memory).
• PERFORMANCE_TIPS - the useful one, because it's type-aware. It detects whether your VAE is LTX Video (128-channel, 32x spatial compression - advises fp16 and full-video causal decode), WAN (advises full-video passes to avoid frame jitter), a pixel-space passthrough (z-image - tells you no decode is even needed), or a standard VAE, and gives advice for each.
• OPTIMAL_SETTINGS - concrete recommendations: tile size, overlap, precision, batch optimization, and whether temporal tiling is available for video.

The source shows it's genuinely reading your hardware - it checks the VAE's dtype and output device, pulls the GPU's architecture string, and tailors everything to whether you're on an APU. The LTX advice in particular ("for videos >200 frames, enable temporal tiling with chunk_size=16, overlap=2") lines up exactly with the pack's decode-node defaults, so the recommendations are the real settings, not generic boilerplate.

The honest framing

This is a diagnostic you run a couple of times, not a fixture. The right pattern: load your model, connect this node, read the OPTIMAL_SETTINGS output, apply those numbers to the pack's ROCm VAE Decode node, then delete the monitor. It's especially good for the "why is my video decode banding / OOMing" moment, because it tells you which VAE family you're actually dealing with - a surprisingly common source of confusion when a workflow uses a non-standard VAE and you've been tuning it like an SDXL one.

Two caveats from the README: the outputs are STRINGs, so if you don't connect Show Text nodes you'll see nothing and think it's broken. And remember the pack's bias - it's tested primarily on gfx1151 / Strix Halo, so on other AMD chips treat the numbers as a strong starting point, not a law. On NVIDIA it still analyzes your VAE fine, but the recommendations skew toward the ROCm world.

Install

Part of ROCm Ninodes - ComfyUI Manager → search "ROCm Ninodes," or

cd ComfyUI/custom_nodes
git clone https://github.com/iGavroche/rocm-ninodes.git

Restart, under ROCm Ninodes → VAE. Light deps (numpy, Pillow, psutil, gguf, safetensors), no model downloads. If the output says "CUDA not available" or looks hollow, that's usually the giveaway that your PyTorch isn't the ROCm build - a stack problem worth fixing before this or any pack node will behave.