laggy viewport

[markxu2022]

I have this issue where the viewport is quite laggy on my 2.93 version. and the render time can vary from 5 seconds to 16 seconds in a simple scene. below is a video showing how the cpu gpu as well as how its lagging. Though there is a video recording running, but when I am not running the video recorder, it still consumes large parts of the cpu/gpu.
https://youtu.be/gB7y88RyOtM

here is a pic showing the render time, I am using the malt sample pack's material.

some other videos demonstrates the issues
render speed at two viewport mode:
https://youtu.be/u-SljNujne0

viewport speed:
https://youtu.be/HD7siSuMRZg

here is a debug log where I opened a simple scene with cube and nothing else but turn around the views.

LOG

(Edit by @pragma37 : Fixed the links and replaced the posted log with an attachment)

[pragma37]

Thank you for the detailed report.
It seems that the problem is not the rendering performance of Malt itself, but loading the final render into the Blender viewport?
It's also strange that it seems to skip samples.
And the viewport FPS are much lower than what the Malt Stats suggest.

I'll prepare some tests to see if we can find where the issue is.

Meanwhile, some things that would be useful to check:

• What does your VRAM usage looks like when rendering on the viewport? 4gb of VRAM may be a bit low for running Malt at 4k.
• When you do a F12 render with the viewport render disabled, does the GPU reach 100% usage?
• If you change your screen resolution to 1080 do you still get lag in the viewport? Does the GPU run at 100% in that case?

[markxu2022]

Hi! Thanks for your suggestion, I changed my monitor resolution from 4k to 2k and now it runs smooth like a butter. and the gpu does not reach 100% if I change resolution from 4k to 2k.

The only weird thing is that whatever scene it loaded, either an empty box or others, the first render is always a bit slow, like 8 seconds, then after that, it will render smoothly like (1.7 sec/frame). I guess it's just the first time loading will cause it and it doesn't worry me at all.

Thanks again for creating this wonderful renderer!

[pragma37]

I'm glad you got it to work smoothly.

That said, if the GPU still doesn't reach 100% use there must be a problem somewhere.
You are not the first user to report a similar issue, so I'll keep looking for a proper solution.

I'll add a screen percentage setting so at least you don't have to change the resolution of your full system.

BTW, the first frame taking longer is indeed because Malt has to initialize resources. It's normal.

[solid-f38]

I'm having the same issue and the same solving.
When resizing the viewport from 4k to 2k it becomes smooth.

But the GPU is GTX1060 6GB so it feels strange to be laggy even if its 4k.
It even lags when there's only a default cube with no malt material applied.

Really appreciate the screen percentage setting but still there might be a bug?

[pragma37]

@solid-f38 Yes, this needs a proper solution, but since I can't reproduce it locally I depend on users willing to do some testing and report back until we find what's causing the problem.

[pragma37]

I have added a Viewport Resolution Scale option to the World settings.
It's available in the Development branch.

Could you check if the performance at 4k with 0.5 resolution scale is the same than the performance at 2k with 1.0 scale?

[solid-f38]

Thank you for the development! So fast development!!
I tested the new feature and it worked as intended!

By the way I captured a video about malt working on my PC.
https://www.youtube.com/watch?v=HXkfGqN-uBI

Here I'm using a
4K monitor
GTX1060 6GB
default cube with no material applyed
first using the Resolution Scale 0.5 which makes the preview pretty smooth,
then changing it to 1.0 which makes it quite laggy.

And also Attached the malt log file to this comment.
malt 2021-06-29(03-34).log

Could this be some kind of help making the performance faster?

[pragma37]

So in your case the GPU is at 100% use.
Could you test this version and check if the Malt window runs smoother than the Blender viewport?
Like this:

2021-06-29.17-44-07_Trim.mp4

[solid-f38]

Thank you for the update!
I tested it out and it looks like the video attached to this comment.
Unfortunately it doesn't seem to make much difference.

By the way, I noticed that in the task manager 2 tasks "Blender" and "Python" is using the CPU and GPU.
Is this the reason why malt needs more performance than other renderers?

2021-06-30.04-22-29.mp4

[pragma37]

Maybe that's the issue? Blender is eating all the GPU, leaving very little resources for Malt (the python process).
It should be the opposite, since Blender only has to draw the final render into the screen.

In my case:

I wonder, what's the refresh rate of your monitor?

[solid-f38]

Feels like getting closer to the cause!
My monitors refresh rate is 60hz.

[pragma37]

I've uploaded a new test version, this one doesn't draw to Blender at all.
Could you test it and post the log?

For testing it at higher resolutions you can set the resolution scale to a value larger than 1. Like this:

2021-06-30.18-04-08_Trim.mp4

Sorry for having you making random tests. I wish I could test this myself.

[solid-f38]

