Blender 3.1 Released With New Features Sans AMD HIP Linux GPU Acceleration

[Quackdoc]

Direct your disappointment at AMD. Their compute stack is a mess, and nothing Blender devs can do.

Exactly this. It was AMD themselves who said that it wouldn't be ready, this is zero fault of Blender. since people are too fucking lazy to read the linked article and jump on blender

https://developer.blender.org/T91571#1291811

No, it's not. AMD supported OpenCL 2 since ages yet Blender decided to go the proprietary CUDA way nonetheless.

Blender did support OpenCL, and it was trash

There's Vulkan Compute...

That is one of the goals they hope to achieve for end of 2022. as announced on their blender 3.x roadmap article from November I think.

[kiffmet]

If they used Vulkan over MoltenVK they could have tackled Mac and AMD/Intel Linux support simultanously while having less work to do in total.

[stargeizer]

OpenCL support in Blender wasn't trash, but not good either. Also OpenCL wasn't developed for big operations in it's original form (OpenCL 1.0), and TBH, wasn't good for anything more than simple parallelizable operations. And raytracing itself is a very complex operation. Add to that that the kernels had to be compilled at runtime (that's why Blender took up to 55-60 seconds, depending on the GPU to compille the produced source code from Blender nodes to a GPU executable that "maybe" can run, and that wasn't Blender Devs fault, but rather hardware/drivers bugs) when on the green side of things, Blender Devs just distributed precompilled CUDA binaries (That's why Blender devs deprecated support for older GPU's that the CUDA SDK also discontinued at the time).

OpenCL 1.2 brought several features that allowed devs to run the big Cycles kernel on AMD GPU's but it was slow as h*ll and heavily prone to crashes, due to hardware limitations. That's why AMD stepped in and helped breaking the big Cycles kernel into smaller microkernels that did run fast on AMD GPU's, except for some features of the raytracer that weren't possible to do on OpenCL at the time. And OpenCL support on Linux was even less than stellar, compared to windows, but to be fair, OpenCL for windows wasn't good either.

OpenCL 2.0 was a big mess on AMD side. Broken drivers also weren't helping (Both Windows and Linux sides). And About OpenCL, nobody else's cared, not even Apple, who invented it. Finally Apple deprecated it, and the rest of the industry just followed the trend. OpenCL 3.0 was dead on arrival. So Blender devs had no option but to deprecate it.

IMHO OpenCL was one of the bigest Industry mistakes ever conceived. But since everyone loves to dance the Apple tune, the mistake took off. Now AMD is trying to fix the mess with their HIP solution. But as usual, it will take time.

[jrch2k8]

OpenCL support in Blender wasn't trash, but not good either. Also OpenCL wasn't developed for big operations in it's original form (OpenCL 1.0), and TBH, wasn't good for anything more than simple parallelizable operations. And raytracing itself is a very complex operation. Add to that that the kernels had to be compilled at runtime (that's why Blender took up to 55-60 seconds, depending on the GPU to compille the produced source code from Blender nodes to a GPU executable that "maybe" can run, and that wasn't Blender Devs fault, but rather hardware/drivers bugs) when on the green side of things, Blender Devs just distributed precompilled CUDA binaries (That's why Blender devs deprecated support for older GPU's that the CUDA SDK also discontinued at the time).

OpenCL 1.2 brought several features that allowed devs to run the big Cycles kernel on AMD GPU's but it was slow as h*ll and heavily prone to crashes, due to hardware limitations. That's why AMD stepped in and helped breaking the big Cycles kernel into smaller microkernels that did run fast on AMD GPU's, except for some features of the raytracer that weren't possible to do on OpenCL at the time. And OpenCL support on Linux was even less than stellar, compared to windows, but to be fair, OpenCL for windows wasn't good either.

OpenCL 2.0 was a big mess on AMD side. Broken drivers also weren't helping (Both Windows and Linux sides). And About OpenCL, nobody else's cared, not even Apple, who invented it. Finally Apple deprecated it, and the rest of the industry just followed the trend. OpenCL 3.0 was dead on arrival. So Blender devs had no option but to deprecate it.

IMHO OpenCL was one of the bigest Industry mistakes ever conceived. But since everyone loves to dance the Apple tune, the mistake took off. Now AMD is trying to fix the mess with their HIP solution. But as usual, it will take time.

Well, honestly HIP doesn't look good either, so far is an over engineered mess with awful GPU support.

At this time i think AMD should drop HIP entirely(outside maybe CUDA translation) and maybe use those new Xilinx devs to implement a compute backend on NIR with Karol and then add compute APIs on top of it because i think it will end up been faster. At the current development rate HIP will be usable on kernel 7.20 and Clang 33

[Quackdoc]

Well, honestly HIP doesn't look good either, so far is an over engineered mess with awful GPU support.

At this time i think AMD should drop HIP entirely(outside maybe CUDA translation) and maybe use those new Xilinx devs to implement a compute backend on NIR with Karol and then add compute APIs on top of it because i think it will end up been faster. At the current development rate HIP will be usable on kernel 7.20 and Clang 33

I would personally rather just wait for the vulkan work myself, but I realize something needs to get done faster for AMD, and if HIP is it then I am all for it.

[numasan]

Why was my previous post "unapproved" (by whom) and what can I do about it?

[oleid]

Why was my previous post "unapproved" (by whom) and what can I do about it?

That's a spam filter, not to worry about.

[Paradigm Shifter]

Actual hardware support for HIP/ROCm is still woefully lacking, and frankly with oneAPI and coming Intel GPUs, AMD now has two behemoths to overcome (nVidia for sheer dominance of the compute space with CUDA, Intel because they can throw money at it until they get bored and abandon it). If I could actually (reliably) run ROCm on my 6800M or 5700G, I'd put way more effort into getting to grips with it, and AMD have made some progress recently. It still feels like "too little, too late", though.

[darkbasic]

Blender did support OpenCL, and it was trash

That happens when all your development is towards a proprietary API and OpenCL gets the second tier citizen treatment.

[darkbasic]

It was undead garbage anyway, performance with RDNA2 cards was pathetic. You could allow OpenCL also for Nvidia by disabling blocklist via env var, and then Turing/Ampere cards beat RDNA2 to death even without using RT cores. No idea what you want to blame the Blender project here for...

That's not the API fault. It was garbage compared to CUDA because all development went towards the CUDA API.