Describe the bug

We observed a visible, partially transparent purple stripe when decoding Qwen-Image-2.1 latents with AutoencoderKLQwenImage21 spatial tiling on AMD Radeon 8060S (gfx1151), using BF16.

This report provides controlled numerical observations and local workarounds. It does not establish a specific faulty layer, a ROCm defect, or UC-BF16 specificity.

Findings

• Decoding the same saved VAE input with tiling enabled produced RGB/alpha seams; disabling tiling substantially reduced them.
• Captured decoder tile outputs already contained RGB/alpha discrepancies near internal tile edges, before blending.
• Recombining those captured tiles reproduced the original tiled RGBA output exactly.
• In one controlled case, the minimum alpha in the affected stripe increased from 220 to 254 after applying the workarounds.
• The user visually inspected generated images in our local Testbed WebUI and confirmed that the previously visible purple stripe was no longer visible.

Local workarounds

1. Exclude 16 output pixels at internal tile borders and blend the remaining overlap using shared RGBA weights and FP32 accumulation.
2. Disable independent spatial VAE tiling, retain full decoder spatial context, and split only Conv2d output rows with the required input halo. We used 128-row blocks and explicitly selected MIOPEN_FIND_MODE=FAST.

Neither method forces alpha to opaque or modifies the exported PNG to hide the stripe.

The full-context method was validated at 1152×1152, 1376×1024, and 1024×1376. Synchronized decode times were approximately 2.0–3.4 seconds in normal generation.

Local RGB differences remain: up to 15 levels versus the later untiled FAST reference, and up to 25 levels between diagnostic and normal application decoding with matching decoder-input hashes. Repeatability within the normal pipeline is separate from equivalence to untiled decoding. Exhaustive fine-detail visual evaluation remains incomplete.

Related discussion: #14866

No images, private latent tensors, prompts, EXIF, or raw logs are attached. A public, self-contained reproducer of the visible symptom is not yet available. The workarounds are offered for technical discussion, not as a universal upstream fix.

Reproduction

A public, self-contained reproducer of the visible symptom is not yet available. The controlled comparison used a privately retained regenerated latent, which cannot be attached. The following describes the procedure actually tested; it is not a copy-and-paste reproducer.

1. Capture the actual unpacked, inverse-normalized BF16 VAE input and retain the same tensor for all decodes.
2. For the primary case, the decoder input shape was [1, 64, 1, 86, 64], producing a 1024×1376 RGBA image.
3. Enable spatial tiling with output tile size 512×512 and stride 384×384, giving 128-pixel overlap. These settings were explicitly overridden, not constructor defaults.
4. Decode that input with tiling enabled and capture raw tile outputs before blending.
5. Disable tiling and decode the identical input as a full-frame reference.
6. Apply identical output denormalization, clamping and 8-bit RGBA conversion to both results.
7. Compare RGB and alpha near internal tile boundaries.

The tiled output showed a purple stripe and alpha depression. The captured raw tiles already disagreed near internal edges, and recombining them reproduced the tiled RGBA output exactly.

Two local workarounds reduced the observed artifact:

• Exclude 16 output pixels at internal tile borders before weighted blending.
• Preserve full decoder spatial context while splitting only Conv2d output rows with the required halo, using 128-row blocks and explicitly setting MIOPEN_FIND_MODE=FAST before the first MIOpen operation.

A synthetic-input diagnostic candidate has only been syntax-checked. It has not been executed and is not claimed to reproduce this symptom.

Would maintainers prefer this evidence as a follow-up to PR #14866 rather than a separate issue?

The attached public_workaround.patch.txt contains the two tested local helper implementations. It is a code example, not a patch against diffusers internals or a self-contained symptom reproducer. Application-level resolution checks are not included.
public_workaround.patch

Logs

No raw logs are attached because they may contain private application data. The numerical observations and validation limits are reported above. This report concerns RGB/alpha output artifacts rather than a Python exception.

System Info

Recorded test environment; this is not output from diffusers-cli env.

• GPU: AMD Radeon 8060S / Strix Halo / gfx1151, shared memory architecture
• OS: Ubuntu 26.04 LTS, x86_64
• Kernel: initially 7.0.0-34-generic; final tests on 7.0.0-38-generic
• Python: 3.12; exact patch version not established
• PyTorch: 2.10.0+rocm7.13.0a20260513, gfx1151 nightly wheel
• System ROCm: 7.2.2; distinct from components bundled with PyTorch
• diffusers: 0.41.0.dev0
• diffusers commit: cc8644b
• transformers: 5.17.0
• VAE: AutoencoderKLQwenImage21, existing Qwen-Image-2.1 VAE
• VAE dtype: BF16
• VAE latent/output channels: 64 / 4 (RGBA)
• Spatial compression ratio: 16
• patch_size: null
• Tested frame count: 1
• Generation transformer: third-party UC-BF16 derived from Qwen-Image-2.1; no official-transformer control was performed
• MIOpen: exact loaded version not established; final successful configuration explicitly used MIOPEN_FIND_MODE=FAST
• Mesa: initially 26.0.3; final 26.0.8-1ubuntu0.3 (RADV used by a separate co-resident Vulkan workload)

PyTorch, diffusers, transformer weights and VAE weights were retained across the workaround tests. Earlier effective MIOpen find modes were not established in every failed trial.

Who can help?

No response