Page MenuHome

macOS viewport lagging
Closed, ResolvedPublic

Description

System Information
Operating system: macOS Mojave
Graphics card:
NVIDIA GeForce GT 650M 1024 MB
Intel HD Graphics 4000 1536 MB

Blender Version
Broken: Blender 2.80 Beta, 2018-12-31
Hash : 4d795cee4938
Branch : blender2.7

Short description of error
Intense lags (not fluid) when moving, grabbing object, sculpting, on this computer with the 2.8 Blender Beta. Even with only a cube on the scene.
These lags doesn't exist on the 2.79 version and on older Macbooks I have.

Exact steps for others to reproduce the error
Sculpting, grabbing objet, moving in the scene. Lags (not fluid) pretty much everywhere.

Details

Type
Bug

Event Timeline

Sebastian Parborg (zeddb) triaged this task as Needs Information from User priority.Jan 24 2019, 4:04 PM

Is this still an issue with the latest blender beta?

Still an issue (2019-01-23 23:36 / Hash:7f77961f1c38) on my MacBook on macOS Mojave / NVIDIA GeForce GT 650 M 1024MB and INTEL HD Graphics 4000 1536 MB.

Can you attach the output of --debug-gpu (as a file) and also try --debug-gpu-force-workarounds and see if that helps?

Can you attach the output of --debug-gpu (as a file) and also try --debug-gpu-force-workarounds and see if that helps?

Don't know how to achieve that. Can you explain me ? Thanks

I'm really sorry Sebastian but I'm not really good at this kind of tech things... Don't understand even with the documentation. --' Hope I could understand !

Do you have any experience using the terminal?

Nop never --'
But If you give me the right code to enter, I could maybe help you !
Sorry !

Ok, open up the terminal.

The three basic commands you need to know is:

cd Change Directory

ls List Directory (contents)

pwd Print name of current/Working Directory

Open up the terminal and type pwd

It probably tell you that you are in your home directory.

Use cd to navigate to the directory were you installed blender 2.8. (Use cd <folder-name-here> to move into <folder-name-here>, cd .. to move up a folder)
Use ls to list the files and folders in the current directory

After you navigated to the folder you got in the .zip file of the blender beta, simply type ./blender.app/Contents/MacOS/blender in the terminal and blender should start.

Now you can pass arguments to blender ./blender.app/Contents/MacOS/blender --debug-gpu.

You can use > to save the output to a file: ./blender.app/Contents/MacOS/blender --debug-gpu > output.txt

Here's the file !
Hope it will help you to fix that bug !
Sorry for the wait, I tried to do the command a few times and didn't work. !

There doesn't seem to be anything odd in the output.

@Clément Foucault (fclem) any ideas? I think this might be hard to fix as I doubt any of the developers will be able to reproduce this.

We had some similar reports. Using debug print was making the lag vanish.

@Camille (Ekiwnox) Can you try launching blender using :

./blender.app/Contents/MacOS/blender --debug-value 23

Hi Clément, I already changed the value to 23 directly on blender and it was really smooth. Can try again through de Terminal if it's different.
Tell me how I can help you ! :-)

Sebastian Parborg (zeddb) raised the priority of this task from Needs Information from User to Normal.Jan 30 2019, 2:51 PM

Is there an other issue I should merge this into?

Still an issue on the 2.90 2019-02-08 !
Does anyone need some help to find where the lags come from ? :-o

Brecht Van Lommel (brecht) renamed this task from Lagging to macOS viewport lagging.Mar 19 2019, 10:50 AM

Basically there is a "missing" glFlush (or glFinish) somewhere that seems to create a performance issue on those macs. But without access to the faulty hardware I cannot know where to put it. Or I can put it at random and hope for the best...

Brecht Van Lommel (brecht) raised the priority of this task from Normal to Confirmed, High.Mar 25 2019, 12:14 PM

Have not confirmed the issue myself, but marking as high priority since this has been reported many times.

Since I seem to have some of the faulty hardware, I did some research on this issue.

It appears that the window compositor skips some of the application's rendered frames when there's a high demand on GPU resources. I observed that this behavior happens when the amount of workload is enough to saturate the GPU (i.e., below 60fps), meaning once it hits below 60fps, the performance deteriorates faster than it should. Unfortunately, the exact mechanism is unknown. It might be based on GPU queue pressure because we've seen that the --debug-value 23 option, which introduces full CPU/GPU synchronization via glFinish, seems to alleviate the issue.

macOS 10.14.4 switched NSOpenGLView to a Metal-based implementation, so Instruments now can be used to diagnose OpenGL presentation issues.

This is how it looks like on an ideal condition:

"GPU 1 (Unknown)" shows the OpenGL commands generated by Blender. The rendered image is blitted into a swapchain image ("GPU 1 (Blit)"). Finally, the image is displayed to the screen ("Display 2"). The color of rectangles indicates relationship between command buffer execution and presented frames. Thus in this example, all rendered frames are presented as expected.

The chart turns into something like this as the frame time rises:

The frame time is roughly 16ms (measured by the distance between blit operations), so it would look smooth *if* all frames were displayed. However, as shown in "Display 2", two thirds of the frames (the green and blue ones) were simply not presented.

