The Mesa driver from version 20.3 has full OpenCL 1.2 support, but Blender doesn't support GPU rendering using Cycles render. Why?
When can we expect full Mesa driver support?
My GPU is an AMD 5700 XT
Blender Stack Exchange is a question and answer site for people who use Blender to create 3D graphics, animations, or games. It only takes a minute to sign up.Sign up to join this community
OpenCL will no longer be supported going forward, and GPU rendering accelaration under AMD cards is at the moment discouraged.
OpenCL development is stagnant and the implementation insufficient for a properly working render engine.
There are critical bugs and limitations that wont allow for a proper implementation using the API. Developer support is also limited with no significant new work being developed for a long time.
No further developments are expected at this point, and support will be dropped going forward, as stated in the Blender Code Blog about Cycles X
As part of the new architecture, we are removing some functionality. Most notably:
- OpenCL rendering kernels. The combination of the limited Cycles split kernel implementation, driver bugs, and stalled OpenCL standard has made maintenance too difficult. We can only make the kinds of bigger changes we are working on now by starting from a clean slate. We are working with AMD and Intel to get the new kernels working on their GPUs, possibly using different APIs (such as CYCL, HIP, Metal, …). This will not necessarily be ready for the first release, the implementation needs to reach a higher quality bar than what is there now. Long term, supporting all major GPU hardware vendors remains an important goal, and we think that with this new architecture we’ll be able to better performance and something stability. It is just a matter of time until more GPUs are supported in Cycles X again.
OpenCL for Cycles will be deprecated for the time being, and as such GPU rendering on AMD Radeon dedicated cards or Ryzen APUs integrated GPUs will no longer be supported. This also means that any current known limitations, bugs and unsupported hardware or features will no longer be improved or worked on.
Further developments are expected possibly using different APIs, but no definitive plans are made at the time of writing
A new API is currently being developed to replace OpenCL named HIP for Windows and Linux only, (no explicit Apple MacOS support at the moment).
HIP is a C++ Runtime API and Kernel Language that allows developers to create portable applications for AMD and NVIDIA GPUs from single source code.
Key features include:
HIP is very thin and has little or no performance impact over coding directly in CUDA mode. HIP allows coding in a single-source C++ programming language including features such as templates, C++11 lambdas, classes,
namespaces, and more. HIP allows developers to use the "best" development environment and tools on each target platform. The HIPIFY tools automatically convert source from CUDA to HIP. Developers can specialize for the platform (CUDA or AMD) to tune for performance or handle tricky cases.
New projects can be developed directly in the portable HIP C++ language and can run on either NVIDIA or AMD platforms. Additionally, HIP provides porting tools which make it easy to port existing CUDA codes to the HIP layer, with no loss of performance as compared to the original CUDA application. HIP is not intended to be a drop-in replacement for CUDA, and developers should expect to do some manual coding and performance tuning work to complete the port.
It has been merged into experimental Blender already, but is highly experimental and under heavy development at the moment. It is being actively worked on, but it currently doesn't work under Windows yet due to lack of driver support.
Before even asking where you can download it or how to try it, be aware that it is not ready for end users, not even for testing. It is unstable and untested, and there are no available builds at the moment. Reporting bugs is discouraged since problems are totally expected and at this point, and triaging them only distracts from actual development.