Conversation
Because Python is a single-threaded piece of shit that I don't trust at all. Basically, I don't think Python does time division multi-threading, which means that one running thread with starve all other threads. Normally, blocking IO operations make threads yield, so other threads can get some CPU, but we are only doing computations. So we need some way for threads to yield and let other threads and let other threads do some works. In particular, the thread that accepts the That said, So you definitely can't remove the sleep, but you could try replacing it with
Yes, but it probably won't do much. Windows' native sleep kernel API only supports millisecond precision. There is a high-precision sleep API, but I don't know if Python uses that. On top of that, Windows likes to sleep a little longer sometimes... As I said above, you can try 0, though. Python has a special cause for |
|
Ok, I'll try |
|
Works perfectly fine. Tested by using a heavy model with 128 tile size. Was able to pause a few times while it was processing. I could actually hear my GPU stop processing while paused. Resuming eventually led to it finishing. |
RunDevelopment
left a comment
There was a problem hiding this comment.
Let's add a comment explaining the thread.sleep(0).
After that, feel free to merge this.
Co-authored-by: Michael Schmidt <mitchi5000.ms@googlemail.com>
I'm assuming this has a reason to be here, otherwise I can't see why it's worth slightly slowing down every upscale.
If it doesn't, let's get rid of it. If it does, can we use a smaller number? Even though it's only a millisecond, that time can add up. A 5 minute video clip at 24fps would cost about 7 extra seconds in processing time because of this.