The GPU (and also CPU) driver/firmware landscape is riddled with licensing troubles. It’s a sad state of affairs, but the only way to get some work done is to stick your head in the sand and go lalalacanthearyou. I really hate this. Also because each vendor needs to have their own flavor of the same thing and writing cross platform code (hardware platforms, in this case) gets harder and harder.
Sometimes it feels like it’s the early nineties again where if you wanted to get sound out of your game you had to write code for many many many soundcards because the idea of a ‘driver’ was nonexistent in DOS.
The only hope we have is Khronos. But they’re by default always a few iterations behind the cutting edge (though Vulkan seems to really take off for a change).
It’s a PITA. I read some topic about a linux distro who could not distribute blender with Optix enabled because NVIDIA has a restrictive license on the fscking headerfiles.
Sometimes I dream of a world where the raspberry pi foundation makes a GPU which actually blows the big 2 out of the water. Not a realistic dream, but a happy one
I’m sure most people, myself included, are pragmatic and don’t really care all that much as long as they get something that works and performs well, but there are open source purists (nothing wrong with that), and they tend to chose AMD over Nvidia, so it really shouldn’t come as a surprise to see this sentiment, especially in an AMD centric thread.
Linux Testers. TLDR: Latest Blender 3.2 nightly builds should work with ROCM 5.1 driver now.
Long story: There was a simultaneous change on the blender side that affected something in our compiler. We’re working to get that fixed and hoping to get Vega cards working for 3.3
On the HIP RT (hardware ray tracing) side, as readers of this thread saw we released the library, look for more info and definite date of this integrated to Blender in June / July.
Brain, I was wondering if you could clarify some things about the Linux implementation of HIP to clarify things for users and for assistance in writing the documentation about Linux support.
Let’s assume a user has downloaded a version of Blender for Linux compiled with HIP. And they have an RDNA2 graphics card that’s supported. What do they need installed for Cycles HIP to work?
In the commit message for official Linux support it says
This requires the 22.10 / ROCm 5.1 driver.
Source: rB179100c02126
I assume this means you need at least AMD Radeon Software 22.10?
What about AMD Radeon PRO Software? Does any version of that driver support Cycles HIP on Linux? Or will a future release support it?
Is there anything else I’m missing?
Am I mis-understanding something? Do you need both the AMD Radeon Software 22.10 and ROCm 5.1 packages installed for Cycles HIP to work?
Just tested the 3.2.0 alpha (179100c02126) it crashed the display driver and X the first time but worked the second time… I didn’t try a third.
System Details
OS - 5.17.1-arch1-1
Drivers - Mesa 22.0.1 with propietary ROCM 5.1.1 from AUR opencl-amd package
GPU - RX 6800 (gfx1030)
Scene - Classroom
Tile Size - 2048
Samples - 300
3 renders with HIP on 3.2.0 alpha (179100c02126) got times, 00:46.04, 00:46.12, 00:46.14
3 renders with OpenCL on 2.93.9 (31712ce77a6a) got times, 01:35.81, 01:35.51, 01:35.70
If you want to compare apples to oranges I compared to the old 3.0 benchmarks from techgage. Running classroom at 2560×1440 with 256 tiles I got about 77 sec on HIP Linux which is fairly similar to the 85 sec for HIP windows considering 3.0 is nearly 4 months old at this point.
Congratulations to AMD and Blender, AMD Linux users will soon benefit from CyclesX as Windows users have. Hopefully HIP RT can be delivered in a timely manner resulting in competitive RDNA2 GPU’s.
Did a quick test using ROCm 5.1.1 from rocm-arch, with some of my own scenes and the BMW scene. Doesn’t work, address boundary error while preparing textures. Probably caused by the bug bsavery mentioned. An untextured test scene I quickly threw together using Curtis Holt’s material test object and his procedural candy shader did work: 9’13" CPU, 2’46" GPU. Quite an improvement!
Very nice, finally working on Linux, only funny thing is that CPU won´t add any performance on the rendering despite being used at 99% most of the render time
I windows platform 6800xt clock boosted to 2600mhz can only 1 minute 32 seconds to complete 300 samples, 6800 default 46s, linux this is equivalent to the performance of windows after opening Ray Tracing almost
6800xt theoretical performance at least 20 percent faster than 6800,46/1.2 equal to 36, linux is almost 2.7 times faster than windows rendering speed, reference cpu in linux speed 25-30 percent faster, that is 36/97/1.3 equal to about 2, that is to say, windows should be twice as fast to be a reasonable speed?
Just tested the alpha (179100c02126) on Ubuntu 22.04 LTS. Viewport rendering is fine but as @L_S has said, an actual render crashes the display driver and X - even with just the default cube scene.
I’m not sure if this is the right place to give feedback. And this have probably been mentioned before. Sorry, I didn’t real all 225 comments.
I’m now running GPU on my iMac Pro Vega 64. I see there’s an option to render with GPU or GPU and CPU in the metal prefs. I though adding the CPU would make a big difference but for render time it’s negligible. But for the memory, If I look at the peak, GPU only took twice as much memory. I don’t understand why.
I was rendering the lone monk demo file.
GPU only: 1271.67, peak 1271.68
CPU and GPU: 479.01M, peak 603.59
I tested the windows environment many times, this scene 300 times the sample is indeed 1 minute and 32 seconds, cpu:5900x data in 4 minutes and 9 seconds, linux if can be completed in 40 seconds that means fast 2.5x
Funnybob, the information found below is still relevant for you. However, for future reference feedback on Metal should go the Metal feedback thread. Cycles Apple Metal device feedback - #340 by S.I
Cycles-X in it’s current form less than ideally schedules work between multiple devices of varying performance in scenes with varying complexity across the frame. As such, enabling CPU + GPU usually doesn’t give people the performance increase they expect.
Investigation is underway to fix this. But until that fix is implemented, that is how Cycles-X works at the moment.
