Hi,
Same for me with my radeon VII… waiting hard !
3 Likes
Looks like HIP RDNA Linux support will be pushed back to 3.2 which appears to be scheduled for June 8, 2022.
Its bad news for Linux RDNA owners. Strangely these days a delay is about as good as it gets for AMD GPUs when compared to the lack of commitment that Vega / Polaris owners are faced with. In other news Nvidia GPUs remain supported 
.
3 Likes
There is some hope that ROCm version 5.x will be fully packaged in Ubuntu Jammy 22.04 LTS releasing April 21st 2022. 4.5.2 packages are still entering Debian:new. So that would be somewhat coinciding dates.
P.S. 20220129 lol, no way
While waiting for Blender acceleration, if you wish the ROCm/HIP stack success, you are welcome helping documenting it! 
@bsavery since we are on a developer forum: would you or an involved AMD developer be kind enough to walk us through the challenges and technical designs that are being dealt with? I am guessing that graphic/compute interop is a big topic since it is not supported officially yet, but any more details and/or vulgarization would be enjoyed.
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
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
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
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
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
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.
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
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
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
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
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
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.
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
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
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.
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
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