Performance degradation of Principled Shader in Eevee when metallic is turned off #66231
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
25 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#66231
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
System Information
Operating system: Darwin-18.6.0-x86_64-i386-64bit 64 Bits
Graphics card: AMD Radeon Pro 560X OpenGL Engine ATI Technologies Inc. 4.1 ATI-2.9.26
Blender Version
Broken: version: 2.80 (sub 74), branch: master, commit date: 2019-06-28 22:08, hash:
648e8a1f1dWorked: (optional)
Short description of error
In Eevee, when I turn metallic from 1.0 to 0.0 in principled shader, viewport becomes extremely sluggish.
Exact steps for others to reproduce the error
See the attached .blend file.
CSGBox1.blend
Follow these steps to observe the problems:
Added subscriber: @ChuckOcheret
#71325 was marked as duplicate of this issue
#74448 was marked as duplicate of this issue
#74276 was marked as duplicate of this issue
Added subscriber: @ZedDB
I can not reproduce this on my end. Does this happen on windows too? (If you can check that is)
I do not see this problem on my Windows machine. Of course, my Windows box has got dual GTX 1080Ti's. I still experience it on my MacBook Pro, which is where this was first reported. I rebuilt Blender today and the problem persists. It may be something specific to this scene since I have not noticed this before. The Knobs object is a duplicate of a cutter object I used with the BoolTools plug-in. I made the knobs visible again (and turned back on various Cycles options that BoolTool disables). But maybe BoolTools sets some other option that makes the Knobs object weird.
Added subscriber: @LazyDodo
Can't repro on windows either, try starting blender with the factory_startup batch files located in the same folder as blender.exe, perhaps it's an addon that is making life miserable for you.
Added subscriber: @deadpin
I can observe a very small perf hit (3%) using an older nVidia Quadro 600 on Win10
Set the timeline in motion and observe the debug output for Eevee (Debug Menu -> value 21) instead of trying to rotate the viewport:
So ugh just about 3% (same percentage drop for rendered display too). I wonder if some lighting calculations can be skipped if you're fully metallic instead of a di-electric and this drop is somewhat expected? Or maybe it's the AMD card/drivers?
Some more info. After a reboot, I don't feel the sluggishness very much at all. However, after loading the scene multiple times (e.g. revert) it gets more and more sluggish with metallic set to 0. Even if I restart blender, it continues to become increasingly sluggish over time. Therefore, I am suspecting that somehow MacOS is experiencing some sort of resource leak related to the GPU. Rebooting appears to be the only things I can find (so far) that gets me back to good performance. I can now get this performance issue with a simple cube with the default shader (Principled BSDF) such that metallic 1 gives great performance and 0 gives horrible performance. Very weird. I'll try the suggestion with resetting to factory settings later today. I have been messing with BoolTool, HardOps, and BoxCutter. Never experienced this before.
Added subscriber: @WilliamReynish
@WilliamReynish can you reproduce this?
Added subscriber: @fixpoint
I have the exact same problem on my iMac Pro running Mojave. As soon as I adjust the metallic setting in my Principled BSDF element to anything other than 1, performance of the viewport goes from extremely fast to extremely sluggish (unusable).
When this happens, my CPU is pegged at 100% by the blender process. It does not seem to be using the GPU when metallic is set to any value other than 1. I can also confirm I can reproduce using the blender file Chuck attached when the bug was opened.
I tried rebooting like Chuck stated, but that makes no improvement, even temporary as it did for him. I've tried re-installing blender. I guess my point is that my blender install is going to be as bare bones as anyone given my lack of history with the program. I'm a complete noob and was going through my first online tutorial, when I discovered encountered this. So, for now, everything I do is metallic :-)
Here are the details on my system:
System Information
Operating system: Darwin-18.7.0-x86_64-i386-64bit 64 Bits
Graphics card: AMD Radeon Pro Vega 56 OpenGL Engine ATI Technologies Inc. 4.1 ATI-2.11.20
Blender Version
Broken: version: 2.80 (sub 75), branch: master, commit date: 2019-07-29 14:47, hash:
f6cb5f5449Worked: (optional)
I'm more that happy to assist troubleshooting and running whatever tests necessary. I am on vacation for Monday - Wednesday of the upcoming week, so I will have time to do as much testing as you need to help diagnose further.
It is still a problem for me on 2.81.
I discovered something interesting that may or may not be helpful for those debugging this issue. Through a series of appending collections to another scene, I'm able to view Chuck's box without any performance issues. Here are the exact steps I performed:
Move around viewport and performance is fast!!
rocks_highRes.blend
rocks_highRes.blend is from a free online tutorial that I've been using to learn Blender. I've uploaded it so you can perform the exact same steps. Oddly, if I just try to append Chuck's box to an new scene, the performance is horrible, just like it is when I open his scene directly. However, if I first append that high res rock collection, then append Chuck's box, the performance issues disappear.
Chuck, can you confirm if this works for you too?
Sorry for the delay in getting back on this. Somehow I missed it. Pete is correct. Oddly the steps above result in improved performance over my original scene (although the rocks are pink - missing textures). If I only append my CSGBox1 collection I still get the reduced performance. Very weird.
This is also behaving the exact same way with the latest master branch build and on a newer MacBook Pro.
Added subscriber: @jackdaw
I confirm that this happens on a iMac (Retina 5K, 27-inch, 2017).
Added subscriber: @GordonM
Can confirm that it happens here too.
Hardware:
Discovered it whilst following the tutorial at https://www.youtube.com/watch?v=zHv4VDoCwYc
Got as far as setting the materials in the node editor. As soon as I removed the metallic setting from the handle of the sword performance tanked.
If I hide the handle performance returns to normal.
If I hide everything BUT the handle performance returns to normal.
If I have the handle plus any metallic object visible at the same time performance tanks.
I have double-checked and can conform that the machine is currently using its primary GPU and not the low-power Intel GPU (Activity Monitor shows GPU: High Perf on the Energy tab)
If I import the model into the same version of Blender running on Windows 10 on the same hardware via Bootcamp performance is fine.
I thought it might have been an issue with the model I'd built during the tutorial, but the tutorial maker has provided the files he built for download at https://www.cgfasttrack.com/blender-fast-track so I tried it again with his sword file. The results were exactly the same.
Added subscriber: @JohnTheThird
There are several different bug reports floating around that I think are all related to the same thing (OSX/AMD only).
The function eevee_draw_background -> EEVEE_materials_draw_opaque -> GPU_batch_draw_advanced then goes into the AMD driver code and its continually calling SCCompileShader causing the slowness/lag. This is visible in this Instruments.app trace of a lagging viewport in Blender 2.82.6:
If you change the metallic setting of the BSDF, or enable Backface Culling or Blend Mode: Alpha Blend, the viewport frees up and the trace looks like this (no repeated calls to SCCompileShader)
Related:
#71398
#71325
#72051
My system: MacBook Pro/AMD Radeon Pro 5500M 8 GB/Catalina 10.15.2
If there is anything I can do to help further troubleshoot let me know. I am reading the source code but have no 3d experience so I'm pretty lost.
@JohnTheThird You are a scholar and a gentleman! Enabling backface culling got the performance back. Thanks.
Added subscriber: @davidmikucki
The 2.82 beta build from 23 Jan appears to have addressed this issue. I turned backface culling back on on the affected asset and didn't notice any slowdown. Can anyone else confirm that the issue is resolved?
Definitely still a problem with the test asset on this ticket as well as the other referenced tickets. As a further data point it's not just the viewport, the issue manifests in a final render as well, each sampling pass results in a call to SCCompileShader which slows the final render down significantly.
This is a side-by-side of a fast render on the right, and a slow render on the left.
I cannot reproduce on my MacBook when running Windows 10, so its obviously a bug in the OSX Radeon drivers, so it's probably nothing Blender can fix but perhaps could work around if we knew what was triggering the bug.
An update to OSX 10.15.3 did not resolve this issue. If the bug is in Apple's AMD drivers then it wasn't addressed in the latest update.
Still no fixes in the recent betas I’ve tried.
Given that Cycles GPU support is gone on macOS, and Eevee rendering has this and the metalness bug (that may be related to this one) that show performance to a crawl, rendering in Blender 2.81+ is severely broken on macOS.
I understand that creating a metal version of Cycles would be work intensive, but why can’t we even get a developer to reproduce this Eevee issue and look into it? If there is no desire to support Blender for macOS, I understand. But letting it lie with both of its included rendering engines is frustrating to users, even deceptive—since we can build out scenes and then find out that they simply won’t be renderable in a timely manner, despite having decent hardware that will render great when we switch to boot camp.
I don’t mean to seem ungrateful. Blender is amazing and I’ve used it for a long time. I guess I’m just asking for communication. If Blender rendering is all but dead on Mac with no plans to improve in the near future, can an announcement be made so we can all move on or switch to Windows/Linux?
Added subscriber: @girafic
I'm not sure if this has been explicitly fixed, or if some other fix is reducing the impact of this bug, but as of 2.82 final the test file I've been using (The textured and shaded sword from the CG Fast Track tutorial) no longer completely tanks the viewport performance. Can anybody confirm that they're experiencing better performance or that the bug in question has been patched?
EDIT: Spoke too soon.
The initial attempt to load the sword yielded acceptable performance, but following that up by loading the .blend attached to this ticket tanked performance again. What's more, attempting to load the sword back in did not see performance return, it remained tanked until I quit Blender.
Added subscribers: @fclem, @Jeroen-Bakker, @mont29
@Jeroen-Bakker, @fclem do you have any insight here? Although openGL and OSX is kind of a mine fields, so would rather consider that as known issue for now...
I have no idea why this happen. I don't have a Mac to reproduce.
However I can remember that we had a similar issue in the past with shader recompiling because of samplers changing binding points constantly. But here the shader is dead simple and has no user textures. Only the eevee utility textures are bound but their binding points should never change.
Added subscriber: @Jelleeey
I'm also on a mac having issues with extreme sluggish performance in eevee when there are multiple metallic shaders. For me changing the value to anything lower than 1 will restore performance to normal.
I posted on blenderartist forum, including video of the issue:
https://blenderartists.org/t/slow-performance-eevee-metallic-material-weird-issue/1209610
Added subscriber: @camot
I could reproduce this problem on multiple macs running Mojave or Catalina.
Even the most actual Mac Pro 2019 with AMD Vega II Pro behaves as reported here.
I can also confirm that Macs with NVidia GPUs are not affected.
However NVidia is not supported any more on MacOS.
Added subscribers: @mano-wii, @ankitm
The problem is still present on MacOS Catalina 10.15.3.
All Macs with AMD GPU are affected.
It is an ongoing issue and was reported by several users since 2.8 Beta quite some time ago.
My own report was first staged back in priority and then closed due to 'lack of input'
Some other users report was closed because the GPU in concern was too old.
Is there any chance the issue will be fixed in the near future?
@camot it is an Apple's AMD drivers issue, what you can do is to report this bug to Apple and AMD -->
https://feedbackassistant.apple.com/welcome
https://www.amd.com/report
https://twitter.com/AMD
https://www.amd.com/en/support/contact-email-form
Due to the amount of reports, I dare to put this as a high priority bug.
This is certainly an issue with the AMD + Mac opengl driver.
But it would be nice if someone with Mac and OpenGL experience could find out if we can workaround this problem within the blender code.
Added subscriber: @blenderrocket
Some relevant informations perhaps: https://github.com/libgdx/libgdx/pull/5893
Added subscribers: @ivanejg12, @BenjaminKleinert
This thread does seem quite important to the discussion here. Just as a note, this is not resolved in the latest 10.15.4 beta 19E258a (beta 5).
Still not corrected as of OSX 10.15.4.
Additionally the problem also seems to apply to the Glossy BSDF
Looks like this is going to get some attention soon. If it’s helpful at all, running 2.82a, this is not resolved in macOS 10.15.5 beta 1 or 2.
Removed subscriber: @deadpin
It would be interesting to know what exactly the underpinning OpenGL problem is.
Which OpenGL function is problematic?
Is there a short standalone isolated piece of code which can be compiled and demonstrates the problem?
For me it is difficult to report anything to Apple without some very simple test code exposing the problem
.
I think we cannot report in a way that tells Apple 'Look we have some performance issues in Blender. Can you please fix the problem?' I guess no developer will answer to this fluffy description.
Added subscriber: @nemediz
I did some debugging and it looks like the problem is the same as described here:
https:*stackoverflow.com/questions/42238124/gldrawelements-on-osx-has-high-cpu-usage .
"Constantly changing the texture slot number might force driver to recompile shader each time."
It looks like the uniform sampler binding change happens while drawing shading groups in a loop inside
'EEVEE_materials_draw_opaque -> DRW_draw_pass(psl->material_pass) -> drw_draw_pass_ex',
if there are multiple shading groups in the loop that use the same shader, and other shading groups (with different shader) are drawn in between.
Probably shader change causes it, only seen it with specular and principled shaders.
This is happening in CSGBox1.blend, as logging 'GPU_shader_uniform_texture' reveals:
shader draw begin MAVents_115
shader MAVents_115, uniform sampler location 23, number 0
shader MAVents_115, uniform sampler location 12, number 1
shader MAVents_115, uniform sampler location 10, number 2
shader MAVents_115, uniform sampler location 13, number 3
shader MAVents_115, uniform sampler location 18, number 4
shader MAVents_115, uniform sampler location 16, number 5
shader MAVents_115, uniform sampler location 8, number 6
shader draw begin MAKnobs_116 <--- shader change
shader MAKnobs_116, uniform sampler location 9, number 6
shader MAKnobs_116, uniform sampler location 24, number 0
shader MAKnobs_116, uniform sampler location 13, number 1
shader MAKnobs_116, uniform sampler location 11, number 2
shader MAKnobs_116, uniform sampler location 14, number 3
shader MAKnobs_116, uniform sampler location 19, number 4
shader MAKnobs_116, uniform sampler location 0, number 5
shader MAKnobs_116, uniform sampler location 17, number 7
shader draw begin MAVents_115 <--- back to MAVents_115
shader MAVents_115, uniform sampler location 23, number 0
shader MAVents_115, uniform sampler location 12, number 1
shader MAVents_115, uniform sampler location 10, number 2
shader MAVents_115, uniform sampler location 13, number 3
shader MAVents_115, uniform sampler location 18, number 4
shader MAVents_115, uniform sampler location 16, number 7 <--- uniform changed
shader MAVents_115, uniform sampler location 8, number 6
I'm very new to the Blender source code so don't know how to fix this, but a quick "hack" solved it on my computer (no idea if it has any side effects though). Before drawing the shading groups inside 'drw_draw_pass_ex', I grouped them by shader name, changing the draw order so that no shader change will take place between shading groups of the same shader. This seems to prevent the uniform sampler changes and recompilation.
So far no viewport lag in my tests (including CSGBox1).
Clearly, this is a driver bug, but hopefully a proper workaround is possible.
@nemediz could you attach your changes of the source code?
Only changed 'drw_draw_pass_ex'
draw_manager_exec.c
@nemediz thx for this proposal, on my AMD hackintosh it's working 👍 (see video attached)
Bildschirmvideo aufnehmen 2020-04-29 um 13.22.30.mp4
Added subscriber: @Samsara_71
Would just like to confirm the bug too. OSX 10.15.4 RX580 on an i7700k Hackintosh.
Fantastic that there is a fix/hack. Is there anyway to try this 'fixed' version of Blender on my Rig, as suffering from this bug badly in an animation I'm doing. cheers
Thank you @nemediz ! The patch works great on my MacBook Pro 16" OSX 10.15.4 AMD Radeon Pro 5500M 8 GB.
The patch solves the lag for me for most scenes, however the attached scene with 2 DecalMachine decals on a box still lags at a specific point when rotating the box in the viewport in EEVEE. Not sure if its related or not but just throwing it out as another data point.
laggy on mac even with patch.blend
@JohnTheThird: I'm glad that I could help, but as your example shows, this hack won't work always.
At least I was able to verify that the problem is the same here too: uniform texture binding points get changed.
In your scene there are only 2 shading groups in the draw loop, but at some point, their order get flipped and that's when the change happens.
Big thanks to @nemediz for figuring this out. Unfortunately the hack is a hack. It won't work for every scene, can be slow and can lead to invalid draw order of shading groups. Reordering shading groups is not a valid operation unless being done explicitely (see DRW_pass_sort_shgroup_z).
But I understand the root of the bug:
MaterialseeEeveeMaterialShadingGroups *emsg = BLI_ghash_lookup(material_hash, (const void *)ma);So there is 2 different shading groups because of different data.
So multiple way to solve this:
Both are quite tricky:
Any of the 2 should be enough to fix the issue.
Added subscribers: @DineshKumar, @D7470, @filibis
Added subscriber: @pablovazquez
@pablovazquez i think this might be the reason for the eevee shader refactor you mentioned in the stream today (https://youtu.be/2mA-TRrJrbE?t=774)
Added subscriber: @danee
This issue was referenced by
b18c2a3c41The world may be burning, but today is the day EEVEE is finally usable on OSX! I tried out @fclem latest commit and all test files I have no longer show any lag or shader recompilation. I know it sucks to have to work around other people's crappy software (cough Apple) but thank you for going the extra mile. Us Mac-heads will be forever grateful.
Changed status from 'Needs Developer To Reproduce' to: 'Resolved'
A lot of work went into this. Hopefully it should benefit all platform.
This issue is likely to have been fixed at
a1f9eebc0b.Confirming that it works on my 16 inch MacBook Pro. I can load up the ArchVis test scene and it works without any issues. Thank you so much for all your work on this. It really is a game changer for Mac, I think.
I can confirm it works as well, tested on both D700 and Radeon Pro 580. Thank you so much for the work Clément, this is fantastic.
Added subscriber: @AleOros
I am very ashamed to ask this. I am new to blender, and have big troubles on my Macbook Pro, specially with eeve. My computer has the following characteristics.
By seeing the thread, I saw that you were able to fix the lag, but since Im new to blender, and don't know nothing about coding, I don't know how can I implement the commit.
Once again Im sorry if my question seems very stupid. But I would really like to solve this problem to continue learning and doing amazing stuff with Blender.
Thank you very much for you patience.
@AleOros nothing to be ashamed of.
Download the experimental 2.90 version which is built with the commit . https://builder.blender.org/download/
You can also build blender from source https://wiki.blender.org/wiki/Building_Blender/Mac
ask about it on https://devtalk.blender.org/c/blender/building-blender/11
or https://blender.chat
Thank you very much @ankitm! I will do it right now =)
In 2.83, the issue seems to be resolved as well.
Removed subscriber: @filibis