sd and sdxl txt2img controlnet pipelines pass their control tensors as image; the callback took them as a preview and returned before the interrupt check.
The t2iadapter, xs and lite caches ignored sd_model_type, and the control-models endpoint never refreshes, so a first request with no model loaded returned ['None'] until restart.
The separate-init branch checked the txt2img signature, where plain sd and sdxl controlnet name the control image `image`, so they received the init image. The img2img and inpaint classes take control_image.
hidiffusion, the ControlNet-XS pipeline and the leres depth helper still
called torch.cuda.empty_cache() directly. That is a no-op on every backend
that does not expose the CUDA API, so the release those paths intend never
happened there, while the rest of the codebase already goes through
devices.torch_gc() (which resolves the active accelerator and logs the
release). Route the three sites through the shared helper, as the core
guidelines ask for CUDA-neutral platform paths.
Signed-off-by: li-lizhe <[email protected]>
The skip options pre-seeded the autotune cache with the kernel's first unpruned config, which can be one its own pruning rejects for the call's arguments: SDNQ int8 attention's BLOCK_SIZE_N=16 does not compile, so with skip enabled every encode failed and sd_hijack_te returned the prompt in place of the embeddings. The seed is now the first config Autotuner.prune_configs keeps, the one Triton runs itself when pruning leaves a single config.
SDNQ compiles its helpers for static shapes, so an encode at a new prompt length or condition-image size recompiles them; on a long-running server each new length costs tens of seconds and logs the long-encode warning. With torch_skip_compile_te on (Compute Settings, next to the Triton autotune skips, off by default), hijack_encode_prompt runs the encoder under torch.compiler.set_stance("force_eager"): warm encodes are as fast as compiled ones and the denoiser keeps its compiled kernels. An encoder ticked under Compile Model keeps its compile.
On the processed Control path processor.py sets width and height from the input image, and processing.py floors them to the VAE factor before task_specific_kwargs captures the request, so the check compared the image with itself: a 1001x700 input sent with a 1008x704 request was reported as requested 1000x696. processor.py marks that override with size_from_input and the check skips it; img2img and skip-processing jobs still compare the output with the request.
task_specific_kwargs compared the hires image, which the hires pass upscales itself, with the base request, so every hires run with a pixel upscaler logged "Size: source=image" and wrote "Size source: image" to the infotext.
Vladimir Mandic