Motion blur hyperthreading

When rendering animations with motion blur, all is well for the first 90% of each frame. This is when UF is calculating the fractal and antialiasing. The four CPU cores are maxed out and the CPU is 0% idle, as shown below on Activity Monitor.

But then comes the final 10% of the frame, which is when motion blur is being calculated. UF suddenly gets a lot slower. The CPU is 70% idle. The two physical cores are about 50% idle and the other two cores are are not being used.

I’m using motion blur because it looks great in animations but it’s very slow. Renders which take hours without blur require days with blur. It’d be really great if motion blur used hyperthreading and ran at 100% speed instead of only 30%.

Thanks much.

Can you test if this also happens when using non-adaptive AA?

Ultra Fractal's AA tries to be smart, which greatly reduces the rendering time in many cases (and can sometimes introduce other weird problems in turn). If your image has very small areas where UF deems AA to be necessary, then very few threads would be left processing just a bunch of nastily slow pixels.

However, motion blur could increase those areas by "smudging" them along the direction of motion but still within just a few threads or - from what it looks like in your example - even just one thread. If they are still small enough to not being broken into multiple threads, i.e. less than 16 pixels wide if I remember correctly, this could explain the behavior you are seeing here. Relatively fast motion along the x-axis of the screen space would do this.

If you force AA over the entire image, motion blur should have no effect on render time, hypothetically. I'd love for Frederik to clear it up if my assumptions are wrong.

Phillip

Hi Phillip. Thanks for the suggestion and the tip about how UF does antialiasing.

I gave this a shot, but unfortunately I got the same results. The screenshot below is with nonadaptive AA and motion blur on. The CPU is 70% idle during motion blur. Half the CPU cores are idle. The rest of the CPU cores are only about 50% used.

For comparison, the screenshot below is also with nonadaptive AA but this time motion blur is off. All cores are now maxed and the CPU is 0% idle.

I just tested this on my latest anim and here's the CPU load while rendering the first frame, those drops happen every few seconds and my load drops down a lot more. I have 24 threads, so it would make sense if some single core stuff is happening:

So it's not the AA then, which begs the question: what is going on?

I'd be surprised to learn that UF does the motion blur in some kind of post-render step because the information for it needs to come from rendering pixels that are offset in time rather than space. How does UF sample in time, if at all? Lycium taught me some anti aliasing stuff over this year and one of the things he mentioned is that motion blur is essentially just AA along the time coordinate. Not sure how this would slow down rendering to single core though.

Here's the view per logical CPU core, it's a 4s drop every 12s roughly:

Here's what it looks like with no motion blur, I still get a 1s drop on all cores every 10s:

Just to dig a bit more, I tried the following things:
Make a non-animated still of the same fractal -> lots of similar drops in CPU load
Increase iterations from 54 to 5444 -> drops get significantly smaller
Zoom into this last one to eliminate any cheap outside pixels -> drops disappear

This last results holds even if I go back to my animation with motion blur, but zoom in so it's 100% inside and then increase the iterations. So this seems to be related to overhead while calculating pixels that don't require lots of iterations, maybe it's when UF redistributes the pixels among threads when one of them finishes or something of that sort. I can only guess here.

24 threads. I’m drooling over here. Kind of you to suppress any get-a-real-computer snark.

I’m still rereading your reply and pondering the implications but the main thing I notice is that your virtual cores are actually being used. That doesn’t seem to be happening for me, so I thought the problem was basically lack of hyperthreading. And I hoped it could be fixed by just changing the “use hyperthreading” variable in the code.

Your cores are also at 100% most of the time. For me, the cores in use average 50% and don’t seem to get above 60%. We’re using different monitoring apps but this is still weird.

I have another Intel Mac with a faster CPU arriving this week which I can test later. My only other Mac now is an M2 which doesn’t have virtual cores.

Lycium. I remember that guy. Talked with him when I was on the UF mailing list like 15 years ago. Good animator. “Motion blur is essentially just AA along the time coordinate” is now something I will probably spend the next 24 hours trying unsuccessfully to get my head around.

24 threads. I’m drooling over here. Kind of you to suppress any get-a-real-computer snark.

I worked on 4c/8t for ages and only upgraded to such a beast because I won some money, but always glad to see a not-so-subtle flex land.

