Hi,
Sorry for bringing such update on a short notice. We had to disable Vega GPUs support for Cycles HIP rendering. The reasoning for this is an accumulated list of bugs which can not be resolved from Blender or Cycles side and require fixes in the compilers toolchains. Unfortunately, there is no official support of these GPUs in ROCm anymore, so it is completely out of our control.
Sorry for asking, but what that really means. I should not update to Blender 4.3? I will not be able to GPU render but yes CPU?, sell my kidneys?, anything else?, my GPU is a Radeon Pro Vega 56.
You can always render on CPU Cycles, and GPU Eevee. The change is only making it so you can not render on GPU Cycles if you have Vega card.
ok, thank you for the fast answer. 
I manually reenabled Vega in 4.5 Alpha and built it locally on Arch with all features enabled except Opencollada. This is also on the latest ROCm 6.3.4.
I was able to render the BMW and Classroom scene on 2 Vega20/gfx906 GPUs just fine as you can see and its MUCH faster than on CPU (EPYC 7352 24Core). Perhaps the issues in HIP you were seeing have been fixed if so I would not mind doing the work to run a test suite to confirm that. Also Vega20 GPUS ARE supported… still on HIP and this should mean gfx900 which is vega10 is also for all intents and purposes fully working also since the main difference is DP4A instructions.
It’s clearly a major inconvenience to people that may have Vega GPUS as their main GPUS still, perhaps, I think rejecting bug reports and leaving the notice in the settings UI would be more fair to them than outright disabling what appears to be very functional support for this GPU.
Hi,
I am not sure what is the main message you’re bringing.
If it is about re-considering the decision: I do not feel confident that Vega support in drivers will be at a decent level for the next 2 years, so enabling these cards in an upcoming LTS does not seem like the right decision.
We want to ensure that Blender comes with a level of quality, and predictability. Giving ability to choose device configuration that is known to have issues is not something we want to do. There are all sorts of implications coming with that, including cases where people might be buying GPUs thinking they are supported, just to then figure out that their specific scene does not work.
What exactly is the rub that prevents enabling code that runs fine… you are saying one thing and doing another, disabling GPUS that work is surprising. And not something that anyone would predict. Enabling Vega doesn’t harm users and has minimal impact on developers but disabling does harm many Blender users.
This setup I am running above is nearly twice as fast as a W5700… so even though its nowhere close to say a 4090 its not so old that it not worth consideration IMO. Its also about the cheapest way to get large VRAM + reasonable compute performance without spending > $600 ($200 if you only get the 16GB version)
Also, the NODE.AI group that AMD bought is working on a CI setup for more AMD GPUs to improve ROCm’s backlog of “unsupported” GPUs… they have pledged 10 years of support as their intent which would line up at least with the LTS.
It’s ironic really because you are causing the exact scenario, apparently needlessly, you claim you are trying to prevent. Because I literally bought these to run blender and AI renders on, and now I can’t run stock builds… I do understand that ROCm has not been the bastion of stability, but really there is no reason to expect anything to happen to gfx9 support for a long long time. There are it seems two or more factions in AMD so the mixed signals is of course not helpful in situations like this.
Lets deal in facts rather than feelings. If gfx900 and 906 of which I have both, can pass the test suite I’d like to see it enabled that seems entirely reasonable to me.
Disabling support for something in code is DIFFERENT… than removing it from a recommended hardware list. Disabling old GPUs harms the group of blender users that are most vulnerable … the trailing edge. And of course they could still continue running 4.3… but why not 4.4 also as it appears nothing actually prevents that other than about 3-4 lines of code.
In my testing also on Linux with ROCm 6.3.4, things have improved for Vega, but it’s still not perfect. Specifically, Vega 64 fails 41 tests in the Cycles render test suite.
So in my opinion Vega still isn’t ready to deploy to the public as “fully working”.
How do you actually run the test suite with HIP, I was able to run it for CPU but not GPU results. I tried exporting the value as well as setting it in the cmake file the documentation states configures that but it kept running as CPU. It could be something with cmake 4.0 on arch but hopefully not.
So… the issue is essentially 1 feature of cycles as a roadblocker that’s good to know.
Just so things are clear, I’m going to provide the full list of instructions from building Blender to testing.
cd ~/blender-git/blender
python3 ./build_files/utils/make_update.py --use-tests
make update
~/blender-git/build_whatever/CMakeCache.txt set CYCLES_TEST_DEVICE to HIPcd ~/blender-git/build_whatever/
ctest -R cycles -C release
Thanks that helps, note that you forgot that you also have to run make after editing the CMakeCache.txt or it will just continue running the CPU tests. Previously I was editing that flag in the wrong file apparently since the documentation doesn’t actually say what file to edit.
My Results, definitely does show quite a few marginal as well as obviously broken things. PDF Cycles HIP Test Report_Vega20.pdf - Google Drive
Edit I also just noticed the PDF misses the red highlight for failed tests, for the more obvious ones you can still see it in the color diff though.