laggy behaviour while in opencl viewport rendering

[Dade]

I also noticed this while playing with the new OpenCL material system in v2.4alpha.
I hope we can improve this for v2.4.

This is mostly a driver problem but it may be easy to fix: I expect the lag will be reduced if I send multiple (smaller) batches of work to the GPU instead of a sing large one. This has more overhead but it may allow the driver to inter-live OpenCL and OpenGL work. Empirically, you can verify if this is true by reducing the size of the view port (i.e reducing the total amount of work sent to the GPU.

I'm trying to reproduce the problem but I have no lag at all on Linux, no matter of the resolution

[B.Y.O.B.]

I have only tested on Windows so far.
I'll send you a testscene later.

[Dade]

I have only tested on Windows so far.
I'll send you a testscene later.

If it is a Windows only problem, it may more related to the bad Windows schedular and all yield() have to add around the code to make Windows responsive: https://github.com/LuxCoreRender/LuxCor ... d.cpp#L100

However one is GPU lag, the other CPU lag, the solution is quite different.

[B.Y.O.B.]

I can not reproduce the problem with a simple cube-on-a-plane, the scene needs to be heavier.
Attached is a scene where I could demonstrate the problem.
https://youtu.be/dbjK5fXRukw
In this video, you can see how unresponsive the interface becomes during the viewport render. Especially in the part after 1:30, where I just pan around the node editor - while the render is running, it is basically a slideshow, and as soon as it pauses, panning is smooth again.

To an extent, the the CPU viewport render also has this problem, but it is much less pronounced.

Note that I have not yet started to investigate what might be the culprit of this. It could be in the addon or in LuxCore, or a combination of both.
The video was recorded with the latest build from the for_v2.4 branch: https://github.com/LuxCoreRender/LuxCor ... b61aae9c46

[Dade]

I can not reproduce the problem with a simple cube-on-a-plane, the scene needs to be heavier.
Attached is a scene where I could demonstrate the problem.
https://youtu.be/dbjK5fXRukw
In this video, you can see how unresponsive the interface becomes during the viewport render. Especially in the part after 1:30, where I just pan around the node editor - while the render is running, it is basically a slideshow, and as soon as it pauses, panning is smooth again.

To an extent, the the CPU viewport render also has this problem, but it is much less pronounced.

Note that I have not yet started to investigate what might be the culprit of this. It could be in the addon or in LuxCore, or a combination of both.
The video was recorded with the latest build from the for_v2.4 branch: https://github.com/LuxCoreRender/LuxCor ... b61aae9c46

The root of the problem is in the grain of the frame cost: longer is the time to render <image width> x <image height> x 1 samples and more lag you have.

However RTPATHOCL has already settings intended to control the cost of rendering a single frame (after the preview):

Code: Select all

# Default values
rtpath.resolutionreduction = 4

The default setting will render 1 of 4x4 pixels every frame (16 times faster than rendering 1 sample every pixel). I think BlendLuxCore is not using the default settings (i.e. is probably using 1).

It is also very important to have an even faster preview phase (the rendering of the very first frames) in order to have a fast response during continuous editing (like in your video):

Code: Select all

# Default values
rtpath.resolutionreduction.preview = 4
rtpath.resolutionreduction.preview.step = 8

This will splat 1 sample over 4x4 pixels for 8 frames.

Short version: if you use the default RTPATHOCL settings there is pretty much no lag while rendering your test scene.

The best solution is probably to scale the RTPATHOCL parameters according the view port size, for instance:

1) use "rtpath.resolutionreduction = 1" if it is smaller than 256x256
2) use "rtpath.resolutionreduction = 2" if it is smaller than 512x512
3) use "rtpath.resolutionreduction = 4" if it is smaller than 1024x1024
4) etc.

This will give constant response time no matter of the view port resolution.

The other option could be to give to the user some control (i.e. low, medium, high pre-view quality).

[andre]

hey BYOB that's exactly the kind of behaviour I was talking about. Glad you had a chance to reproduce it.
And thanks guys for diving into this.
To me personally this is the only big thing that's lacking in Luxcore compared to Octane or Redshift.

[B.Y.O.B.]

I inserted a bunch of timing checks in the view_update() and view_draw() methods in BlendLuxCore.
For testing I only modified the absorption color of the clouds volume, like in the video, and at the end I let it render a bit uninterrupted.

