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
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.

1 participant