Run the command as is: sudo usermod -a -G render,video $LOGNAME
The command will automatically interpret $LOGNAME as your user name.
1 Like
I wanted to expand on the results from this testing.
In many of the demo files provided by the Blender foundation, the intersection performance boost offered by HIP-RT was surprisingly low. In some scenes, the boost to intersection performance wasn’t enough to offset other factors (BVH construction time, artifacts), resulting in HIP-RT not being worth it in some files.
But I just wanted to add that in the right scenes, HIP-RT can be highly beneficial. I’m working on a scene right now, and the HIP-RT has no noticeable artifacts, and offers a intersection performance boost of 150%, compared to the ~60% performance boost I saw in the Blender demo files (This 60% performance boost is different from the 30% I mentioned in the post I’m replying too, this is because I swapped to a RX 7800XT which has different performance characteristics than the RX 7600XT used in the older tests).
Overall render times (Scene initialization and rendering) is 50% faster using HIP-RT in this scene. The overall performance boost is only 50%, and not 150%, because the 150% performance boost is only for intersections, which only makes up a portion of the rendering. And with HIP-RT, the scene initialization time is longer due to the HIP-RT BVH taking longer to construct.
HIP-RT performance is still quite a bit behind NVIDIA. Because in the same scene my NVIDIA RTX 4090 observes a 1370% performance uplift in intersection performance when using OptiX vs CUDA (compared to the ~200% seen in the demo scenes). But it’s still good to see that the performance benefits that HIP-RT offers scales up to a meaningful amount in some scenes.
3 Likes
Unfortunately ROCm 5.7 seems to require the amdgpu dkms module.
On openSUSE Leap 15.5, without having the dkms module installed, Blender freezes when switching to HIP.
Using the default kernel of Leap 15.5
amdgpu-install --usecase=rocm,graphics,dkms
did the job.
I tried to install the dkms module on the backported kernel 6.7.1, but it didn’t compile.
I guess that might be the problem with ROCm 5.7 on Tumbleweed.
2 Likes
so that is probably it, older ROCm didn´t require ROCm-dkms and the newer one can´t install them because of libpython3.6m kernel dependency. I hope this get fixed by AMD or Blender team, Tumbleweed is such a great distro for working and productivity.
1 Like
@Alaska if you could provide more information, it would be help us at AMD to track down possible deficiency areas.
1 - What are the scenes where the intersection boost is not enough to counter BVH construction time?
2 - What are the scenes that show artifact with HIP-RT?
3 - Do you see patterns/common properties in scenes where there is a decent performance boost?
Also, there are two other BVH construction methods (balanced and fast) that would run much faster than the high quality BVH method. My experience is that the high quality BVH makes up for the construction time with more accurate intersection.
When testing with the RX 7600XT last year, there were a few scenes from the Blender demos list where the intersection boost wasn’t enough to offset the BVH construction time. However that has mostly/entirely disappeared when switching to the RX 7800XT, probably due to the intersection boost on the RX 7800XT being higher.
A user reported that the Classroom scene from the demos page was overall slower with HIP-RT. I assume this is because the HIP-RT performance boost wasn’t enough to offset the BVH construction. I and Brian Savery could not reproduce this behavior.
There’s also the factor of the render time. If a scene takes 30 seconds to construct a BVH , and 2 seconds to render on HIP. But takes 32 seconds to construct a BVH and 1 second to render on HIP-RT, then using HIP-RT isn’t worth it. But if the user increases the sample count, resolution, and/or ray bounces, then the render time will increase, but the BVH construction time will stay the same. And at a certain point HIP-RT will become worth it.
I have created a bug report here for one of them: #117527 - HIP-RT transparent rendering artifacts - blender - Blender Projects
The secret deer scene renders different on HIP-RT : #117567 - HIP-RT renders Secret Deer scene differently from other BVHs - blender - Blender Projects
The plants in the lone monk scene from here renders differently with HIP-RT. As far as I can tell, some of it is the same issue as the Secret Deer issue linked above. Some of it is due to differences in how each backend handles co-planar overlapping faces (This is also an issue with other GPU vendors and is not HIP-RT specific)
There is a relativity minor issue on the Monster Under The Bed scene from here. The way the monster “flesh” overlaps with one of the eyes is different between HIP-RT and all the other BVH options (Embree, BVH2, OptiX). It’s a relatively minor difference, but it’s enough to cause a “flicker” in a animation rendered across multiple GPU vendors (E.G. HIP-RT and OptiX render alternate frames, and due to subtle differences in how they render this overlapping section, this will appear as a flicking piece of geometry around the eye).
In the scene where I saw the 150% intersection performance boost, the main factor appears to be having lots of fine geometry (I had a lot of plants and pebbles and twigs scattered on the ground to fill out an environment).
1 Like
I found such a post on another forum. It looks like there is some breakthrough in the topic of blender viewport stability for cycles running on Radeon graphics cards. Is there anyone who can verify this and explain it to someone who is not technically proficient? This was may best new year gift!
https://patchwork.freedesktop.org/patch/575997/#comment_1052187
It seems that the new release of Blender 4.1 has improved the situation with driver support for HIP on Linux. I just hope that this is not a mere coincidence. and the next time the program is set on fire, it will blow up the whole system again. If this is corrected then I guess it’s time to upgrade the graphics card to some RDNA3.
Here is my test of the GPU viewport in Blender 4.1 beta.
3 Likes
Unfortunately. I was too happy too quickly. The program still runs unstable with the Cycles engine when rendering GPU with Radeon.
I’ve created a pull request to re-enable graphics interop on the HIP backend. This changes how the rendered image gets from Cycles to the Blender user interface.
I was wondering if some people could test this. I’m primarily interested in Linux users and users with older hardware (Vega or RX 5000 series), but anyone is free to test.
The Blender build with graphics interop re-enabled can be found here: Blender Builds - blender.org (The Windows build failed. So Windows is not available for testing at the moment)
Note: To properly test this, you must be using your AMD HIP compatible GPU for rendering in Cycles, and that same GPU should be rendering the Blender User Interface.
What are you testing?
You’re testing to see if re-enabling graphics interop breaks anything or has any negative side effects. Comparisons should be made against Blender 4.1 available here.
Examples of issues are:
- Anything involving Cycles renders (viewport render, final render, Cycles material previews) is distorted compared against standard Blender 4.1. This could be colour/brightness shifts, line/block/dot artifacts and more.
- Any other weird things. Examples include: noticeable increases in stuttering while using Cycles, new crashes, new system hangs, graphics driver hangs, etc.
- If you run Blender from the command line with something like
/path/to/blender --debug-cycles --verbose 4and find any errors likeError registering OpenGL bufferor errors mentioninginteropwhen rendering with Cycles, this is also a issue.
After testing, report back with your OS, GPU, Driver/ROCm version, and whether or not you experienced issues.
If you have issues, report the same information as above, then try updating your GPU driver/ROCm version if you aren’t on the latest already and retest and report the results from that test. Knowing that one driver version is broken and another isn’t is useful information to me and the Blender foundation.
Note: It is unlikely that you will encounter a issue, but it’s still nice to check.
2 Likes
Using the blender build to render the standard cube with cycles in one viewport leads to a crash. Since I can’t upload attachements I’ll provide you the content of “blender.crash.txt”:
# Blender 4.1.0, Commit date: 2024-02-21 12:20, Hash 3656293f134b
bpy.context.space_data.context = 'RENDER' # Property
bpy.context.scene.render.engine = 'CYCLES' # Property
bpy.context.scene.cycles.device = 'GPU' # Property
# backtrace
./blender() [0xefc5a0]
./blender() [0x82a84c]
/lib64/libpthread.so.0(+0x16910) [0x7f401e9d6910]
# Python backtrace
and some few log lines of the start of blender:
~/Programme/blender-4.1.0-beta+main-PR118562.3656293f134b-linux.x86_64-release> ./blender --debug-cycles --verbose 4
Read prefs: "/home/tom/.config/blender/4.1/config/userpref.blend"
I0221 22:40:31.233851 28863 device.cpp:39] HIPEW initialization succeeded
I0221 22:40:31.233877 28863 device.cpp:41] Found precompiled kernels
I0221 22:40:31.258062 28863 device.cpp:205] Device has compute preemption or is not used for display.
I0221 22:40:31.258080 28863 device.cpp:209] Added device "AMD Radeon RX 6600" with id "HIP_AMD Radeon RX 6600_0000:08:00".
I0221 22:40:41.430613 28863 device.cpp:541] Mapped host memory limit set to 46,107,590,656 bytes. (42.94G)
I0221 22:40:41.430836 28863 device_impl.cpp:63] Using AVX2 CPU kernels.
I0221 22:40:41.583241 28863 device.4.1.0 Beta, branch: blender-v4.1-release, commit date: 2024-02-20 18:18, hash: `a3ffb51da6c5`
Worked: (newest version of Blender that worked as expected)cpp:51] CUEW initialization failed: Error opening the library
I0221 22:40:41.583482 28863 sync.cpp:296] Total time spent synchronizing data: 0.00036788
and some few log lines of right before the crash:
I0221 22:40:41.633098 29422 path_trace.cpp:409] Rendered 4 samples in 0.00682306 seconds (0.00170577 seconds per sample), occupancy: 0.0541475
I0221 22:40:41.633111 29422 render_scheduler.cpp:510] Measured path tracing occupancy: 0.0541475
I0221 22:40:41.633121 29422 render_scheduler.cpp:503] Average path tracing time: 0.109631 seconds.
I0221 22:40:41.633134 29422 path_trace.cpp:654] Perform copy to GPUDisplay work.
Writing: /tmp/blender.crash.txt
Speicherzugriffsfehler (Speicherabzug geschrieben)
Some Information regarding my computer:
System Information
Operating system: Linux-5.14.21-150500.55.49-default-x86_64-with-glibc2.31 64 Bits, X11 UI
Graphics card: AMD Radeon RX 6600 (navi23, LLVM 17.0.4, DRM 3.56, 5.14.21-150500.55.49-default) AMD 4.6 (Core Profile) Mesa 23.3.0-devel
Blender Version
Broken: version: 4.1.0 Beta, branch: PR118562, commit date: 2024-02-21 12:20, hash: 3656293f134b
I’m using opensuse 15.5, ROCm 6.0.2 : amdgpu-install --usecase=rocm,graphics,dkms
Rendering the standard cube with cycles in blender 4.1.0 Beta, branch: blender-v4.1-release, commit date: 2024-02-20 18:18, hash: a3ffb51da6c5 doesn’t crash. This blender version does crash if e.g I have two viewports in one blender instance, both rendering in cycles at the same time (both counting the samples), no problem if one viewport has finished its rendering.
1 Like
Thank you for the test. It looks like we may not be able to enable graphics interop just yet if you’re experiencing crashes from this feature.
1 Like
Hello everyone! Is there any optimistic news regarding the improvement of HIP rendering stability in the new Blender? I didn’t find any information in the summary of the upcoming version 4.1. Please. Please tell that you know something? @bsavery Is it a good time to buy cards with RDNA3 if I want to stay with Linux? This thread has been going on since 15.november 2021. it can be suspected that the problem appeared earlier. I assume that if I actually worked on it, the problem would be rather solved. on my system there is a slight improvement. but further when I change, for example, the material on an object, or delete something the system just shuts down at the least expected moments.
(@bsavery is no longer at AMD)
As far as we know stability issues are in the driver and firmware, and they can’t be solved in Blender. So no particular Blender release is going to fix them. When we know anything concrete we’ll share it.
The fundamental issue I think is that mixed compute and graphics just hasn’t been supported well by AMD drivers. Most applications will use only one or the other, so this doesn’t get tested as much.
2 Likes
Brecht Van Lommel Thank’s for info. From what you say it seems that no one is interested in it. Pity. Maybe the matter will be improved by the implementation of CUDA for AMD. I am curious about this development. Although it is quite frustrating. Blender CUDA on AMD GPUs [ZLUDA by Vosen] - Latest News - Blender Artists Community
2 Likes
@Mikolaj_Neronowicz I would like to add. With ROCm 6.0.2, on Ubuntu, with Linux 6.7.X kernels, with a RX 7800XT with Blender 4.2 has increase stability for me compared to earlier this year/last year. I can now run a preview render and a final render at the same time without it crashing. However I haven’t done extensive testing on this or figured out which change fixed it. So it’s possible these types of issues will continue to appear in some scenes (E.G. I was testing really simple scenes, I should test a more medium sized project to see if I can reproduce these results).
As for ZLUDA. It’s a tool that runs CUDA code on AMD GPUs through ROCm/HIP. So many issues that come from ROCm/HIP will likely still exist when running ZLUDA.
There is also the issue that the ZLUDA project is seeing reduced development due reduced funding, specifically AMD no longer paying for the projects development.
4 Likes
Thank you for such a detailed explanation. It may not be the most optimistic information, but it’s nice that there is still someone following the topic. I appreciate the commitment. I would like to help somehow, but I’m afraid I don’t know how. I don’t know how to send this report and my technical knowledge is low.
I’m looking for some help and i don’t have extensive technical knowledge and i new to linux. I’m using 22.04.4 LTS ubuntu & blender 4.0.2. I wanted to use gpu to render in blender thus i found out about HIP/ROcm etc and followed the guide from “Ubuntu native installation — ROCm installation (Linux)” , i have finished all the steps and blender seems to detect the gpu but when i try to go into render mode it gets stuck on “updating shader” , same when i hit f12 to render but doesn’t freezes , it freezes when i try to change to solid mode.
Also i want to know if its possible to get this working with less storage ,Rocm is taking a lot of space(around 23gb), my only purpose for it is to render.
1 Like
Just an update. Rendered viewport + final render still freezes in more complex scenes.
1 Like
I wanted to ask if you are the person responsible for the implementation of HIP in Blender? Or in general for the development of ROCm technology in Linux or other platforms? If not, is there any person who could give the company’s official position on the topic of Cycles stability fixes using AMD graphics cards? Is there any way to motivate those responsible to take this step forward? Some form of heppening? Something to draw the company’s attention to this problem? I for one am really keeping my fingers firmly crossed for AMD. But they don’t give a chance to take them seriously in this aspect. Especially with all the marketing campaign going towards professional applications and AI.