laggy behaviour while in opencl viewport rendering

[B.Y.O.B.]

You can have bandwidth (PATHOCL) or low "latency" (RTPATHOCL), you can not have both for obvious reason: being able to edit the scene while rendering with PATHOCL would require to keep 2 copy of the scene in memory.

I'm not talking about rendering while editing, but about the case where no edits happen and the user just watches the image converge. So it's a simple render-draw-render-draw loop. Can this not use 100% GPU, regardless of how often the rendered samples are retrieved for drawing?

[Dade]

I'm not talking about rendering while editing, but about the case where no edits happen and the user just watches the image converge. So it's a simple render-draw-render-draw loop. Can this not use 100% GPU, regardless of how often the rendered samples are retrieved for drawing?

No because the WaitNewFrame() is synchronization point between BlendLuxCore, LuxCore CPU code and LuxCore GPU code. And a synchronization point is required to avoid to edit a scene while someone else is reading the same data. The only solution to avoid synchronization is to have multiple copies of the data.

PATHOCL leaves the GPU to its own business without any synchronization. For the same reason, it is not possible to halt PATHOCL rendering to an exact number of samples per pixel (it will always render slightly more because GPU will be stopped after CPU has detected the "enough" samples condition).

[B.Y.O.B.]

But why is the GPU doing more work when I request more synchronizations? And no work at all if I don't call WaitNewFrame() for several seconds?

[Dade]

But why is the GPU doing more work when I request more synchronizations? And no work at all if I don't call WaitNewFrame() for several seconds?

As I wrote, the WaitNewFrame() is synchronization point between BlendLuxCore, LuxCore CPU code and LuxCore GPU code:

BlendLuxCore code:

1) WaitNewFrame() synchronization;
2) do its own business.
3) goto #1

CPU Code:

1) WaitNewFrame() synchronization;
2) Tell GPU do X work;
3) goto #1

GPU Code:

1) WaitNewFrame() synchronization;
2) Do the amount of work CPU has sent;
3) goto #1

Clearly, they runs at the pace of the slowest one.

[B.Y.O.B.]

Can I request more work to be done?

edit:
I tried setting opencl.task.count to a higher value, like 1024 * 1024 * 1000, and it helps a tiny bit (samples/sec go from 12M to 16M), but I guess i'm hitting the taskCap relativily soon at something like 1024 * 1024 * 10. CUDA utilization in the task manager still shows 50%.

Speaking as a user, I prefer fast rendering (high bandwidth) a lot compared to low latency. Usually I slide some value around, which triggers a bunch of updates, but I don't care if the renderengine can keep up with them because the low-resolution first samples are not of much use for fine-tuning anyway (they are only useful for orientation during camera movement). But after I stopped dragging the value slider, I want the engine to give me a preview with many samples in a short time. Not milliseconds, but half a second or so would be nice. To judge the result of my value-editing, I need a clean image with many samples, a long phase of blocky preview means I have to wait several seconds before I can judge if the new value is good or not.

[Dade]

Can I request more work to be done?

edit:
I tried setting opencl.task.count to a higher value, like 1024 * 1024 * 1000, and it helps a tiny bit (samples/sec go from 12M to 16M), but I guess i'm hitting the taskCap relativily soon at something like 1024 * 1024 * 10. CUDA utilization in the task manager still shows 50%.

You control that with the rtpath.resolutionreduction (viewtopic.php?f=4&t=1863&start=10#p20672). 1 sample every pixel is more work than 1 sample every 2x2, more thane 1 samples every 4x4, etc.

However this thread was about reducing lag and you seem to want to move exactly in the opposite direction: increasing the bandwidth (and lag). I have also the feeling that you are using a too simple test scene (you are talking of 10+M samples/sec) and if you test the same settings with a complex scene, the lag will be insane.

[Dade]

Speaking as a user, I prefer fast rendering (high bandwidth) a lot compared to low latency. Usually I slide some value around, which triggers a bunch of updates, but I don't care if the renderengine can keep up with them because the low-resolution first samples are not of much use for fine-tuning anyway (they are only useful for orientation during camera movement). But after I stopped dragging the value slider, I want the engine to give me a preview with many samples in a short time. Not milliseconds, but half a second or so would be nice. To judge the result of my value-editing, I need a clean image with many samples, a long phase of blocky preview means I have to wait several seconds before I can judge if the new value is good or not.

This is what the "preview" settings are about: you can use a preview phase where, for instance, you render 1 samples every 8x8 and than a normal phase where you render 1 samples every pixel: low lag, low bandwidth preview and high lag, high bandwidth normal rendering.

[B.Y.O.B.]

However this thread was about reducing lag and you seem to want to move exactly in the opposite direction: increasing the bandwidth (and lag).

To an extent, yes, but to quote the first post:

My only complain is how laggy the whole software becomes while using opencl during viewport rendering.
Renders really fast, but it's just impossible to tweak things while rendering. So much delay.

From my understanding this is about responsiveness of the Blender interface, for example being able to still move sliders around, open/close menus etc. while the viewport render is running. Not so much about the latency when editing the scene. With the old settings i used for RTPATHOCL, the whole interface was indeed very laggy, which is fixed by using the settings you suggested.

I have also the feeling that you are using a too simple test scene (you are talking of 10+M samples/sec) and if you test the same settings with a complex scene, the lag will be insane.

I'm using the DanishMood example scene. While samples/sec might seem high, it resolves pretty slowly.
Sometimes I also use the scene I posted, with the lake and clouds, which has about 3.5M samples/sec.
Indeed, I should test it with a more complex scene.

This is what the "preview" settings are about: you can use a preview phase where, for instance, you render 1 samples every 8x8 and than a normal phase where you render 1 samples every pixel: low lag, low bandwidth preview and high lag, high bandwidth normal rendering.

That is why my settings for RTPATHOCL where like this for the longest time:

Code: Select all

# The user can choose how low-res the first frame is
definitions["rtpath.resolutionreduction.preview"] = resolutionreduction

# Only do one frame at low-resolution, render full-res afterwards
definitions["rtpath.resolutionreduction.step"] = 1
definitions["rtpath.resolutionreduction"] = 1

But it does not really work. With step = 1, I get no low-res preview at all even during camera movements. And with higher steps, e.g. 2, it takes forever to blend from blocky to fine-grained.

I think what I would find best is if the viewport would stop refreshing for 0.5 seconds after the blocky preview, then completely replace the blocks with the samples that were rendered in those 0.5 seconds at 100% GPU load.
(And no matter how long it takes to render 1 sample/pixel, the Blender interface should stay fluid)