It’s true, early versions of the 4.0 alpha were faster than 3.6, somewhere along the line it started to get slower, my test PR112152 was very fast for this version, and it started to get slower towards the later versions
1 Like
Brian said they didn’t see slow downs on their device in testing. They didn’t list which device they were using, but I suspect it was a RX 7000 series GPU because I can’t reproduce a slow down on my RX 7800XT. So it may be slower on RX 6000 series, but not RX 7000 series.
As for what changed between Blender 3.6 and 4.0 that could cause this slow down. Well there’s:
- Some bugs with HIPRT have been fixed.
- Different material types have been added and some materials have been adjusted.
- The light rendering code has been changed.
- Maybe others?
None of the changes above stand out as things that can cause slow downs on HIPRT with an RX 6900XT, but not HIP on the RX 6900XT, or HIPRT on a 7800XT. But the changes above could still have an impact.
For example, the fixed HIPRT bugs may change the registers needed for ray tracing. This in combination with the material and light changes may lead to issues with the register filling up faster, meaning less concurrent work on a RX 6000 series GPU compared to the RX 7000 series GPU, which could lead to the issue being present only on the RX 6000 series with HIPRT.
But this is all speculation. It would require a proper investigation from someone more knowledgable than me to figure out what the cause for the slow down is.
3 Likes
The only actually change to HIPRT in 4.0 was this: #114555 - Fix for HIP RT deformation: - blender - Blender Projects
For deformation motion blur. Like @Alaska said above there could be some side effect of other changes to Cycles code causing register pressure. Is there more evidence other than the above example to go on? Quite frankly I’ve seen renders vary by a few seconds in cycles sometimes, so we can’t take that one example as definitive proof. (And the change there wasn’t a lot TBH)
1 Like
Tomshardware did some tests:
The regression isn’t AMD only, it’s also not very strictly a regression, as the 7900 XTX sees a very very minor improvement unlike everything else.
3 Likes
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.
4 Likes
Update of the old post from Aug 22 comparing HIP GPU share (has all the same caveats).
An interesting point is despite HIP increasing in share (ignoring the decline in the last 2 months), Linux users as a percent of OpenCL / HIP GPU tests have dropped from ~16% with OpenCL in 2021 to ~9% with HIP in 2023 despite linux tests remaining steady at around ~10% of all opendata tests. The drop in HIP Linux users is probably due to longstanding bugs and poor support with Rocm on Linux.
So I guess the feedback is:
- Good work supporting Windows, AMD is back to around 2021 levels.
- Bad work loosing almost 1/2 of Linux opendata tests.
6 Likes
Got myself computer to replace HP SFF to get GPU rendering. Got myself Vega 64 GPU, checked before getting such that it is supported in Blender. And now finding out thatit is not working in Blender under Linux. Is this reality, or some wrong combination of software components?
2 Likes
Hmm, looks like even Debian Sid has too old ROCm. But is Vega working even with latest ROCm, so it is worth compiling latest?
1 Like
I want to add couple Linux-specific points that might explain some of that data.
- Features in HIP are not released for Windows and Linux at the same time. It’s Windows first, Linux second, sometimes after really long time. That was the case with first HIP release and now with HIP-RT which still is not supported on Linux even as an experimental feature.
- ROCm stack is huge and a lot of smaller Linux distributions do not have enough manpower to test, validate and update new versions quickly enough. And even with bigger distros this can take a lot of time.
If you combine both delays it could be well over a year between the feature is implemented in Blender and the time you can use it with AMD GPU on Linux.
- GPUs are being dropped from supported list faster than the competition while still having serious bugs. That should speak for itself.
There are other not Linux related reasons like performance/$ and lack of day 1 ROCm support after GPU release that adds salt to the wound.
2 Likes
Is vega 64 supported/working in Linux or not?
According to CMakeLists.txt (One of the files for setting up the Blender build environment), Vega 64 (gfx900) is one of the HIP kernels being compiled for Cycles. And downloading a Blender 4.0.2 build for Linux from the Blender foundation shows that the gfx900 kernel is present in the application.
So the Vega 64 should work with Blender Cycles HIP in Linux. There could be a configuration issue on your end, or there could be some issues with HIP and Vega that can’t easily be fixed (E.G. Vega VII is currently disabled for Cycles due to some issues).
I don’t have the hardware to test Vega 64 compatibility with Blender and Linux, but it could be helpful if you provided some more useful information. For example:
- What Blender version are you using? Make sure this version is from the Blender foundation.
- You say your Vega 64 isn’t working with Blender. In what way is it not working? An error message when you try rendering? Can’t find your GPU in preferences?
- Have you made sure you have all the prerequisites to use HIP in Cycles (Radeon Software 22.10+ or ROCm 5.3+), and what versions of these are you using?
Hopefully with this information, someone else might be able to help you figure out what’s going on.
Thanks for reply! Yeah, I can see that there is stuff for Vega compiled in but GPU rendering fails on hip related errors and elsewhere I have gotten comments ‘unsupported card in linux’ so I wanted to have some confirmation.
I have tried in debian, both v12 and sid, and indeed ROCm version is too low, so definitely config issue here. It looks like there isn’t packaged more recent ROCm available for debian. I might even look for building it myself, but checking out repo, not having build instructions more that to docs, and even building docs fail 
Maybe I have to consider changing distribution: Arch would have more recent ROCm packages and for Ubuntu there is AMD drivers available. If someone would have some comments about options I would be glad to hear them!
Tested Vega 64, results:
- With Arch linux (ROCm 5.7) when trying to open gpu rendering settings for HIP, whole blender or whole computer will freeze (2 different computers)
- With Ubuntu 22.04 and AMD closed drivers in theory GPU rendering works (can render cube), but even with simple projects I had, in both cases will crash with ‘Memory access fault, Reason: Page not present or supervisor privilege’
Unfortunately no solutions however your Arch item has an open arch issue which interestingly links an open issue where the memory access fault is mentioned briefly.
I think Blender is stretching the truth when they say HIP is supported on Windows and Linux but you know, don’t bite the hand that feeds you.
Yeah, for me it looks like that I need to get some nvidia card if I want to have gpu rendering. That crash with closed amd drivers and thing that Vega has been long disabled gives feeling these problems aren’t going to get fixed. Time to sell my Vega 
1 Like
Get a NVIDIA GPU if you prioritize reliability and stability in Cycles. (There can be issues when rendering on NVIDIA GPUs, but they typically appear less often than other vendors).
If you want to go with an AMD GPU, then you’ll get the best experience by getting a RX 6000 or newer GPU and run it on Windows. Older GPUs like the RX 5000 and Vega series are not properly supported (Cycles supports them, but AMD seems to give them low priority when fixing issues in HIP/ROCm). Linux support also appears to be a lower priority for AMD at the moment when compared to Windows.
If you want to go with a Intel GPU, your only true option is the Intel Arc AXXX or newer (when they come out) discrete GPUs. Windows and Linux support for Intel GPUs in Cycles appears to be good, but there have been some quirks during it’s development (similar to AMD HIP and Apples Metal having quirks during development).
If you wish to switch to a Mac, make sure you get a “Apple Silicon” Mac, preferably M2 or newer.
Non-Apple Silicon Macs are low priority for Apple, and so they regularly experience bugs and performance regressions that Apple doesn’t fix.
2 Likes
This topic is about AMD HIP Feedback. Please stay on topic and discuss GPU purchases etc in private.
3 Likes
Returning to this, things aren’t that bad. With Blender 3.6 rendering with Linux Vega works in Ubuntu + closed drivers!
Edit: for some material, 20th frame in my animation and got crash. Another animation, crash immediately
More testing, it works also in Blender 4, and the crashing happens when there is material with emission.