macOS viewport lagging #60043

New Issue

Camille · 2019-01-01T23:25:49+01:00

Camille commented

2019-01-01 23:25:49 +01:00

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 : 4d795cee49
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.

**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.

Camille commented

2019-01-01 23:25:49 +01:00

Added subscriber: @Ekiwnox

blender-admin commented

2019-01-01 23:25:49 +01:00

#63026 was marked as duplicate of this issue

blender-admin commented

2019-01-01 23:25:49 +01:00

#63322 was marked as duplicate of this issue

blender-admin commented

2019-01-01 23:25:49 +01:00

#56996 was marked as duplicate of this issue

blender-admin commented

2019-01-01 23:25:49 +01:00

#62560 was marked as duplicate of this issue

blender-admin commented

2019-01-01 23:25:49 +01:00

#62705 was marked as duplicate of this issue

blender-admin commented

2019-01-01 23:25:49 +01:00

#61068 was marked as duplicate of this issue

Sebastian Parborg commented

2019-01-24 16:04:45 +01:00

Added subscriber: @ZedDB

Sebastian Parborg commented

2019-01-24 16:04:45 +01:00

Is this still an issue with the latest blender beta?

Camille commented

2019-01-24 20:43:11 +01:00

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.

Sebastian Parborg commented

2019-01-24 21:24:17 +01:00

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?

Camille commented

2019-01-26 18:29:17 +01:00

In #60043#606365, @ZedDB wrote:
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

> In #60043#606365, @ZedDB wrote: > 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

Sebastian Parborg commented

2019-01-26 19:14:11 +01:00

https://docs.blender.org/manual/en/latest/render/workflows/command_line.html

Camille commented

2019-01-27 20:40:47 +01:00

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 !

Sebastian Parborg commented

2019-01-27 20:45:55 +01:00

Do you have any experience using the terminal?

Camille commented

2019-01-27 20:47:22 +01:00

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

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

Sebastian Parborg commented

2019-01-27 21:24:45 +01:00

Ok, open up the terminal.

The three basic commands you need to know is:

cd Change Directory

lsList 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