This is a run with the current BlendLuxCore settings:

Code: Select all

Current BlendLuxCore settings:
rtpath.resolutionreduction = 1
rtpath.resolutionreduction.preview = 4
rtpath.resolutionreduction.preview.step = 1

view_update() took 168.1 ms
view_draw() took 142.0 ms

view_update() took 171.5 ms
view_draw() took 141.0 ms

view_update() took 171.1 ms
view_draw() took 138.0 ms

view_update() took 168.0 ms
view_draw() took 141.0 ms

view_update() took 170.1 ms
view_draw() took 136.0 ms
view_draw() took 140.0 ms
view_draw() took 141.0 ms
view_draw() took 139.0 ms
view_draw() took 139.0 ms
view_draw() took 139.0 ms
view_draw() took 140.0 ms
view_draw() took 170.0 ms
view_draw() took 809.8 ms
view_draw() took 835.1 ms
view_draw() took 806.5 ms
view_draw() took 820.3 ms
view_draw() took 801.2 ms
view_draw() took 814.2 ms
view_draw() took 810.6 ms

And this is with Dade's proposed settings:

Code: Select all

Dade's proposed settings:
rtpath.resolutionreduction = 4
rtpath.resolutionreduction.preview = 4
rtpath.resolutionreduction.preview.step = 8

view_update() took 171.0 ms
view_draw() took 141.0 ms

view_update() took 171.0 ms
view_draw() took 137.0 ms

view_update() took 171.0 ms
view_draw() took 136.0 ms

view_update() took 171.0 ms
view_draw() took 152.0 ms
view_draw() took 136.0 ms
view_draw() took 135.0 ms
view_draw() took 136.0 ms

view_update() took 170.0 ms
view_draw() took 135.0 ms

view_update() took 169.0 ms
view_draw() took 138.0 ms

view_update() took 170.0 ms
view_draw() took 138.0 ms

view_update() took 168.0 ms
view_draw() took 136.0 ms

view_update() took 169.0 ms
view_draw() took 137.0 ms
view_draw() took 139.0 ms
view_draw() took 140.0 ms
view_draw() took 136.9 ms
view_draw() took 138.0 ms
view_draw() took 136.0 ms
view_draw() took 136.0 ms
view_draw() took 152.0 ms
view_draw() took 137.0 ms
view_draw() took 135.0 ms
view_draw() took 137.0 ms
view_draw() took 136.0 ms
view_draw() took 135.0 ms
view_draw() took 136.0 ms
view_draw() took 136.0 ms
view_draw() took 136.0 ms
view_draw() took 137.0 ms
view_draw() took 137.0 ms
view_draw() took 137.0 ms

The only difference is the drawing time after the render runs uninterrupted for a while, so I inserted more fine-grained timing checks:

Code: Select all

view_update(): checking for changes took 125.0 ms
view_update(): applying changes took 42.0 ms
view_update() took 167.0 ms

view_draw(): checking for changes took 126.0 ms
view_draw(): session.WaitNewFrame() took 1.0 ms
view_draw(): session.UpdateStats() took 0.0 ms
view_draw(): framebuffer update took 22.0 ms
view_draw(): framebuffer drawing took 1.0 ms
view_draw(): showing stats in UI took 0.0 ms
view_draw() took 151.0 ms

view_update(): checking for changes took 124.0 ms
view_update(): applying changes took 41.0 ms
view_update() took 167.0 ms

view_draw(): checking for changes took 126.0 ms
view_draw(): session.WaitNewFrame() took 1.0 ms
view_draw(): session.UpdateStats() took 0.0 ms
view_draw(): framebuffer update took 7.0 ms
view_draw(): framebuffer drawing took 0.0 ms
view_draw(): showing stats in UI took 0.0 ms
view_draw() took 135.0 ms

"checking for changes" is the biggest chunk, and because I do it both in update and drawing (because some updates only happen during drawing) it hurts double.
The main priority should be to optimize this method in BlendLuxCore.

edit: When I disable update checking, I get the following pattern:
Suddenly, WaitNewFrame() takes 40-100 ms. I guess this is because with updates, the next frame is already getting rendered while the slow update check is running.

Code: Select all