There are numerous ways to present OpenGL contents, some of which are described in a Google Chrome design document:

  • NSOpenGLView — This is what Blender currently does.
  • NSOpenGLView with CALayer backing — No improvements were seen. Not sure how this is different from this option since NSOpenGLView is backed by CALayer by default anyway.
  • CAOpenGLLayer — Uses a pull-style API, thus inapplicable

I tried another option and found it effective:

  • CAMetalLayer — The issue was non-existent. This is similar to what NSOpenGLView does under the hood (as of macOS 10.14.4) except for using a public API. It's unknown why this option gives a better result. As shown in the following chart, display updates are now completely synchronized with the rendering of Blender's window:

Thanks a lot for the investigation! I guess ideally we could find a simpler fix, but if that's difficult this seems reasonable.

Could you submit this for code review?
https://developer.blender.org/differential/diff/create/

There seems to be mixed space and tabs indentation.

From the patch, it seems this requires bumping the minimum supported macOS version from 10.9 to 10.11? That's probably fine and something we already wanted to do.

@Tomoaki Kawada (yvt) That's some impressive work you did here! Did you try a simpler approach first? like adding glFlush at some places to see if it fixes it. (this should not have performance implication).

Adding glFinish would definitely decrease performance but maybe that's a lesser evil.

In the end, if adding a base Metal layer is the only solution I don't have any objection.

@Brecht Van Lommel (brecht) Submitted here: D4619

@Clément Foucault (fclem) I didn't try glFlush because finding the right place to insert seemed impossible (it would be probably timing-dependent, assuming there's one). Another thing I tried was adding [CATransaction commit] after [m_openGLContext flushBuffer] (motivated by the internal implementation of CAMetalLayer), which only had a mediocre effect.

just adding confirmation that i see this lag as well, and it moves very smoothly with

--debug-value 23

Machine Specs:
macOS 10.14.3 (18D109)
MacBook Pro (Retina, 15-inch, Mid 2015)
2.8 GHz Intel Core i7
16 GB 1600 MHz DDR3
AMD Radeon R9 M370X 2048 MB
Intel Iris Pro 1536 MB

LuisG (LuisG) added a subscriber: LuisG (LuisG).EditedMar 31 2019, 11:58 AM

Hi, same problem here. Viewport rotation, panning and zooming is smooth in 2.79 but lags terribly in 2.8 (with same scene loaded in both). Disabling grid and axis display in Overlays alleviates this problem, but overall it never reaches the smoothness of 2.79

Specs:
macOS 10.14.4
Macbook Pro (Retina 15-inch, late 2016)
2.6 GHz Intel Core i7
16 GB 2133 MHz LPDDR3
Radeon Pro 450 2 GB

For me it's the same as LuisG describes.

My specs:
macOS 10.13.6 (High Sierra)
iMac (Retina 5K, 27 inch, late 2015)
3,2 GHz Intel Core i5
32 GB 1867 MHz DDR3
AMD Radeon R9 M380 2048 MB

can some one send me the D4619 patched blender 2.8 file, i am having trouble with "make" part.

Furkan (furkan161) added a comment.EditedApr 13 2019, 11:02 PM

okey i tried D4619 path but it did not worked for me

Operating system: mac os
Graphics card: Radeon Pro 555 2 GB

Blender Version 2.8

lag and freeze problem while changing segments on add "uv sphere"
https://dev-files.blender.org/file/data/6pz2i5eay4to5ld3sq2j/PHID-FILE-hroo76ijkhcebdms45tk/Ekran_Resmi_2019-04-05_22.55.35.png

@Furkan (furkan161) I think it’s a pretty normal and OS-independent behavior that it lags a lot when creating a mesh with a large number of elements. D4619 addresses a specific issue in macOS’s presentation path and doesn’t magically make everything faster.

Is this patch going to be implemented in the main 2.8 version available for download on the Blender website?. I'm downloading each new build on a daily basis, but so far, the issue with the viewport lag doesn't seem to be fixed yet.

Yes, we will review it and commit a solution for this bug, should not be too long.

I am running the latest version of Blender on my MacBook Pro and I still have the same issue, the viewport jumps from smooth to laggy constantly.

MacBook Pro (Retina, 15-inch, Late 2013)
Operating system: macOS Mojave (10.14.4)
Processor: 2.3 GHz Intel Core i7
Memory: 16 GB 1600 MHz DDR3
Graphics card 1: Intel Iris Pro 1536 MB
Graphics card 2: NVIDIA GeForce GT 750M with 2GB of GDDR5 memory and automatic graphics switching

Same on macOS Mojave !
Macbook Pro Retina Mid 2012
2.3 GHz Intel Core i7
8 GB 1600 MHz DDR3

I still have this lag with the last version of Blender. Today I tried to rallback to the 2.79 and I was impressed how smooth is the old version... :-(

Brecht Van Lommel (brecht) closed this task as Resolved.Sun, Jun 2, 1:08 PM

@Tomoaki Kawada (yvt)'s solution was committed now, which hopefully resolves all the issue here.