Cycles AMD HIP device feedback

Feature & Design Feedback
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
593

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.

594

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
595

Just an update. Rendered viewport + final render still freezes in more complex scenes.

1 Like
596

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.

597

No, I am just person who owns a AMD GPU, and I use it to test AMD GPU specific issues in Blender/Cycles.

As for your other questions, the only thing we as average users can do is make bug reports about the relevant issues to the relevant places. And hopefully the relevant groups fix the issues in a timely manner.

Sadly this doesn’t appear to be working as well as we hope (E.G. Major stability issues on Linux that have persisted for months, if not years), but there’s not much else average users can do.

4 Likes
598

Has anyone tried version 6.1 of ROCm yet? I read on one of the forums that finally the viewort problem has been fixed. I hope AMD took to work and seriously wants to gain points with pro users. I wonder if version 6.1 will work with rx 6600 xt and if rocDecode will be available on my GPU. I can’t wait for my Nobara 38 distro to do an update from version 5.7. Release ROCm 6.1.0 Release · ROCm/ROCm · GitHub

599

With Arch Linux it looks like rocm 6.1 from opencl-amd no longer has issue 100353.

Cycles may finally works on Linux with an AMD GPU after… 2 years 4 months and 14 days (Blender 3 release to rocm 6.1 release). AMD please target the release next time to avoid being a few years late.

4 Likes
600

hey, cool to know someone is still using this package and it can be useful :stuck_out_tongue: it seems that its popularity dropped a lot in the recent years.

1 Like