Cycles rendered 3DViewport massive performance drop, using lights with node groups. --Intel MacOS-- #108357
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
7 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#108357
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: macOS-13.4-x86_64-i386-64bit 64 Bits
Graphics card: Metal API AMD Radeon Pro 5700 XT 1.2
Blender Version
Broken: version: 4.0.0 Alpha, branch: main, commit date: 2023-05-26 22:53, hash:
082766bfa420Worked: (newest version of Blender that worked as expected)
Short description of error
See screenrecording video!
When switching to a light with nodegroups in Cycles rendered 3DView, performance drops a big time. (~50%).
Exact steps for others to reproduce the error
I'm not sure what you really expect here. That light is very expensive. It is made up of 12 4d voronoi textures, dozens of math operations, and various other expensive nodes.
Hi, thanks for the report. Did not notice any performance drop with light nodes in your file (checked in 4.0).
Does result remain same with CPU and Metal rendering?
Any improvements in performance without
experimentalfeature set?Did hardware or memory utilization increase during the performance drop?
Hi @PratikPB2123 ,
no wonder you didn't notice anything when using Windows with NVIDIA !!! (Does it say Windows or Intel Mac in the title ?)
You did that now the third time to me. Even after I told you the last two times...
You tell me that there is nothing, by ignoring the working OS I mentioned.
That Windows has more support is clear.....
So do me a favour and check it on the mentioned Intel MacOS and 4.0 Blender Version stated above.
@rboxman I did expect the same performance as with 3.x versions. Because the soo expensive nodes did work fine before 4.0a. Did you double check with other MacOS blender versions to compare, or did you just guess that the node are heavy.
I use the ligts for a year now without any issues, until 4.0a that I beta test like any other alpha/beta. And when I do find a bug or odd behaviour by testing always with the same conditions, I come here.
Both your lack of will to test with the right mentioned OS and blender versions just cost much time and is frustrating telling you this over and over.
PLUS it does not solve anything. Not effective at all !
Nope, tested with 3.3.7 LTS and got the slowdown too. The file you provided isn't even operable on older versions (uses nodes that don't exist and crashes due to the mesh changes in 4.0).
What version works for you -- you were supposed to fill that out when filing the bug. I put in the same effort as the bug filer.
How do you test it on 3.3.7 LTS when it's not working when opening 4.0 files!?
My version 3.3.1 crashes too, when opening a 4.0 file.
I don't have the 3.x blank file version of the performance.blend with this light.
All of them already have been opened/saved via 4.0 and the startup.blend was converted automatically.
So I can't provide you with a 3.x file.
I'm ~8 hours a day working with blender, having a manipulated startup.blend like most people do, to have a constant testing. And if something is different, it will be reported.
Also there are no 4.0 only nodes used in the file.
It was generated with 3.1 and opened with 4.0 and saved.
There have been no node changes at all.
That's all I can give you.
What OS system did you use to test with 3.3.7 LTS?
I simply did File->Append for your light and set up my own scene with it shining on a plane. On Windows a CPU render with the expensive light completed in 50 seconds. While a simple light using just an Emission node was 1.5 seconds.
As for the nodes that didn't exist, I just bypassed them in the shader.
My file attached.
Still leaves us with testing on Windows from you and Pratik Borhade!
Maybe it's a better idea to ask a blender developer for MacOS here with this!!
Hi, as far as I can see you've only mentioned about your hardware & OS. (no traces I found about "working OS/hardware" in report description)
I don't have a system with MacOS.
@brecht , can you check?
@Nurb2Kea please test the 3.3 file in both Blender 3.3 and 4.0, and report the render time. You have to first confirm that there is actually a performance regression with the same file, as part of making a bug report. Just going off memory is not enough, there are many factors that can impact this and it's easy to miss something, I have done so many times.
By itself what is reported in the bug report description is not a bug, a light with expensive shader nodes like this is expected to give a drop in performance.
@brecht I will do so later today.
I'm not going off memory.
This was the file I tested it with since 3.1, and it was converted to 4.0 + no backup of this particular file.
@PratikPB2123 That's why I told you the third time now.
If you don't have Intel MacOS to test...let it someone do with MacOS.
Otherwise it's at least a waste of your and my time.
Your comment:
"Hi, as far as I can see you've only mentioned about your hardware & OS. (no traces I found about "working OS/hardware" in report description) ?
What did I miss incl. the bugreport title ???
see image
@rboxman
If I look side by side at the nodes, I ask myself why you only replaced the one mix node in the caustics?
I changed all three nodes to the proper mix node and removed the red undefined nodes you left behind. see file.
Here the side by side test as video!
@brecht Hi, here the test video showing the difference.
Tested on a Mac M1. I can notice a difference in performance, but it's not surprising as the lamp material is complex.
It's also does not seem a regression:
Blender 3.3 - Time: 00:27.25
Blender 4.0 - Time: 00:26.67
So I can't confirm a bug here.
Yepp, I expected this with M1.
On a big Intel MacOS Mac 64GB + 16GB AMD it is significant!
My system is pretty much same, just with i9 CPU, and can't confirm regression with CPU/GPU rendering.
OS is 13.2.1 so may re-check after update
Was a bit confused and realized this is about viewport performance, still wouldn't say I see any regression here.
Hi,
did you test light-3.3lts-compat_01.blend from two post up or any of the blend files?
And yes, I build / compile every night at 2-3 am the latest INTEL Macos blender 4.0a.
So it's updated.
You can see it in the video on the top.
(I keep track of any report I made since the last two years. If the issue still exists in the updated / fixed version + daily check of my reports!)
I have tested with
light-3.3lts-compat_01.blendfile. In 3.3 and 4.0 I framed the object, switched to rendered view and the performance was pretty much identical. I could have measured how much time it takes to do 64 samples, but from video you posted it seemed to me you have issue with "update rate", is that correct?Since you build from sources, did you check if this issue happens with builds frm buildbot?
See video. Latest build downloaded.
Exact same behaviour as my build/compiled version before.
See at the end when clicking the About Blender.
Even there it takes some split second until blender let me select and click it.
As usual I look very close that it is not my mistake.
As you could see in the compare video and this one here, it has nothing to do with my setup.
Also the nodes aren't that crazy. We all have seen heavier shader or light node trees that do not cause such a performance drop.
As usual I would say it's again a Intel MacOS problem with a high end basic setup iMac 5K (no wild exotic hardware but apple tested setup)
So here is a second side by side comparison with yesterdays and tonights build.
And the jittering 3dviewport got worse!
As little side question:
When I downloaded blender from blender.org to test this issue here, I placed the blender app on the desktop for a quick test.
So when I start blender from the desktop, a folder 'Shaders' will be created on the desktop with all shader files (see txt file).
Wouldn't it be better to place it here (see image): /Users/USERNAME/Library/Application\ Support/Blender/4.0
I mean, I have my regular blender versions in a folder 'Blender' under the 'Applications' folder & the compiled builds blender-git folder.
But the usual Mac user installs the blender app in the Applications folder and the 'Shader' folder gets generated in the applications folder as well!
I'm not sure it belogs there !? Or am I wrong?
Anyways, just for info! Has nothing to do with the reported issue here, but came up while testing this issue.
I also dump daily builds on desktop on Mac and at no time there was "Shader" folder created on my machine.
You tried it with blender 4.0?
I mean I have the same in the git folder. Right next to the blender app, there is the shading folder.
Sure, admittedly, I don't download as much builds on Mac, but here fresh Blender build is running and there is no such folder:
Perhaps this is created by some add-on?
I have the blender app direct on the desktop or in the git folder.
Here is a zip containing the shader folder from the Blender-git folder.
Inside you can find :
/* SPDX-FileCopyrightText: 2023 Blender Foundation
*
and no hint to an addon!
Maybe this video is more helpful !?
These files seem to be generated at compile time and I assume these are compiled in to Blender binary executable. I am not sure if it is even possible for these to be dumped to disk... This is quite strange, but I have no idea what could be happening in this case.
But the curious part is that it happened with the downloaded version too. (9 comments above, if you remember)
MacOS is up to date as well as brew and Xcode 14.1.
The latest version of Xcode 14.3.1 isn't working yet with building blender. Brecht meant I shouldn't try the latest build if it's only 1-2 days old, what I did.
I remember... I guess there is storage for actually compiled shaders managed by OS, so there may be some environment variable for that, but I don't think this is controled by Blender, and the folder is just shader code, not compiled version... As I said, I have no idea why this happens.
I have no insight who is trusted the most with this Shaders, so maybe we should ask Brech and Sergey.
Because when you say that this shader folder has to be inside the blender app (package contense) and compiled,
THAT'S maybe the cause of the 3dviewport behaviour you all don't have.
And since it is doing it with the downloaded versions too, they maybe have an idea what's causing it from the OS side.
I know a lot of maybe's, but I guess we're getting there.
Could you please ask Brech and/or Sergey, because I think you can better explain this to them!?
EDIT: I tested blender 3.1.2, 3.2, 3.3.1, 3.4.1, 3.5, 3.6a, 3.6b &. 4.0.
The Shader folder ONLY gets build when starting up blender from Blender version 3.6alpha to 4.0
Latest build log 10/june 2am.
Tested with vanilla blender 4.0 and Shader Folder turns up. So no third party addons involved. see images.
Another try to fix it:
brew update && brew upgrade (Already up-to-date)
I updated to latest Xcode 14.3.1
I deleted the 'build_darwin' folder in 'blender-git' folder.
make update && make without problems.
see 'build log.txt'
New 'Shaders' folder was build after starting of blender in the blender-git folder.
as you can see the '.cache/cyles/kernels/AMD_Radeon_Pro_5700_XT' folder is not updated (see date) after rendering in the 3dviewport. (I also tried deleting it but it will NOT be rebuild) BUT the uncompiled Shaders in the 'Shaders' folder will !?
So I'm at the end of my Latin. I have no clue why the '.cache/cyles/kernels/AMD...' forlder isn't used/updated anymore,
BUT the 'Shaders' folder, only me getting, when starting blender.
@brecht told me some months ago, to delete the '.cache/cyles/' folder, after having issues. That fixed the issue and the '.cache/cyles/' folder was rebuid each time as expected.
Since then nothing changed (not in brew, xcode) except the blender versions.
And as I stated, this 'Shaders' folder only get build when using 3.6 a/b and 4.0
(I tested all vanilla blender 3.1.2, 3.2, 3.3.1, 3.4.1, 3.5, 3.6a, 3.6b &. 4.0 )
Perhaps @Michael-Parkin-White-Apple could check and provide some insights.
This is poping up quite a lot since blender 4.0 lately, when just opening blender, checking something and quitting blender.
Nothing done, no scene nothing rendered, just checking some settings in the menus and then leaving blender.
There's quite a lot going on in this report.
Regarding the "Shaders" folder:
Regarding the crash on exit, this is something I am looking into relating to the Metal viewport, and has a separate report (Crash on exit with Metal backend #108792)
Regarding the mentioned performance issues, I can't personally comment on this, as it is unclear if it's a specific regression or just highlighting something which is unexpectedly slow. However @Michael-Jones would be the correct person to look into this, if it is indeed caused by Metal Cycles.
@Michael-Parkin-White-Apple
Hi,
by 'debugg not necessary and can be removed', means someone of the dev's have to disable it for the public / main intel macos blender builds. And not the settings in blender !?
Also it should be updated for compiling/building and the download version on blender.org, because it happens with compiled/build versions of the main branch and the online downloaded versions.
About the crash we had this some time ago, but I can't find it again in all the reports. Not the best info, but at least we know it as a known issue.
For the cache, as shown in above comments, when I delete the '.cache/cyles/kernels/' folder, it will not rebuild the folder with the AMD kernals, or is this dependent on the debugging erroneously enabled in another PR !?
When @brecht told me to delete the '.cache/cyles/' folder, it was rebuild with each new daily download/build version or rendering in the viewport. (or at least some of the kernels got updated, ech time they got changed)
So where are those Cycle Kernels saved now if not in the '.cache/cyles/kernels/' folder?
For the performance I'll wait for @Michael-Jones .
Performance for AMD GPU rendering on Metal is low priority currently. The AMD driver here is being maintained just to the level of fixing serious regressions and bugs, so this is unlikely to get attention soon, and also on our side as Blender developers we don't have the time to try to find workarounds for such issues.
Any other issues in this bug report that are not what the original report are about should be reported separately.