Cycles AMD HIP device feedback

Feature & Design Feedback
573

I have a RX 7800XT with ROCm 5.7.3 and it’s detected just fine in Blender 4.0.2.

There’s probably some sort of a configuration issue on your end. Some examples I can think of are:

  • If you’re installing ROCm from your package manager, and not AMD, then your package manager maintainer may be doing something weird that means it doesn’t work properly with certain applications.
  • There might of been a error during the installation of ROCm and it’s dependencies that you missed which could be causing issues. (I had this issue on my computer when installing ROCm 5.7.3)
  • Your user might not be in the render and video groups as recommend by AMD. sudo usermod -a -G render,video $LOGNAME then reboot.
  • Maybe there was a issue during the uninstallation/upgrade to newer ROCm versions? For example, maybe you have both ROCm 5.6 and 5.7 installed by accident, and you need to make sure only one of them is included in your PATH?
  • Something else?
1 Like
574

Hi. What version of Blender do you have? Can you run Blender from the command line with --debug-cycles for more info on the command line?

Also if you can check where libamdhip64.so is located?

2 Likes
575

tried with 5.7.3 and Blender 4.0.2 the whole system freezes when I click over HIP in Cycles Render Devices.

Additional steps I’ve tried now:
Downgrade from mesa 24.1 to default tumbleweed drivers
Switched from Wayland to X11

HIP Runtime from: https://repo.radeon.com/ that I’ve used until ROCm 5.6 without any problem.

The only dependency missing was Perl-Encode which I have successfully provided via Perl repo.

That command, should I run as it is or I must switch something to my username?
sudo usermod -a -G render,video $LOGNAME

1 Like
576

thank you for helping, here is the output:
I0122 21:54:21.916563 3192 device.cpp:49] CUEW initialization failed: Error opening the library
I0122 21:54:24.290143 3192 device.cpp:37] HIPEW initialization succeeded
I0122 21:54:24.290189 3192 device.cpp:39] Found precompiled kernels

but then Blender freezes

libamdhip64.so is located in:
/etc/alternatives/rocm/lib

577

Run the command as is: sudo usermod -a -G render,video $LOGNAME
The command will automatically interpret $LOGNAME as your user name.

1 Like
578

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
579

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
580

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
581

@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.

582

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
583

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!

2024-02-06_13-31
2024-02-06_13-311386×870 92.8 KB

https://patchwork.freedesktop.org/patch/575997/#comment_1052187

584

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
585

Unfortunately. I was too happy too quickly. The program still runs unstable with the Cycles engine when rendering GPU with Radeon.

586

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 4 and find any errors like Error registering OpenGL buffer or errors mentioning interop when 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
587

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
588

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
589

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.

590

(@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
591

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
592

@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