[Bug] Hires pass runs an extra step at some denoising strengths

Git commit

be48649, local Release Vulkan build from a clean source tree. This was current master and the latest release source at the time of reproduction. The incremental binary retained an earlier version banner; the source commit was verified separately with git rev-parse HEAD.

Operating System & Version

Fedora 44, kernel 7.2.11-200.fc44.x86_64. Mesa Vulkan drivers 26.2.5, Vulkan loader 1.4.341. AMD Radeon 780M, RADV PHOENIX, UMA.

GGML backends

Vulkan. Other backends were not tested.

Command-line arguments used

sd-cli -m realisticVisionV60B1_v60B1VAE.safetensors \
  -p 'A red fox sitting in a forest clearing, wildlife photograph' \
  -W 256 -H 256 --steps 2 --sampling-method euler --cfg-scale 5 \
  --seed 42 --max-vram 4 --vae-tiling --backend vulkan0 \
  --hires --hires-upscaler Lanczos --hires-scale 1.25 \
  --hires-steps 2 --hires-denoising-strength 0.5 -o output.png

Steps to reproduce

1. Run the command above directly with sd-cli, without SwarmUI or ComfyUI.
2. Observe the hires sigma schedule and its sampling progress.
3. Repeat with the hires-step and denoising-strength pairs in the table below.

What you expected to happen

The hires pass runs the requested number of sampling steps. The CLI help describes --hires-steps as the second-pass sample steps. The source comment in make_hires_sigma_schedule also says trimming should yield exactly the effective step count.

What actually happened

All five cases completed successfully. The base pass ran its requested 2 steps. The behavior also occurs with actual 256x256 to 320x320 upscaling, so it is not limited to a scale of 1.

Logs / error messages / stack trace

For 2 hires steps and denoising strength 0.5:

hires fix: upscaling to 320x320
hires fix: scheduler_steps=4, denoising_strength=0.50, sigma_sched_size=4
1/3
2/3
3/3
hires sampling 1/1 completed

For 4 hires steps and denoising strength 0.4:

hires fix: scheduler_steps=10, denoising_strength=0.40, sigma_sched_size=6
1/5
2/5
3/5
4/5
5/5

Additional context / environment details

The likely cause is make_hires_sigma_schedule. It computes scheduler_steps from effective_steps / strength and trims starting at scheduler_steps - t_enc - 1. When t_enc reaches the requested count without reaching scheduler_steps, the resulting schedule contains one extra interval. This is a source-based explanation; no fix has been tested.

The troubleshooting guide was checked. Its numerical overflow workarounds do not address a deterministic schedule-length discrepancy. Existing hires issues and PRs were searched; no matching step-count report was found.