Ok, open up the terminal. The three basic commands you need to know is: `cd` **C**hange **D**irectory `ls`**L**ist **D**irectory (contents) `pwd` **P**rint name of current/**W**orking **D**irectory 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`

Camille commented

2019-01-29 21:42:40 +01:00

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. !

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. ! [output.txt](https://archive.blender.org/developer/F6446366/output.txt)

Sebastian Parborg commented

2019-01-30 01:20:26 +01:00

Added subscriber: @fclem

Sebastian Parborg commented

2019-01-30 01:20:26 +01:00

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

@fclem any ideas? I think this might be hard to fix as I doubt any of the developers will be able to reproduce this.

There doesn't seem to be anything odd in the output. @fclem any ideas? I think this might be hard to fix as I doubt any of the developers will be able to reproduce this.

Clément Foucault commented

2019-01-30 01:36:32 +01:00

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

@Ekiwnox Can you try launching blender using :

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

We had some similar reports. Using debug print was making the lag vanish. @Ekiwnox Can you try launching blender using : `./blender.app/Contents/MacOS/blender --debug-value 23`

Camille commented

2019-01-30 11:51:52 +01:00

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 ! :-)

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 ! :-)

Clément Foucault was assigned by Sebastian Parborg

2019-01-30 14:51:47 +01:00

Sebastian Parborg commented

2019-01-30 14:51:47 +01:00

Is there an other issue I should merge this into?

Sebastian Parborg commented

2019-01-31 17:39:25 +01:00

Added subscriber: @BobJamZ

Camille commented

2019-02-10 18:22:30 +01:00

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

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 changed title from ~~Lagging~~ to macOS viewport lagging

2019-03-19 10:50:24 +01:00

Sebastian Parborg commented

2019-03-19 17:25:45 +01:00

Added subscribers: @ruja, @intrigus-3

Clément Foucault commented

2019-03-20 01:26:07 +01:00

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...

yvt commented

2019-03-24 04:24:01 +01:00

Added subscriber: @TomoakiKawada

Brecht Van Lommel commented

2019-03-25 12:10:20 +01:00

Added subscribers: @FrederikStorm, @aetharr, @WilliamReynish

Brecht Van Lommel commented

2019-03-25 12:11:50 +01:00

Added subscribers: @PawelBzyl, @RoranKladivo, @stefmalawi, @nexuz6, @cataalinux, @bopieds, @Abrases, @mont29, @brecht, @lichtwerk

Brecht Van Lommel commented

2019-03-25 12:14:09 +01:00

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

M commented

2019-03-26 23:34:48 +01:00

Added subscriber: @postcom

yvt commented

2019-03-29 09:39:50 +01:00

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:
exprimental-patch-metal-presentation.diff

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:
{F6897912}

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: ![Screen Shot 2019-03-29 at 0.04.21.jpg](https://archive.blender.org/developer/F6897875/Screen_Shot_2019-03-29_at_0.04.21.jpg) "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: ![Screen Shot 2019-03-29 at 0.33.40.jpg](https://archive.blender.org/developer/F6897877/Screen_Shot_2019-03-29_at_0.33.40.jpg) 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](https://docs.google.com/document/d/19YX5WYnpJj-h9nMM4r5WwlGOT99OQ7aEAm2DhWl-Ltg/edit): - `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: [exprimental-patch-metal-presentation.diff](https://archive.blender.org/developer/F6897881/exprimental-patch-metal-presentation.diff) - `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: {[F6897912](https://archive.blender.org/developer/F6897912/Screen_Shot_2019-03-29_at_17.30.37.jpg)}![Screen Shot 2019-03-29 at 0.30.29.jpg](https://archive.blender.org/developer/F6897894/Screen_Shot_2019-03-29_at_0.30.29.jpg)

Brecht Van Lommel commented

2019-03-29 15:40:25 +01:00

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.

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.

Clément Foucault commented

2019-03-29 15:49:05 +01:00

@TomoakiKawada 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.

@TomoakiKawada 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.

yvt commented

2019-03-30 09:07:12 +01:00

@brecht Submitted here: D4619

@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.

@brecht Submitted here: [D4619](https://archive.blender.org/developer/D4619) @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.

Michelangelo Capraro commented

2019-03-31 01:44:39 +01:00

Added subscriber: @mcapraro

Michelangelo Capraro commented

2019-03-31 01:44:39 +01:00

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

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 commented

2019-03-31 11:58:20 +02:00

Added subscriber: @LuisG-2

LuisG commented

2019-03-31 11:58:20 +02:00

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

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

Michael Helmrich commented

2019-04-04 10:56:29 +02:00

Added subscriber: @uhuruguru

Michael Helmrich commented

2019-04-04 10:56:29 +02:00

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

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

Brecht Van Lommel commented

2019-04-06 15:24:30 +02:00

Added subscriber: @furkan161

Furkan commented

2019-04-06 16:33:49 +02:00

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

can some one send me the [D4619](https://archive.blender.org/developer/D4619) patched blender 2.8 file, i am having trouble with "make" part.

Furkan commented

2019-04-13 23:02:28 +02:00

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

okey i tried [D4619](https://archive.blender.org/developer/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

yvt commented

2019-04-14 08:55:18 +02:00

@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.

@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](https://archive.blender.org/developer/D4619) addresses a specific issue in macOS’s presentation path and doesn’t magically make everything faster.

LuisG commented

2019-04-16 17:50:14 +02:00

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.

Brecht Van Lommel commented

2019-04-16 18:03:25 +02:00

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

Giuseppe Bufalo commented

2019-05-02 14:43:43 +02:00

Added subscriber: @giuseppebufalo

Giuseppe Bufalo commented

2019-05-02 14:43:43 +02:00

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

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

Camille commented

2019-05-14 23:26:44 +02:00

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... :-(

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 commented

2019-05-21 11:16:50 +02:00

Added subscribers: @olyandros, @ideasman42

Brecht Van Lommel commented

2019-06-02 13:08:38 +02:00

Changed status from 'Open' to: 'Resolved'

Brecht Van Lommel closed this issue

2019-06-02 13:08:38 +02:00

Brecht Van Lommel commented

2019-06-02 13:08:38 +02:00

@TomoakiKawada's solution was committed now, which hopefully resolves all the issue here.

Michael Helmrich commented

2019-07-11 09:29:14 +02:00

For me, the lag is still there with the newest version:

Date: 2019-07-10 15:05
Hash: bb7b741d2f

It occurs when an object (even the default cube) is selected and the Overlays/Object/Outline Selected checkbox is checked.
If the overlay is disabled or the cube is deselected, the lag disappears.

Here is my system info from my previous comment:
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

For me, the lag is still there with the newest version: Date: 2019-07-10 15:05 Hash: bb7b741d2f1c It occurs when an object (even the default cube) is selected and the Overlays/Object/Outline Selected checkbox is checked. If the overlay is disabled or the cube is deselected, the lag disappears. Here is my system info from my previous comment: 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

Samuel Partridge commented

2019-08-21 21:53:49 +02:00

Added subscriber: @CertifiedDoc

Samuel Partridge commented

2019-08-21 21:53:49 +02:00

I have the same issue. It does not exist in 2.79b, but it persists in both the 2.8 official release and the 2.8.1 build from 2019-08-21 (Hash 3d8f158697).
2011 Macbook Pro
OS: Mac OS High Sierra 10.13.6
CPU: 2.2 GHz Intel Core i7 2720 QM
GPU: Intel HD 3000, AMD HD 6750M

There appears to be an issue where OS X will not automatically switch from the integrated to discrete GPU when Blender launches.
There is a workaround for this problem: disable automatic graphics switching in OS X System Preferences.

When I switch to only using the discrete GPU, I have no performance issues whatsoever. However, if I let the system decide, it defaults to the low-power HD 3000 integrated GPU. When that happens blender's performance is abysmal, even on the default scene. (It also causes rendering errors in Eevee, which I believe are related to incompatibilities with the HD 3000 GPU, but those are a totally different issue).

I have the same issue. It does not exist in 2.79b, but it persists in both the 2.8 official release and the 2.8.1 build from 2019-08-21 (Hash 3d8f1586973b). 2011 Macbook Pro OS: Mac OS High Sierra 10.13.6 CPU: 2.2 GHz Intel Core i7 2720 QM GPU: Intel HD 3000, AMD HD 6750M There appears to be an issue where OS X will not automatically switch from the integrated to discrete GPU when Blender launches. There is a workaround for this problem: disable automatic graphics switching in OS X System Preferences. When I switch to only using the discrete GPU, I have no performance issues whatsoever. However, if I let the system decide, it defaults to the low-power HD 3000 integrated GPU. When that happens blender's performance is abysmal, even on the default scene. (It also causes rendering errors in Eevee, which I believe are related to incompatibilities with the HD 3000 GPU, but those are a totally different issue).

Harley Denham commented

2019-10-07 12:22:51 +02:00

Added subscriber: @qxoko

Harley Denham commented

2019-10-07 12:22:51 +02:00

I am also experiencing the same issue, even after the above patch.

Date: 07.10.19
Version: 2.80.75 Stable Release

(I apologise, I do not know where to find the 2.80 hash string)

MacBook Pro (15-inch, 2018)
macOS Mojave 10.14.6
6 Core 2.2 GHz Intel Core i7
16 GB 2400 MHz DDR4
Radeon Pro 555X 4 GB + Intel UHD Graphics 630 1536 MB

The solution I have discovered is that Blender 2.8 runs entirely lag/jitter-free on any monitor whose scaling factor is set to "Default for display", regardless of the actual resulting scale factor of the screen. For instance, my MacBook's built-in display's "Default" setting is somewhere around 150%, while my external monitor's "Default" is the standard 100%. On both monitors, at these values, Blender runs completely smoothly.

Setting one screen to a non-default scale factor will cause Blender to lag only on that monitor. Dragging the app over (without restarting) to the default-scale monitor and manipulating the viewport is then lag-free. Returning Blender to the non-default monitor reinstates the lag.

Whatever macOS considers "Default for display" for each monitor seems to correlate directly with Blender's viewport lag when displayed on it.

Edit: In the latest experimental build at writing - hash 54a9649e26 - the issue is lessened but appears to persist. The same scaling behaviour I have described above also persists.

I am also experiencing the same issue, even after the above patch. Date: 07.10.19 Version: 2.80.75 Stable Release (I apologise, I do not know where to find the 2.80 hash string) MacBook Pro (15-inch, 2018) macOS Mojave 10.14.6 6 Core 2.2 GHz Intel Core i7 16 GB 2400 MHz DDR4 Radeon Pro 555X 4 GB + Intel UHD Graphics 630 1536 MB The solution I have discovered is that Blender 2.8 runs entirely lag/jitter-free on any monitor whose scaling factor is set to "Default for display", regardless of the actual resulting scale factor of the screen. For instance, my MacBook's built-in display's "Default" setting is somewhere around 150%, while my external monitor's "Default" is the standard 100%. On both monitors, at these values, Blender runs completely smoothly. Setting one screen to a non-default scale factor will cause Blender to lag only on that monitor. Dragging the app over (without restarting) to the default-scale monitor and manipulating the viewport is then lag-free. Returning Blender to the non-default monitor reinstates the lag. Whatever macOS considers "Default for display" for each monitor seems to correlate directly with Blender's viewport lag when displayed on it. Edit: In the latest experimental build at writing - hash 54a9649e2636 - the issue is lessened but appears to persist. The same scaling behaviour I have described above also persists.

Jay Weeks commented

2019-12-19 19:03:18 +01:00

Added subscriber: @jpweeks

Jay Weeks commented

2019-12-19 19:03:18 +01:00

I can reproduce the same behavior as @qxoko

Date: 12.19.19
Version: 2.81 2019-11-20

MacBook Pro (15-inch, 2018)
macOS Mojave 10.14.6
6 Core 2.9 GHz Intel Core i9
32 GB 2400 MHz DDR4
Radeon Pro 560X 4 GB + Intel UHD Graphics 630 1536 MB

I can reproduce the same issues with non-"Default" display scaling in System Preferences. What's odd is this never affected Blender 2.79 on the same hardware.

I can reproduce the same behavior as @qxoko Date: 12.19.19 Version: 2.81 2019-11-20 MacBook Pro (15-inch, 2018) macOS Mojave 10.14.6 6 Core 2.9 GHz Intel Core i9 32 GB 2400 MHz DDR4 Radeon Pro 560X 4 GB + Intel UHD Graphics 630 1536 MB I can reproduce the same issues with non-"Default" display scaling in System Preferences. What's odd is this never affected Blender 2.79 on the same hardware.

Muhammad Fadhlika commented

2020-06-23 18:26:57 +02:00

Added subscriber: @valdez

Muhammad Fadhlika commented

2020-06-23 18:26:57 +02:00

I also can reproduce the same behavior as @qxoko

Date: 23.06.20

MacBook Pro (13-inch, 2017, Two Thunderbolt 3 ports)
macOS Catalina 10.15.5
2,3 GHz Dual-Core Intel Core i5
8 GB 2133 MHz LPDDR3
Intel Iris Plus Graphics 640 1536 MB

The issue happen on 2.8x release on non 100% display scaling. It doesn't happen on Blender 2.79 with same hardware and display scaling configuration

I also can reproduce the same behavior as @qxoko Date: 23.06.20 MacBook Pro (13-inch, 2017, Two Thunderbolt 3 ports) macOS Catalina 10.15.5 2,3 GHz Dual-Core Intel Core i5 8 GB 2133 MHz LPDDR3 Intel Iris Plus Graphics 640 1536 MB The issue happen on 2.8x release on non 100% display scaling. It doesn't happen on Blender 2.79 with same hardware and display scaling configuration

Giuseppe Bufalo commented

2020-06-24 02:06:47 +02:00

Removed subscriber: @giuseppebufalo

Jas commented

2020-08-08 06:16:12 +02:00

Added subscriber: @Jas64

Jas commented

2020-08-08 06:16:12 +02:00

I am using Blender v2.83.4 and I also see this issue. Simply opening a window of blender and trying to rotate the view is extremely laggy.

My specs are:
MacBook Pro (Retina, 13-inch, Early 2015)
8 GB 1867 MHz DDR3
Intel Iris Graphics 6100 1536 MB
Mac OS Catalina - 10.15.6

Running Blender with the "--debug-value 23" did not help.

I am using Blender v2.83.4 and I also see this issue. Simply opening a window of blender and trying to rotate the view is extremely laggy. My specs are: MacBook Pro (Retina, 13-inch, Early 2015) 8 GB 1867 MHz DDR3 Intel Iris Graphics 6100 1536 MB Mac OS Catalina - 10.15.6 Running Blender with the "--debug-value 23" did not help.

Jas commented

2020-08-09 08:49:32 +02:00

I realized that decreasing my resolution helps a lot. I am using EasyRes from the AppStore to go from 1440x900 retina to 1440x900 non-retina, and this fixes the issue. The screen quality is reduced quite a bit, but performance is smooth and very pleasing.

Camille commented

2020-08-10 21:47:56 +02:00

I must say that it's also the case for the surface pro 4 on the last version of Blender. Don't really know why. It's related to the resolution of the computer. But the computer is set on the recommanded settings for the surface...

Luz commented

2020-08-25 21:35:44 +02:00

Added subscriber: @Lucylove

Luz commented

2020-08-25 21:35:44 +02:00

This also fixes the problem on my late 2013 13” MacBook Pro

In #60043#993282, @Jas64 wrote:
I realized that decreasing my resolution helps a lot. I am using EasyRes from the AppStore to go from 1440x900 retina to 1440x900 non-retina, and this fixes the issue. The screen quality is reduced quite a bit, but performance is smooth and very pleasing.

This also fixes the problem on my late 2013 13” MacBook Pro > In #60043#993282, @Jas64 wrote: > I realized that decreasing my resolution helps a lot. I am using EasyRes from the AppStore to go from 1440x900 retina to 1440x900 non-retina, and this fixes the issue. The screen quality is reduced quite a bit, but performance is smooth and very pleasing.

Jas commented

2020-09-26 21:12:17 +02:00

Hello everyone. I found a better solution. Instead of changing/reducing your entire systems resolution, you can simply set blender itself to a lower resolution. Instructions:

Go to your applications folder in finder
Right click on blender
Select "Get Info"
Under "General", check "Open In Low Resolution"

This is much better than toggling resolutions everytime you wanna use blender, and it also prevents other apps from having to work in low resolution, which makes your other apps experience poor.

Hello everyone. I found a better solution. Instead of changing/reducing your entire systems resolution, you can simply set blender itself to a lower resolution. Instructions: 1) Go to your applications folder in finder 2) Right click on blender 3) Select "Get Info" 4) Under "General", check "Open In Low Resolution" This is much better than toggling resolutions everytime you wanna use blender, and it also prevents other apps from having to work in low resolution, which makes your other apps experience poor.

Paweł commented

2020-09-27 21:29:45 +02:00

In #60043#1024115, @Jas64 wrote:
Hello everyone. I found a better solution. Instead of changing/reducing your entire systems resolution, you can simply set blender itself to a lower resolution. Instructions:

Go to your applications folder in finder

Right click on blender

Select "Get Info"

Under "General", check "Open In Low Resolution"

This is much better than toggling resolutions everytime you wanna use blender, and it also prevents other apps from having to work in low resolution, which makes your other apps experience poor.

For me, it is impossible to select this option. Do I need to do anything else to mark it?

> In #60043#1024115, @Jas64 wrote: > Hello everyone. I found a better solution. Instead of changing/reducing your entire systems resolution, you can simply set blender itself to a lower resolution. Instructions: > 1) Go to your applications folder in finder > 2) Right click on blender > 3) Select "Get Info" > 4) Under "General", check "Open In Low Resolution" > > This is much better than toggling resolutions everytime you wanna use blender, and it also prevents other apps from having to work in low resolution, which makes your other apps experience poor. For me, it is impossible to select this option. Do I need to do anything else to mark it?

Jas commented

2020-09-28 00:46:17 +02:00

"Impossible" as in you cannot select it, or is it not there at all? And are you on Catalina?

Paweł commented

2020-09-30 12:02:15 +02:00

It cannot be selected. I am using MacOS Big Sur (Beta)

Dmitry commented

2020-12-15 08:07:05 +01:00

Added subscriber: @Rezoob

Dmitry commented

2020-12-15 08:07:05 +01:00

hey guys, nothing new on this?
Still issue low viewport performance (in comparision to 2.79) from 2.83 (Catalina) and 2.91.0 (Big Sur). It sounded like almost fixed?
"Open in Low Resolution" works BUT this is very bad looking on retina, AND 2.79 runs in normal resolution smoothly.
Is this bug and somedays will be solved or this is impossible to solve on 2.8+?
I started to learn 2.79 as it has much better performace :(

hey guys, nothing new on this? Still issue low viewport performance (in comparision to 2.79) from 2.83 (Catalina) and 2.91.0 (Big Sur). It sounded like almost fixed? "Open in Low Resolution" works BUT this is very bad looking on retina, AND 2.79 runs in normal resolution smoothly. Is this bug and somedays will be solved or this is impossible to solve on 2.8+? I started to learn 2.79 as it has much better performace :(

Timo Takala commented

2021-04-25 12:00:16 +02:00

Added subscriber: @Timo-1

Timo Takala commented

2021-04-25 12:00:16 +02:00

This was finally fixed for me in 3.0 alpha.

I had laggy 3d view perfomance since 2.8 on a Hackintosh Mojave with UHD display with scaling. Probably less than 30 fps when rotating viewport in default scene. Blender 2.79 was smooth and now 3.0 alpha also.

Thanks, team!

This was finally fixed for me in 3.0 alpha. I had laggy 3d view perfomance since 2.8 on a Hackintosh Mojave with UHD display with scaling. Probably less than 30 fps when rotating viewport in default scene. Blender 2.79 was smooth and now 3.0 alpha also. Thanks, team!

Dmitry commented

2021-04-25 12:22:38 +02:00

Unfortunately cannot confirm for 3.0 alpha on
MacBook Pro (Retina, 15-inch, Late 2013), 2 GHz Quad-Core Intel Core i7, Intel Iris Pro 1536 MB,
Big Sur 11.2.3

still same performance.

Checked also latest 2.92 - the same.

Unfortunately cannot confirm for 3.0 alpha on MacBook Pro (Retina, 15-inch, Late 2013), 2 GHz Quad-Core Intel Core i7, Intel Iris Pro 1536 MB, Big Sur 11.2.3 - still same performance. Checked also latest 2.92 - the same.

Daniel commented

2021-10-09 00:08:20 +02:00

Added subscriber: @Danvi

Daniel commented

2021-10-09 00:08:20 +02:00

In #60043#993282, @Jas64 wrote:
I realized that decreasing my resolution helps a lot. I am using EasyRes from the AppStore to go from 1440x900 retina to 1440x900 non-retina, and this fixes the issue. The screen quality is reduced quite a bit, but performance is smooth and very pleasing.

Thank you very much for the tip. Out of everything I've read this is the one that has surprisingly worked.

By the way in EasyRes when you choose 'Standart' instead of 'Retina', the quality and detail of the text and widgets decreases a lot. I personally don't like it and it blurs my vision.
So I chose Retina mode with the following resolutions: 825x525 or 1024x640.
Then in Blender Preferences: Interface > Resolution Scale > Set to half (0.5).
The quality is good and the viewport (Lookdev and Rendered) is now super fluid. No lagging.

PS: Change the mac screen resolution (whether through EasyRes or not) before opening Blender.

> In #60043#993282, @Jas64 wrote: > I realized that decreasing my resolution helps a lot. I am using EasyRes from the AppStore to go from 1440x900 retina to 1440x900 non-retina, and this fixes the issue. The screen quality is reduced quite a bit, but performance is smooth and very pleasing. Thank you very much for the tip. Out of everything I've read this is the one that has surprisingly worked. By the way in EasyRes when you choose 'Standart' instead of 'Retina', the quality and detail of the text and widgets decreases a lot. I personally don't like it and it blurs my vision. So I chose Retina mode with the following resolutions: 825x525 or 1024x640. Then in Blender Preferences: Interface > Resolution Scale > Set to half (0.5). The quality is good and the viewport (Lookdev and Rendered) is now super fluid. No lagging. PS: Change the mac screen resolution (whether through EasyRes or not) before opening Blender.

Sign in to join this conversation.