I’ve noticed that blender 4.0’s hiprt has gotten a little slower than hip.
I just uninstalled 3.6 and had no choice but to download another 3.6 portable package for comparison purposes
I just uninstalled 3.6 and had no choice but to download another 3.6 portable package for comparison purposes
AMD HIP:
- Linux RDNA2 crash bug was confirmed by AMD team and is being investigated.
- HIP-RT support is still being worked on. Code should be submitted for review even if driver is not out yet.’
Dear AMD developers. I would like to promote the use of Radeons and HIP with my works. I recently purchased my first graphics card from you guys. I see that since version 3.0 or 3.1 there is no major progress in improving the stability of Veiwport in Blender on Radeon cards. We have version 4.0 and the problem continues. Is there any work being done on this? Is there any chance of some updatedla Hip RT for Linux? Although I would definitely prefer a regular HIP that works stably. I guess AMD has completely lost interest in consumer GPUs, and their professional use in Linux. I think it would be fair if they at least admitted it officially. at least I wouldn’t get my hopes up that the situation will get better. Is Rocm and HIP actually officially supported on Linux?
3 Likes
I suspect amd didn’t test the code before submitting it, on windows platform, blender 4.0 has regressed in rendering speed when using hiprt, not even as fast as with hip.Of course it’s also possible that code changes on both sides could have caused the performance degradation,Maybe amd’s tests are ok.
We do test, and on our side we don’t see the same performance difference you do. In that HIPRT being slower than HIP. On this classroom scene though they are similar in render times so it might be a “margin of error” thing.
2 Likes
But HIPRT in Blender 4.0 is slower than HIPRT in Blender 3.6
2 Likes
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.