Was GPU support just outright dropped for GPUs that are not very very new?

Archive User Feedback
1

I was just looking up Cycles on AMD OpenCL in hopes of seeing when I might be able to do GPU-accelerated renders again, as to my understanding Cycles X was only supporting really exotic APIs at first and then going on to support more. However, looking at this blog post, I think I may have been wrong. Is support being dropped entirely for GPUs outside of these exotic APIs? Is no support planned for Vulkan or anything? It would be a shame to no longer be able to use GPU acceleration at all and have to use CPU for everything. My 2011 Xeon X5690s are very fast, yes, but not nearly as fast as I would get rendering on a real GPU despite somehow being able to ray trace in almost real-time.

If it really is planned to leave everyone who is not constantly upgrading all the time in the dust, what options might there be to render a little bit faster? Is there some way to export to older versions of Blender that includes hair systems? Or perhaps some other render engine would work, though, that might have a lot of problems with missing features. Alternatively, could new Blender be modified to export to old Cycles? I’m pretty sure most people are not using post-2020 GPUs (in my own experience meeting people (often in VR too!) and looking at the current Steam Hardware survey) so a workaround would be very helpful to a lot of people.

3 Likes
2

Ooh, I wonder if this could help increase compatibility: LLVM's HIPSPV Coming Together For AMD HIP To SPIR-V For OpenCL Execution - Phoronix.

FOSS community to the rescue yet again!

I am glad HIP is an open standard, and more glad that people have actually decided to build on it unlike, say, ROCm which suffers from lack of support on older hardware.

2 Likes
3

I think it’s best to understand the history of OpenCL in Cycles to understand why it was removed. And then I’ll talk about the new APIs to explain why they’re limited.

Back in version Blender 2.79, Cycles used CUDA to provide GPU rendering support to Nvidia. It also had OpenCL to provide GPU rendering support to AMD GPUs (and in later releases Intel GPUs?).

With the release of Blender 2.80, OpenCL in Cycles was removed from the MacOS build of Blender. This is because Apple had stopped supporting OpenCL and the Cycles developers were now experiencing issues with the OpenCL compiler on MacOS, something that would be best fixed by Apple updating the compiler (which they weren’t doing as they stopped support it).

As time continued with the release of various Blender versions, OptiX was added for Nvidia GPUs (primarily Nvidia RTX), and OpenCL was improved upon and updated. However, there were frequent issues that occurred with OpenCL. With the release of Blender 2.83? All AMD GPUs running certain modern GPU drivers had large rendering errors. And I believe there were issues with OpenCL rendering having issues with volumetrics (still present in 2.93?) (I’m not sure if this was a Cycles bug or a driver bug).

So when the Cycles team decided to re-write Cycles in the form of Cycles-X, they decided to remove OpenCL as an option. It just had lots of issues.

That’s the history of OpenCL and why I believe it was removed. Now onto why the new APIs are being used and why there are limitations on them.

During some point in the development of Cycles-X, AMD and the Blender foundation were in contact and AMD proposed the idea of using the “HIP” rendering backend for AMD GPUs. There were a few advantages to using this system:

  1. HIP is very similar to CUDA in terms of code style. Meaning maintaining HIP code should be quite similar to maintaining CUDA code.
  2. AMD was willing to take on the task of porting Cycles to HIP + adding various features. Compared to letting the Blender foundation do all the work.

There’s just a few issues with HIP.
During the early development of Cycles-X, HIP was only supported on Linux.
And support for modern GPUs was missing or lacking? - I may be wrong on this one.

So, along side adding HIP support to Cycles, HIP had to be ported to Windows. HIP had to be updated to have better support for modern GPUs. And the AMD GPU drivers on Windows had to be updated to support it.

The focus was on getting HIP in Cycles working on RDNA2 or newer GPUs. And that’s what they did with the initial release of Cycles-X. (RDNA1 support was also enabled as it appeared to work well)

Support for older GPUs was being investigated. This is because older GPUs were having experiencing crashes or errors when trying to run Cycles HIP. And these issues need to be fixed before they can be enabled.

Work has been done and support for Vega has now been enabled in Blender 3.2 (there are still some issues with it and that is under investigation). Older GPUs like Polaris are also being “investigated” to see if they can be enabled.

Along side the addition of HIP, Apple contributed code for a “Metal” backend that allows MacOS users to use Cycles with their GPU. It supports all(?) AMD and Apple GPUs supported in MacOS 12.3.

And recently, Intel has provided OneAPI, used to provide Intel GPU rendering support in Cycles. It is limited to Xe GPUs.

A large benefit of this is that the rendering APIs/backends are being provided by the company that made them, rather than leaving development entirely up to the Blender foundation. This reduces the workload on the Cycles developers. And it means compiler and/or driver bugs are expected to be fixed in a more timely manner (something that has been very important for the development of HIP and Metal, as both had bugs related to the drivers/compilers during the development).

Just for completion sake.
Apple’s Metal in Cycles supports all AMD and Apple GPUs supported in MacOS 12.3
Intel’s OneAPI in Cycles plans to support Intel Xe and newer.
AMD’s HIP in Cycles supports AMD Vega and newer.
Nvidia’s CUDA in Cycles supports Nvidia Kepler (GTX 700) and newer
Nvidia’s OptiX in Cycles supports Nvidia Maxwell (GTX 900) and newer? - I may be wrong about this.

24 Likes
4

A short version of what I just wrote.

OpenCL support was removed with Cycles-X as OpenCL had various issues with it.

In place of OpenCL, AMD provided HIP, Apple provided Metal, and Intel provided OneAPI to allow Cycles GPU rendering on their GPUs.

Many of these rendering backends have more limited support for older GPUs compared to OpenCL due to bugs related to older GPUs that are considered a “low priority” by the companies working on them.

There are plans to support older GPUs, but it will take time to fix the issues. And in same cases it may not be considered “worth it” to support older GPUs.

A benefit of these companies providing rendering backends is that the companies are employing developers to work on the Cycles project. Which reduces the workload on the Cycles developers and allows for quicker development of the respective companies rendering backend.

21 Likes
5

I have a Radeon Pro VII. RDNA with the latest drivers, but still no support in any beta or alpha releases. Is this simply an overlook of activation for this card? The Pro VII is something that AMD marketed and forgot about so it’s understandable that it isn’t a priority for Blender.

2 Likes
6

The Radeon Pro VII is Vega based, not RDNA. As such, it is not officially supported in Blender at this current point in time.

AMD did try enabling Vega support in an earlier development version of Blender 3.2, but experienced some major bugs. They are attempting to fix those bugs and potentially re-enabling Vega support later on. But until then, Vega is not officially supported.

2 Likes
7

Thanks, Alaska! That explains it.

1 Like
8

Any chance for moblie GPU’s like the Ryzen 5800u to get supported in the future?