Cycles 4.0 about 25% slower than 3.6 #114351
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
8 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#114351
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: Windows
Graphics card: RTX 4060 ti
Blender Version
Broken: (example: 2.80,
edbf15d3c0, master, 2018-11-28, as found on the splash screen) 4.0 vs 3.6Worked: (newest version of Blender that worked as expected)
Short description of error
4.0 cycles slower than 3.6 on same scenes.
Exact steps for others to reproduce the error
Based on the default startup or an attached .blend file (as simple as possible).
Render any scene in 3.6 then 4.0 with no changes. Considerably slower (about 25%).
I've tested this a few times on a few different scenes with the same results. Changing no settings, 4.0 is considerably slower. I tried to send a scene but it's too large. Not sure if anyone else has noticed this? I'm rendering on a RTX 4060 ti.
I'll try to make a smaller scene and send it.
Cant repro in simple tests.
If you could provide a .blend where this happens, it would certainly help tracking the issue down.
I've sent one by wetransfer https://we.tl/t-K0K0TGhNym
Does that work for you? If I start rendering this at frame 360, after the first frame when everything is in VRAM, on Blender 3.6 it renders in 36 sec. If I do the same on 4.0 it renders in 48 sec.
I've tried on a couple other completely unrelated projects and get similar results. Thanks for looking into it! Cheers.
I can confirm a slow down with a RTX 4090. However the slow down is rouhgly 9% for me. Note: I turned off adaptive sampling.
A quick look points at shading being slower in 4.0 and making up the most of this performance decrease. This is probably expected since quite a bit has changed in the shading section (large changes to the Principled BSDF, which is used quite a bit in this scene, large changes to light rendering, the adding of new materials (which can effect code generation quality), etc).
I'll leave the decision up to @lichtwerk if they want the Cycles developers to look at this report or if it should be closed.
34b4487844if copies of evaluated data are used - there could be a bit more overhead from this ^
I can confirm it too. In my case (WIN10/GTX1660/CUDA) the slow down is roughly 11%.
hi,
I also checked in Blender Open Data, and it seems that 4.0 has significant slowness than 3.6. see the link below.
it means the general performance benchmark of Blender shows it as well.
The big drop is also on the RTX 4090.
https://opendata.blender.org/benchmarks/query/?device_name=NVIDIA%20GeForce%20RTX%204090&device_name=NVIDIA%20GeForce%20RTX%204080&blender_version=3.6.0&blender_version=4.0.0&blender_version=3.5.0&group_by=device_name&group_by=blender_version
Should this be marked as confirmed by now? It's a pretty significant slowdown and it would be nice to keep it on the radar.
Looks like Tom's Hardware confirmed as well. Interestingly, it seems to mostly effect Nvidia GPU's.
https://www.tomshardware.com/news/blender-4-released-and-tested
Looks like this was closed by accident
@Len-Krenzler : Sorry it took a bit for me to check on this. I want to do this now (to find out the commit(s) that are actually responsible for the slowdowns, but the wetransfer links has expired, could you put it up again?
For the time being, I'll run a test with a couple of demo files from https://www.blender.org/download/demo-files/
Scene : Classroom from https://www.blender.org/download/demo-files/
Operating system: Linux-6.5.12-200.fc38.x86_64-x86_64-with-glibc2.37 64 Bits, X11 UI
Graphics card: NVIDIA GeForce RTX 3080 Laptop GPU/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 535.129.03
Thanks for looking into this! Here's a new link:
https://we.tl/t-8WDqX96Jyt
On this scene with a RTX 4060ti it's a 25% slowdown inside the building.
Looks like Toms Hardware was seeing about 12% on their benchmarks.
Sorry I closed the thread by accident. Thanks for restarting!
Brecht mentioned that a 10% slow down (what I and John Doe observed while testing) wasn't much of a concern, and this report should probably be closed. But the 25% slow down observed by @Len-Krenzler was concerning enough to keep the report open for further investigation.
The 25% slowdown could come from various places. But part of it likely the code and the changes to it (since other people can reproduce slow downs, but not to the same extreme). So took a look when changes were made to the code that caused slow downs, and this is what I have so far:
Based on the chart (and the raw numbers that made up the chart) I can identify two points of slowdown.
Between 2023-06-08 (Commit:
38833a20a6a) and 2023-06-15 (Commit:45b9542e6c8), something changed resulting in a ~2% slowdown. Testing these versions, there are no differences in the rendering of the scene, which suggests this is before most/all of the Principled BSDF v2 changes. I will investigate this further and report back with further information.After that, performance tends to decrease as time goes on. But there's a bit of noise in the data that makes it hard to pick out if a performance decrease comes from a single point in time, or just that performance slowly decreases as various things change over weeks.
Note: You may wonder why the worst performance slow down I have here is 5.X% while I originally reported ~9%. This is because I am building Blender myself for this test, and I use a different CUDA and OptiX version which appears to be slightly faster than the one used by the Blender foundation.
@Alaska thanks for the tests. The next thing would be to identify the specific commits.
When I do this I look at
git log intern/cycles/kernelsince those are the most likely problem. For example between38833a20a6aand45b9542e6c8, the most likely candidate is144ad4dwith fractal voronoi changes.If you can mention the specific CUDA version you used that would be helpful, if just bumping the versioning on the buildbot provides a speedup that would be nice.
I'm not sure why it would be impacting my system more than most. At first I thought it was the brushed metal material I used a lot on the test scene I sent. However I tried it on other scenes that don't have that or any procedural materials and got the same results.
I adjusted my testing methodolgy (Only measure render time, exclude scene intialization, take 5 averages instead of 3, use command line rendering instead of GUI rendering, etc) and did some further investigation. I now have this graph:
Testing is focused around areas where performance changed substantially. So results away from the "clifs" are mostly interpolated.
From this graph we can identify a few points in time (and commits) that caused rendering slow downs in 4.0. They are:
144ad4d20b0- Nodes: add Fractal Voronoi Noise0b3efc9d8c0- Cleanup: Cycles: removeSHARPdistribution internally (Doesn't really make sense to me. I might of gotten this wrong)6f8011edf76- Cycles: new Principled Hair BSDF variant with elliptical cross-section support (Makes up the largest portion of the slow downs)8e49bc4a05c- Refactor: Make Cycles shadow linking primitives receive ray self primitives (Only about a 0.1% slowdown)Mid September (All three combined make up the 1% slow down bump in mid September):
158dbc1b101- Cycles: Rework Principled BSDF Clearcoatd7aee5a5803- Cycles: Tweak Principled BSDF Subsurface parameters4c229070a95- Cycles: Rework Principled BSDF Emission@Alaska, just a clarification question - so the biggest cumulative performance drop (compare to 3.6.5) on your chart is 9% at the right part of the graph? If so, then it is kinda not fully connected to the title and the original description about 25% slowdown? Or I am just reading chart wrong?
Others don't seem to be getting the same slowdowns I get. Not sure why. I've tested on a couple different machines, one with a RTX 3060 and one with a RTX 4060 ti with similar results. On the test scene I sent, these are the steps I took. Start rendering at about frame 360 (inside the building). Let it render a couple frames so that loading the scene isn't part of the recorded time. I thought it was just that scene but I've tried others with similar results.
> On the test scene I sent
@Len-Krenzler, is it possible to attach it here, on Blender site? It seems all your previous wetransfer links have expired already.
It's too big. Here's another link. https://we.tl/t-JF2tNA9dkV
Thanks! I have give it a try on my RTX 4080 and I have 14.25 seconds with 3.6.5 and 15.4933 seconds with 4.0.1 for final render, so for me it is 8-9% regression in performance between versions. I would say, maybe something trickly happening in your environment with 4.0 - for example, OptiX cache somehow got corrupted. So, I would recommend to run blender from Command Line (cmd.exe) with additional options
--debug-cycles --verbose 4and run both blender version with saving all output to the file (for example with additional argument in the command line> output.txt 2>&1) and then post it here - maybe the problem will be visible in the logs.Thanks for testing! I'll try that. It must be just me because all the others got about the same results as you.
I'm sorry, after a few tries I realized I'm an old has-been hobbyist that has no clue how to do that. It's clearly not an issue for anyone else to this might as well be closed. Cheers.
@Len-Krenzler your self-bashing isn't helpful. What happened? Did your find the cause of 25% performance drop? If so, what was it?
I still plan to look at the ~10% performance drop, and we have gotten enough information to do that. There's a reasonable chance it will help with the 25% performance difference too.
Regardless, no one is obliged to keep testing things, and the feedback we have gotten so far has been helpful.
Sorry @JohnDow, that was just meant as humor (which didn't seem to come across) at my struggle to get a simple command line to work. I'll try again this weekend. However this issue seems to be just on my system for some reason. Others are not seeing it.
@Sirgienko I couldn't figure out how to get it to write a file so I just copied from the command window. I don't know if this is any help.
I did notice that 3.6.7 is showing slower than 3.6.6 for me. For frame 361 with 3.6.6 I was getting 36s, now on 3.6.7 it's 42s and with 4.0 it's 46s. I don't have 3.6.6 installed anymore to test with.
@Len-Krenzler, sorry for delay, I have thought I have added my comment 3 weeks ago, but it looks like something go wrong or I have forget to push a "Comment" button - a comment haven't appear here.
So indeed, the gap in performance in your logs is not that big as reported initially, and from logs perspective all seems good - there is expected Blender kernel/shaders slowdown, which explain this overall slowdown.
Situation about 3.6.7 and 3.6.6 upgrade shouldn't, in theory lead to any performance improvements and degradation, as this two versions are quite close and do not have any performance related changes:
But I have notice, that you seems few extension installed - and they seems to be different in 4.0 and 3.6 versions. In fact, for both versions I see multiple failures in extension initialization, meaning that this extensions won't work. I have verify the names of the failing extensions, and they seems to be not related to a render performance, so their failure are not related to the performance situation, described in this bugreport.
However, I don't have details about the distribution method or update process for Blender extensions. If extensions are distributed separately from Blender releases, it is possible that the previously observed "low" performance with version 4.0 or "high" performance with version 3.6.6 could have been due to a malfunctioning extension. This could have been subsequently resolved with an update to the extension, which might explain why the issue is no longer reproducible.
Hi,
just to be clear, the performance test was done using the Blender Benchmark tool that downloads the version of Blender and runs the test demo files.
The benchmark shows significant differences between the two versions of Blender, 3.6 and 4.0.
No extensions are involved in the benchmark, and the results are not affected by the use of any extensions.
Go to https://opendata.blender.org/benchmarks/query/ and check the results. it is so clear that the difference in benchmarks exists. Not sure if it is by 25%, but it is noticeable for sure.
Indeed, others are seeing roughly 9% to 10% quite consistently. It must have been some specific shaders I'm using or like Nikita pointed out, an extension causing my larger slowdown.
I just tested the latest 4.2 Alpha with the same scene and I'm happy to say great results! On 3.6.6 it was about 36sec / frame, on 4.0 and 4.1 it was 46sec / frame and now with 4.2 it's 32sec / frame for me. A big thanks to whoever fix it and now it's not only fixed but better than ever!
I suppose this could be closed now.
Thanks for testing, that's good news. It must have been something random that fixed it, though unfortunately that means another random change can break it again. But hopefully not.