There are two things going on here:
-
A user earlier in this thread reported that HIP-RT in 4.0 was slower than HIP in 4.0. When looking at testing in 3.6, they observe the opposite, so this seemed concerning.
-
What Toms hardware (and some other people) have observed. GPU rendering in Cycles seems to be slower in 4.0 compared to 3.6.
Brecht has made a comment on the general slow down (the Toms hardware thing).
- Render times typically should not be directly compared between major Blender/Cycles versions.
- A 10% slow down would not be considered an issue for a update like 4.0
Let’s take a look at this.
Why you should not compare different Blender/Cycles versions:
For 4.0, the main reason you shouldn’t compare it’s performance with previous versions of Blender is because of the shader and light changes. Changes to the shaders and lights will make them render differently. This makes comparisons of performance unfair because you’re not comparing the same render between versions. For example:
Many of the materials that are used in the scene above were changed in 4.0. And now they render differently. Versioning is used to try and make materials look similar to how they did in older versions of Blender (depending on how large the change was, the versioning may not be able to do a good job at this). But even with the versioning, the scene is still being rendered differently which means the computations are different, and performance is likely to be different.
But let’s say a material looks similar between 3.6 and 4.0, maybe that material renders using a completely new method and just looks similar, and this is impacting performance.
Apart from obvious changes, there are less obvious changes like bug fixes that cause no change in rendering under normal circumstances, but has a negative impact on performance due to more computations being done. Or subtle changes in brightness between versions causing russian roulette sampling to stop earlier or later, resulting in more or less rays cast. Or subtle changes in noise changing the memory access patterns, thus changing cache usage, cache misses, and memory bandwidth requirements. Things like that.
And then there’s the hidden stuff. Adding complexity to the Cycles code, even if it isn’t being used by the end user, can negative impact performance. For example, Blender 4.0 added a new hair material type. All scenes made in 3.6 will NOT be using that hair type, but it’s existence in the code causes performance slow downs in these scenes on many types of hardware (E.G. 2% slow down on Windows Nvidia GPUs, a 200% slow down on AMD GPUs with Metal (This seems to be a issue with the Metal compiler and a work around has been implemented to help out)).
Why a 10% slow down for 4.0 isn’t really considered an issue:
Hopefully the information above explains it. A lot changed in 4.0, materials, light rendering, added complexity from other features, etc. Very few “typical” scenes will match 3.6 in terms of how they render and even if they do, other factors are still going to impact performance.
As for how much each device is impacted by performance, is dependent on the device itself and it’s hardware design, the compiler, and if it’s a GPU, the drivers.
I should note, an investigation has be done to try and figure out where the 4.0 performance slow downs came from, just to make sure performance slow downs don’t come easy to fix things. I’m not sure what the chosen course of action is with regard to the information discovered.
The above comment explains why the general slow down isn’t much of a concern. But we still don’t have the exact answer to why HIP-RT is slower than HIP for the other user in 4.0.