Thank you for the update!
I tested out and it became quite responsive.
Feels like there's 0.4 seconds between my mouse input and the viewport movement but much smoother than before.

There's something I felt odd.
The python task keeps using the GPU for a several seconds even after I stopped moving things.
Is this something not intended or is it normal?

2021-07-01.05-29-30.mp4

Developing is the real hard part and compared to that testing is like nothing!

[solid-f38]

I tested it on a different blend file and remaining GPU usage thing didn't happen on one but happened on the other.

2021-07-01.06-05-11.mp4

2021-07-01.06-21-41.mp4

[solid-f38]

Forgot to post the log files!
The first one is for 2021-07-01.06-05-11.mp4
and the second one is for 2021-07-01.06-21-41.mp4

malt 2021-07-01(06-08).log
malt 2021-07-01(06-08)_2.log

[pragma37]

Awesome! Thank you!
At least now we know for sure there's room for a performance improvement.

Those logs should contain info for how much time passes between Blender frames, but it's not there.
If you open the Blender system console, do you see something like this?

[solid-f38]

I took two videos with the console showed.

2021-07-02.02-33-50.mp4

2021-07-02.02-35-22.mp4

[pragma37]

Sorry for the late reply (I've been on vacation).

I added a new option to the Development branch that allows setting a maximum frame-rate for the Blender viewport (only while Malt is rendering).
(0 means no frame-rate cap)

That way it's possible to ensure Blender doesn't consume too many resources.

Could you test setting it to a low value (20, for example) and see if that helps?

[BerlinAW]

I ran some tests.

Highlights: RX580 Graphics Card, Manjaro Linux, Running Latest Development Version of Malt, Screen Size 2560 x 1440

I tested using the advanced line mesh shader.

I am showing the GPU maxing out when I force blender to redraw the screen. (Funny Aside: At those frequencies, I can actually hear my graphics card humming like a bad transformer. XD)

I set the frame rate cap at 30 FPS, and the window resolution down to .25% If I run it at 50% the system lags pretty hard.

Video illustrating the GPU Usage:

condensed.mp4

Malt Log File First 900 of 32000 lines:
Malt Test GPU.txt

[pragma37]

Could you test the performance of this pipeline?
minipipeline benchmark.zip

This should fly on any GPU.

If it doesn't it must be a core issue with the way Malt interacts with Blender, and if it does we should be able to profile the rendering performance to figure out the issue (I recently added RenderDoc support to Malt).

[solid-f38]

I'm so sorry for the late reply.
I overlooked your posts.
Currently my work is so hard I can't do the tests.
I think I could take time 2weeks later.

[BerlinAW]

malt 2021-08-17(17-34).log

Sorry it took me so long to get back to you. Life is certainly busy at the moment.

Attached is the log file for the malt session.

Here is what I learned:

When running malt renderer in the viewport if I make small orbits around Suzy, a few degrees per second, my graphics card will jump up to around 50% usage. It renders silky smooth while panning about like this. If I make larger motions, the system will get a little more frame skippy and the card usage will jump up to 100%. Even still, the behavior here feels more natural than the previous tests that I had done. If I go crazy and just whip the model around, the viewport will go gray for a second and all I will see is the XYZ axis frozen and then it will snap back in a second after it is done calculating.

Also this time I noticed the malt window running in the background. It adopts whatever imagery is behind it on the desktop, open windows, plasma widgets, or just the desktop background itself, and it flickers at a very rapid interval. I do not know if this is normal behavior for it or not. Might just be a linux thing.

[pragma37]

Hey! No need to apologize.
I actually just got an RTX 3060 ti and I can finally reproduce some of these issues on my own.

As I expected, the low performance at 4k is not a rendering performance problem, but a bandwidth problem.
https://user-images.githubusercontent.com/36610999/130094897-e755b913-0103-4050-bb28-6bf8b22a72fe.mp4

• Render at 4k, send to Blender as 1080 (32 bits/channel). (~2ms) 👍
• Render at 4k, send to Blender as 4k (32 bits/channel). (~40ms) ❌
• Render at 4k, send to Blender as 4k (8 bits/channel). (~2ms) 👍

The downside of sending the render result at 8 bits/channel is that Malt would have to do its own color management, but it may be worth it.

@BerlinAW I missed it on the first log you posted, but your OpenGL driver doesn't seem to support GL_READ_PIXELS for any texture format.
Malt > GL_RGBA8 GL_READ_PIXELS: GL_ZERO
It should report GL_FULL_SUPPORT instead of GL_ZERO.

That's why it's so slow.

[pragma37]

I added the option to choose between 8 and 32 bit textures for the viewport render.

The color management is still done by Blender since there's no way to avoid it. For SRGB is fine, but with Filmic it clamps values above 1.0.