Jokes aside, I don't think there's anything wrong with your setup or CPU or even your fractal. Try the following:

1. open a normal mandelbrot set
2. activate some kind of inside coloring
3. set iterations to 5000
4. turn of periodicity checking
5. zoom in so all pixels are inside.
6. render the image and look at your CPU load

I would just give you params to paste but I'm at work. If my suspicions are correct, your CPU load should be a lot more consistent.

Yesterday was new computer day. Still setting it up but I tried the test in your reply on the same old MacBook I’ve been using in this thread. Same results as before.

phillipThreadsTest {
fractal:
  title="phillip threads test" width=1000 height=1000 layers=1
  frames=10 frame=10 fps=1 credits=""
layer:
  caption="Background" opacity=100 transparent=yes
mapping:
  center="-0.0968944101/0.0223602484@#0SS-0.08612189457/-0.00328998451\
  @#43200" magn="2@#0SS8@#43200E"
formula:
  maxiter=5000 percheck=off filename="Standard.ufm" entry="Mandelbrot"
  p_start=0/0 p_power=2/0 p_bailout=128
inside:
  transfer=linear filename="Standard.ucl" entry="DirectOrbitTraps"
  p_trapshape=point p_diameter=1.0 p_traporder=4.0 p_trapfreq=1.0
  p_trapcolor=distance p_threshold=0.25 p_startcolor=4278190080
  f_trapmergemode=normal p_trapmergemodifier=none
  p_trapmergeopacity=0.2 p_trapmergeorder=bottom-up p_trapcenter=0/0
  p_aspect=1.0 p_angle=0.0 p_solidcolor=no
outside:
  transfer=linear filename="Standard.ucl" entry="Smooth" p_power=2/0
  p_bailout=128.0
gradient:
  smooth=yes rotation=1 index=0 color=6555392 index=64 color=13331232
  index=168 color=16777197 index=257 color=43775 index=343 color=512
opacity:
  smooth=no index=0 opacity=255
}

I want to see what happens on the new Mac but I’m wondering whether this works for you because you've got the Windows version.

And it just gets worse. The new Mac is almost 90% idle during blur and the virtual cores are still unused. This is an i7 Mac mini. The previous tests were with an i5 MacBook.

At the risk of asking a dumb question: how do you know this is "during motion blur"? I can't find anything indicating which part of the calculation was being done.

Good question, actually. I should’ve provided a reference for that.

Ultra Fractal performs motion blur when rendering (a part of) an animation. The last 10% of the progress is reserved for motion blur

https://www.ultrafractal.com/forum/index.php?u=/topic/564/rendering-single-frame-of-animation/post-1612#post-1612

This is why I keep putting the UF Render window in my screenshots. When UF slows down and the virtual cores go idle, it’s during that 90%-100% part of the frame.

Oh... then the problem is a lot worse than I thought. It means that motion blur is applied in a separate step instead of during the render.

Correct, and currently the motion blur calculation is single-thread only so that explains why you're not seeing full CPU utilization.

Which begs the question: why not include it in the sampling itself? Instead of AA-ing each image and then blurring, you could sample the 3D space of [time, real, imag], which would also help smooth transitions if the fractal doesn't move but some parameter changes over time instead.

Is it currently only blurring literal motion? I.e. changes in the fractals center, zoom, and rotation? Or is it also motion blurring if I change a parameter of the fractal?

Motion blur is currently a post-processing step that only applies the location animation of the fractal, so center, magnitude and rotation. This vastly saves on calculation time compared to doing the 3D sampling that you're suggesting. Getting smooth results with that takes many sample points and could easily increase calculation times by a factor of ten or more.

I see... depending on how difficult it is to implement it might still be worth it, especially if some things change drastically between frames. Here's a comparison between the two. This is a Julia Set with only the seed varying. The code is mine, though with a lot of help from Lycium (big thank you to him, I still suck at C++).

The effect is even more apparent if the differences between frames are bigger:

You can always make it optional, if users prefer the faster mode.

//edit: no clue why the bottom two gifts aren't synchronous, but it annoys me more than it should
//edit2: In case anyone is wondering: the sample count is 36 here
//edit3: apparently they are synchronous after all...