Skip to content

Conversation

wbruna
Copy link
Contributor

@wbruna wbruna commented Sep 16, 2025

Second-order samplers call the model twice per step, except for the last iteration. Since the progress is updated only for each second call, the last step is never shown.

The timing information is also misleading, since it's displaying the number of full steps, but measuring only the last half. Comparing to a first-order sampler, the progress shows the same timing for each iteration, and the same number of steps, but takes almost twice as long.

So, change the display to show average time per step, which should give a better idea of the expected time until completion, and update the progress display after all model calls.

@wbruna
Copy link
Contributor Author

wbruna commented Sep 16, 2025

Since the time always advances, but we have two updates per step, the displayed average will oscillate, especially on the first iterations. We could instead keep updating for full steps, and explicitly include the last one:

diff --git a/stable-diffusion.cpp b/stable-diffusion.cpp
index 7b03bee..d21c2eb 100644
--- a/stable-diffusion.cpp
+++ b/stable-diffusion.cpp
@@ -1224,7 +1224,7 @@ public:
                 vec_denoised[i] = latent_result * c_out + vec_input[i] * c_skip;
             }
             int64_t t1 = ggml_time_us();
-            if (step != 0) {
+            if (step > 0 || step == -(int)steps) {
                 int showstep = std::abs(step);
                 pretty_progress(showstep, (int)steps, (t1 - t0) / 1000000.f / showstep);
                 // LOG_INFO("step %d sampling completed taking %.2fs", step, (t1 - t0) * 1.0f / 1000000);

@wbruna wbruna force-pushed the fix_progress_2nd_order_samplers branch from 2d1bc7f to 86e26b3 Compare October 11, 2025 19:04
Second-order samplers call the model twice per step, except
for the last iteration. Since the progress is updated only
for each second call, the last step is never shown.

The timing information is also misleading, since it's
displaying the number of full steps, but measuring only
the last half. Comparing to a first-order sampler, the
progress shows the same timing for each iteration, and
the same number of steps, but takes almost twice as long.

So, change the display to show average time per step,
which should give a better idea of the expected time
until completion, and update the progress display after
all model calls.
The progress call on each half step would increase the time
without increasing the step count, making the average go up;
it would then go down again on the whole step update.
@wbruna wbruna force-pushed the fix_progress_2nd_order_samplers branch from 86e26b3 to 852adcc Compare October 12, 2025 21:25
@leejet leejet merged commit c64994d into leejet:master Oct 13, 2025
9 checks passed
@stduhpf
Copy link
Contributor

stduhpf commented Oct 15, 2025

image I'm not 100% certain it's because of this PR yet, but after updating sd.cpp, I noticed this issue with progress display. (this is with euler sampler) Instead of displaying the speed it seem to just display the time elapsed since the start.

@leejet
Copy link
Owner

leejet commented Oct 15, 2025

I wasn’t able to reproduce your issue. Could you provide the detailed command-line arguments?

[DEBUG] ggml_extend.hpp:1582 - Wan2.x-T2V-14B compute buffer size: 202.72 MB(VRAM)
  |==================================================| 14/14 - 1.57it/s
[INFO ] stable-diffusion.cpp:3008 - sampling completed, taking 8.90s

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants