Cycles AMD HIP device feedback

Feature & Design Feedback
86

Linux RDNA2 users might have a chance to try a new 5.1 ROCM version soon.

Reasons this will amount to a hill of beans:

  • No word from AMD
  • Could be a typo as its a really strange place to mention release plans
  • ROCM 5.? has been pushed back several times.
  • ROCM 5.? might not fix what breaks Blender HIP.
  • Blender isn’t verified with ROCM.
  • Proprietary driver may or may not be released.
  • Proprietary driver may not be able to be tested with Blender as HIP is currently disabled.
  • AMD mentioned code changes are required to Blender 3.2 that have not been made.

Reasons to be excited:

  • You can’t become less supported than not supported.
2 Likes
87

As far as I understood, for Linux, Mesa-ROCm(HIP/OpenCL) graphics/compute interop is not even in the works yet, only interop with the proprietary graphics drivers… Communication from AMD is indeed bad on this subject.
Hopefully updates soon. https://github.com/ROCm-Developer-Tools/HIP/issues/2237

P.S. Interop is a very broad term, it binds compute kernels to graphics APIs, but it is not really defined anywhere. There is a huge surface area WRT APIs where interop is possible graphics{OpenGL, Vulkan} – compute{HIP, OpenCL}.
I suspect AMD of focusing work on AMDVLK or its proprietary vulkan driver, to the detriment of Mesa’s RADV. You could have interop with opencl, with opengl… the list and feature matrix can get big, I (we?) just don’t know what AMD plans.

1 Like
88

Enabling HIP alone in Blender is very easy, and it can be done by passing a couple of extra options to CMAKE, and obviously you have to compile from source. I’ve added this when editing AUR PKGBUILD for blender-git version:

-DWITH_CYCLES_DEVICE_HIP=ON \
-DWITH_CYCLES_HIP_BINARIES=ON \
-DCYCLES_HIP_BINARIES_ARCH=gfx900 \

where gfx900 is my Vega 64 arch from rocminfo output, I think RDNA 1/2 is included by default

If you have a non-RDNA GPU you also have to tweak some major/minor arch vars in util.h iirc, and I don’t actually know what they’re responsible for and noone will probably tell us, the old commit rB2f89ddc04377: Cycles: eliminate HIP architectures that fail to build that added HIP bins to be built for more GPU arches is now deleted, so just forget about it.

And building ROCm from source is an adventure of it’s own for several days with numerous build errors that have to be addressed every time. I just don’t bother anymore.

I feel so dumb now for picking Vega over RTX looking forward to years of support that AMD was known for at the time, for better support by open-source drivers. Nvidia proprietary Linux driver is horrible, there’s no overclocking or fan/power management support etc. But this thread just screams at me “Go buy Nvidia as soon as prices settle down and forget AMD GPUs as a bad dream!” Such a spit in the face of AMD users by essentially taking away GPU rendering, the lack of communication, this thread is a joke. At least AMD developed a great CPU to render with that doesn’t require “”“the driver”"" to work, but still times slower than GPU rendering.

3 Likes
89

Yup, sitting here stuck on 2.8 because my Vega 56 turns into a paperweight with Cycles X. But on OpenCL it’s hardly any better because the render kernel fails to compile like 60% of the time and crashes blender. Almost tempted to sell my vega for a ridiculous price while I still can.

1 Like
90

Since this stack is almost completely free and open-source, in theory anyone, with enough will and technical knowledge, is able to write their own graphics(OpenGL/Vulkan)/compute(HIP/OpenCL) interop and debug this Blender-Cycles-AMD-ROCm-HIP-Mesa-Linux thing.
I am almost seriously considering candidating to GSoC 2022 on this subject, depending on feedback from BSavery once he returns from parental leave.

@FogLizard compiling ROCm is almost acceptable now. There are still internal efforts at AMD to improve the build system, and people like Ye Luo and me are also trying to give a hand.

5 Likes
91

I am 2.9 began to contact blnder opencl except in 2.93 can not render the volume of other cases do not appear crashing problems, if frequent crashes I think it may be the first installation of the software for a few minutes of pre-compilation problems, it is recommended to delete the entire cache to recompile once, during the blind point do not rush to exit the software, in addition opencl each rendering of large scenes require a certain amount of pre-compilation time, rocm solves this problem.

92

That’s really good, I think the performance ratio can be restored to 2.93 opencl and cuda like satisfied, more complex scenes can be faster than cuda same level gpu, simple scenes amd gpu no matter what renderer are consistent does not dominate, anyway, noise elimination soon does not matter.

1 Like
93

There are interesting open discussions, on the topic of AMD ROCm-Vulkan interop and its technical challenges, at the Mesa mailing list dri-devel, on the CRIU (!) thread:

https://lists.freedesktop.org/archives/dri-devel/2021-May/thread.html

94

If pal is the windows HIP runtime, and rocr the linux HIP runtime…
focus does seem a bit skewed, doesn’t it?
Lines added in each repository during last year:

maxzor@mada:~/rocm/gpuopen/pal$ git log --since=2021-02-01 --until=2022-02-01 --format= --numstat | awk 'NF==3 {plus+=$1; minus+=$2} END {printf("+%d, -%d\n", plus, minus)}'
1076340
maxzor@mada:~/rocm/ROCm/ROCR-Runtime$ git log --since=2021-02-01 --until=2022-02-01 --format= --numstat | awk 'NF==3 {plus+=$1; minus+=$2} END {printf("+%d, -%d\n", plus, minus)}'
6461

PAL repo: https://github.com/gpuopen-drivers/pal
ROCm runtime repo: https://github.com/radeonopencompute/rocr-runtime

Where is the equivalent? https://github.com/GPUOpen-Drivers/pal/blob/dev/src/core/hw/gfxip/rpm/g_rpmGfxPipelineBinaries.h

1 Like
95

I still do not understand whether they are going to add support for HIP old video cards amd? And if they are going to, what will be at least approximately a performance gain? After all, the conditional 580 in the bare computations better than the 1060. Will it at least have the level of 1060 if they add support? Or is it like most of amd software? And if support is not planned then please write about it so we can sell these graphics cards while they are still worth something

2 Likes
96

AMD have not committed to dates on support for Vega or Polaris. They missed the 3.0 release for all but RDNA on Windows and are planned to miss broadening support in 3.1. AMDs lack of commitment and results once again reinforces their reputation for substandard support in productivity programs like Blender.

Another potential hiccup for our 580’s may be AMDs confusion / conflict in Polaris Rocm/HIP support.

1 Like
97

bsavery already mentioned multiple times that they are committed to this, I personally do not think that it is productive to constantly bash AMD here. Also there is no incentive for AMD to support previous generations given when the person buys it they buy for the currently available options, I doubt that AMD ever promised that years later they could come up with a new technology for Blender where the users of old cards can enjoy even faster speeds.

I do not own an AMD card myself and I had to shell out money to buy an over priced RTX card to do my work unfortunately, I would have been happier if I could buy a reasonably priced AMD card and enjoy the new implementation, but it does not seem to be there yet.

98

I think there is another factor in play here. Namely, being able to use the GPUs at all. With the removal of OpanCL AMD users are left with basically a paperweight.

OTOH I agree with you about bashing.

3 Likes
99

I feel the use of terms like “no guarantee” and “don’t want to commit” convey a lack of commitment. English is full of nuance however.

It is not my goal to “bash” but to be subjective. I think Blender and AMD are doing themselves and their users a disservice by placing such a low priority on widespread GPU support. Currently we have Nvidia with extensive support and a posts to r/Blender every few days along the lines of “Why doesn’t my AMD GPU render?”.

Perhaps if more are vocal about Blenders GPU support you may have more options the next time you purchase a GPU?

4 Likes
100

Based on all the responses I saw from bsavery, it seemed clear that AMD has put GPU support in Blender commitment forward. However, this is not an easy battle for them to win right away given Nvidia’s dominance in this field and their available resources. My point was based on the fact that the negative tone will never make things any better for anybody, rather AMD might find positive user outreach to be a better motivator.

I am not a gamer, I will never buy an AMD card based on game benchmarks. If AMD wants to sell GPU cards to the professionals they need to up their GPU rendering game in DCCs like Blender, that is for sure.

101

I think people can be both understanding of the situation at hand yet also be incredibly frustrated. At the same time, I don’t think a multi-billion dollar corporation needs anybody defending them on the internet; if individuals were being attacked, that’s another story, but I don’t see that happening. AMD has the money and resources to make swift work of this issue, but they aren’t doing so because they ran the numbers and figured that the relatively minuscule number of people it effects wasn’t worth it.

Not to mention, this may be passable for people who simply can’t use Blender 3.0, but I bought two Vega 56 cards in 2019 specifically for Blender, and haven’t been able to use them to render anything in any version without my system crashing. The devs and AMD knew of the issue for over two years and did nothing. And to counter your “AMD might find positive user outreach to be a better motivator” claim, I had to raise a massive stink on Reddit to get in touch with anyone at AMD to finally take a look at the issue – Their engineering department sent me drivers that wouldn’t crash my computer when I rendered, but I got blue screens instead. They wrapped it up and called it good.

I’ve waited so long to actually do what I bought my cards for that it’s hard to care anymore. Not making older card support a priority after disregarding older cards not even working at all is just salt in the wound at this point. The message has already been sent very loud and clear that if you want actual support for a graphics card, buy Nvidia instead.

6 Likes
103

Development doesn’t happen overnight.

It has been stated several times, that there is work going on to support more cards and also support Linux.
There will be an announcement once there is news on that.

3 Likes
104

I agree that development doesn’t happen overnight. I just hope something can be learnt so the pain is eased the next time GPU support is on the chopping block or getting unmanageable. We all look forward to any announcements when you have more info. Thanks!

1 Like
105

David Airlie, the maintainer for the Linux graphics subsystem - this means he is responsible for the Kernel Mode Setting / display subsytem, the Direct Rendering Manager subtree, all GPU drivers… has an interesting read about AMD’s somewhat antiquated culture of open-source, on why it repeatedly fails to build a community around its software.
This includes the huge problem of poor documentation, the topic of ‘closed development’ without communication, and not really welcoming external contributions. In French there is the expression fauxpen-source.
Which is at this point not a whole lot better (still much better for me, depends on the point of view!) than closed-source with great communication, intense lobbying, and excellent documentation as Nvidia does.

There are areas where this is improving and AMD engineers are doing awesome, the work on the linux kernel dri-devel and amd-gfx mailing lists for the development of amdgpu.ko is cool, the job of AMD LLVM engineers upstreaming their compiler developments is great, what Cordell Bloor and Jeremy Newton do with the Debian and Fedora packaging communities - outside of their official job!! - is in my opinion fantastic.

Still a personal opinion, the issues discussed here might originate in various spots sitting between executives, upper and middle managements… whom are cultivating this toxic culture of control, which in the end might be disserving the company.

P.S. The graphics-pipeline is particularly hit by this open-source-released trend, and this AMD department is frequently subject to privileging its own projects to the detriment of the community ones even if the latter are in a better shape: similar to the past split between the community’s RADV and AMD’s AMDVLK, about Vulkan implementations, which still remains to this day; there is on one hand Cycles for Blender, and on the other hand AMD ProRender, with ProRender having clear priority.

AMD has the money and resources to make swift work of this issue

This is a bit tricky, AMD has long been starved for cash-flow, they are still in a transitioning period, where the cash-flow has improved, but scaling the teams and the strategies are still pending topics.

Did you know that there is still technically support for the Radeon HD 2000/3000 Series (R600) in the LLVM backend?!

6 Likes
106

You doubt it, because you don’t know any better. HIP was on the roadmap back in 2018 when I bought my Vega 64, and there is absolutely no reason or excuse not to support it now.

If you don’t have an AMD GPU, why are you here? Go enjoy your RTX card and don’t spew out misinformation.

4 Likes