view_draw(): checking for changes took 0.0 ms
view_draw(): session.WaitNewFrame() took 88.1 ms
view_draw(): session.UpdateStats() took 0.0 ms
view_draw(): framebuffer update took 6.0 ms
view_draw(): framebuffer drawing took 0.0 ms
view_draw(): showing stats in UI took 0.0 ms
view_draw() took 97.1 ms
view_draw(): checking for changes took 0.0 ms
view_draw(): session.WaitNewFrame() took 90.1 ms
view_draw(): session.UpdateStats() took 0.0 ms
view_draw(): framebuffer update took 6.0 ms
view_draw(): framebuffer drawing took 1.0 ms
view_draw(): showing stats in UI took 0.0 ms
view_draw() took 97.1 ms
view_draw(): checking for changes took 0.0 ms
view_draw(): session.WaitNewFrame() took 89.1 ms
view_draw(): session.UpdateStats() took 0.0 ms
view_draw(): framebuffer update took 6.0 ms
view_draw(): framebuffer drawing took 0.0 ms
view_draw(): showing stats in UI took 1.0 ms
view_draw() took 96.1 ms
view_draw(): checking for changes took 0.0 ms
view_draw(): session.WaitNewFrame() took 89.0 ms
view_draw(): session.UpdateStats() took 0.0 ms
view_draw(): framebuffer update took 11.0 ms
view_draw(): framebuffer drawing took 0.0 ms
view_draw(): showing stats in UI took 0.0 ms
view_draw() took 100.0 ms
view_draw(): checking for changes took 0.0 ms
view_draw(): session.WaitNewFrame() took 39.0 ms
view_draw(): session.UpdateStats() took 0.0 ms
view_draw(): framebuffer update took 7.0 ms
view_draw(): framebuffer drawing took 0.0 ms
view_draw(): showing stats in UI took 0.0 ms
view_draw() took 46.0 ms
view_draw(): checking for changes took 0.0 ms
view_draw(): session.WaitNewFrame() took 87.0 ms
view_draw(): session.UpdateStats() took 0.0 ms
view_draw(): framebuffer update took 11.0 ms
view_draw(): framebuffer drawing took 0.0 ms
view_draw(): showing stats in UI took 0.0 ms
view_draw() took 98.0 ms
view_draw(): checking for changes took 0.0 ms
view_draw(): session.WaitNewFrame() took 82.0 ms
view_draw(): session.UpdateStats() took 0.0 ms
view_draw(): framebuffer update took 11.0 ms
view_draw(): framebuffer drawing took 0.0 ms
view_draw(): showing stats in UI took 0.0 ms
view_draw() took 94.0 ms
view_draw(): checking for changes took 0.0 ms
view_draw(): session.WaitNewFrame() took 88.0 ms
view_draw(): session.UpdateStats() took 0.0 ms
view_draw(): framebuffer update took 6.0 ms
view_draw(): framebuffer drawing took 0.0 ms
view_draw(): showing stats in UI took 0.0 ms
view_draw() took 95.0 ms

[B.Y.O.B.]

I have optimized the check for updates, it is now a lot faster.

One thing I observe is that my GPU reports a CUDA load of only around 50% during viewport rendering.
As a test, I put the viewport to sleep for one second after each update. The CPU viewport is rendering with slightly improved performance when I do this (960k samples/sec with sleep vs. 850k without), but in the OpenCL viewport, the samples/sec go down to 640k with sleep vs. 12.2M without! CUDA load also goes down to something like 5% when sleeping.

It seems the load I can put on the GPU in RTPATHOCL is limited by the drawing rate I can achieve in the client program? This is bad news for the Blender addon.

edit:
If I use this instead of sleep(1):

Code: Select all

for i in range(100):
    engine.session.WaitNewFrame()

I get about 70% CUDA load and 25.6M samples/sec.
But of course this is not a solution because it locks up Blender completely between viewport draws, just like sleep.

[Dade]

It seems the load I can put on the GPU in RTPATHOCL is limited by the drawing rate I can achieve in the client program?

Yes, it is the expected, it the the result of the WaitNewFrame(). 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.

[andre]

It seems the load I can put on the GPU in RTPATHOCL is limited by the drawing rate I can achieve in the client program?

Yes, it is the expected, it the the result of the WaitNewFrame(). 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.

Yeah I can see that it’s not making use of full GPU potential. Even using two GPUs. I wonder how cycles or octane keeps 100% performance in viewport rendering.
Cycles doesn’t seems to scale properly with 2 gpus but octane basically doubles the speed.
I wish I could help but have no coding knowledge.