Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blender 3.0 takes support for AMD GPUs to the next level

gpuopen.com

Post reply on HN
Print view View original

61–70 of 117 posts

Re: Blender 3.0 takes support for AMD GPUs to the next level

#61

Post by theHIDninja »

hrnnnnnn wrote: post #60
theHIDninja wrote: post #53

I cannot understand Blender's inanely arcane interface Every tutorial out there seems to be for a drastically different version where half the shit no longer works in the current one without delving into more and more hidden menus Every feature is its own labyrinth of menus, every model downloaded seems to be customized to a unique version with nothing similar to another It is massively disheartening to try to compre…

It's a powerful tool and it takes time and effort to learn. I was in the same boat as you when I started, but after ~3 years of using Blender more or less daily I find the UI very intuitive and powerful. One of the nice things about having a very active community is that there's always new tutorials being made, often at the beginner level, on the very latest versions.

Not a single thing about it is intuitive if its UI changes every month.

Re: Blender 3.0 takes support for AMD GPUs to the next level

#62

Post by floatboth »

ur-whale wrote: post #41

> This removed OpenCL™ support for rendering on AMD GPUs for technical and performance reasons. So, that's it, OpenCL is out the door, no more standardized way to write GPU compute code, I guess.

Vulkan! Compute! Shaders!

I hate compute-specific APIs so much. Use Vulkan!

Re: Blender 3.0 takes support for AMD GPUs to the next level

#63

Post by pjmlp »

my123 wrote: post #56
pjmlp wrote: post #50

Earlier quoted context omitted.

If I have learned anything from Khronos APIs is that if Internet was a Khronos standard instead of IETF, we would only have IP as standard, while everyone else had to come up with TCP, UDP, HTTP,... as extensions. Language support and tooling are never better than the alternatives.

Blender decided to support just the platforms which have a C++ target device language. This encompasses CUDA, Metal[1] (one of the reasons why it’s much more usable than Vulkan), ROCm HIP, and oneAPI[2]. [1] Metal’s Shading Language is C++14 with a handful of limitations, the biggest one is no lambdas [2] Vulkan uses a restricted SPIR-V dialect without pointers notably. OpenCL and oneAPI use a separate one which _doe…

Indeed, and a reason why Khronos only adopted SPIR-V and is now slowly embracing C++.

They took a hard beating from proprietary APIs that have long moved away from "C is the best" approach, and now they are playing catch-up with the rest of the world cozy in their mature C++ tooling for the GPGPU.

Re: Blender 3.0 takes support for AMD GPUs to the next level

#64

Post by floatboth »

my123 wrote: post #14
shmerl wrote: post #10

Why HIP and not for example Vulkan? UPDATE: Looks like this more about adapting existing CUDA code to work with AMD. So it makes sense as the least resistance approach I suppose.

> Looks like this more about adapt existing CUDA code to work with AMD. So it makes sense as the least resistance approach I suppose. It isn't about that. Vulkan isn't flexible enough to allow it to happen. Give true pointers support in Vulkan for example first. GLSL/HLSL is much worse than modern C++ as a programming language too. As described by Brecht Van Lommel (Blender and Cycles developer): Vulkan has limitatio…

Why would anyone want pointers on the GPU?

Re: Blender 3.0 takes support for AMD GPUs to the next level

#65

Post by floatboth »

KennyBlanken wrote: post #26
blihp wrote: post #17

Earlier quoted context omitted.

Not really on the compute side yet. This is their 2nd attempt at supporting Blender as the first (an OpenCL renderer for Blender) was deemed unmaintainable and deprecated shortly after it was released. All indications are AMD is doing much better on the video driver side (which is where the good news is), but on the compute side they appear to have a long way to go still.

AMD may be doing better on the open source video driver side but their Windows drivers have been a mess for half a decade.

How?? I've had zero problems with the Windows driver in the last 5 years or so.

Re: Blender 3.0 takes support for AMD GPUs to the next level

#66

Post by MrLeap »

floatboth wrote: post #64
my123 wrote: post #14

Earlier quoted context omitted.

> Looks like this more about adapt existing CUDA code to work with AMD. So it makes sense as the least resistance approach I suppose. It isn't about that. Vulkan isn't flexible enough to allow it to happen. Give true pointers support in Vulkan for example first. GLSL/HLSL is much worse than modern C++ as a programming language too. As described by Brecht Van Lommel (Blender and Cycles developer): Vulkan has limitatio…

Why would anyone want pointers on the GPU?

It would be nice if I could use function pointers in hlsl. It would let me pass a pointers to distance functions around. Doing anything complicated with signed distance fields is a bit hairbrained without them.

Re: Blender 3.0 takes support for AMD GPUs to the next level

#67

Post by tim-- »

iforgotpassword wrote: post #55
roenxi wrote: post #45

Earlier quoted context omitted.

Are ROCm and HIP considered any good? I've long since given up trying to figure out what ROCm is and what "installing it" means but I suppose it might be time for another attempt. I see PyTorch supports it now.

I don't. Imo it's still a clusterduck. Issues with modern kernels. Pull requests by volunteers that fix these issues go ignored for months. Like GP said, before the ryzen launch I could see why software is in such a bad state, but today there is no excuse for being that understaffed. Also their hardware is notoriously buggy. PCIe passthrough especially, google the PCI reset bug if you wanna know more. There is a proj…

To be fair, many of the newer cards don't have any reset issues, and work perfectly fine with pass thru.

The new AMD graphics cards have drivers that ship as part of the Linux driver, and work perfectly fine. Better than Nvidia under a number of circumstances (where is Nvidia with Wayland support?)

Hopefully rocm 5 will bring support for RDNA 2 cards, but I said that about rocm 4 too.

https://github.com/RadeonOpenCompute/ROCm/issues/1180#issuec...

6000-series cards work under WSL with Windows using DirectML, so it can't be too far away.

https://docs.microsoft.com/en-us/windows/ai/directml/gpu-ten...

Re: Blender 3.0 takes support for AMD GPUs to the next level

#68

Post by gspr »

floatboth wrote: post #62
ur-whale wrote: post #41

> This removed OpenCL™ support for rendering on AMD GPUs for technical and performance reasons. So, that's it, OpenCL is out the door, no more standardized way to write GPU compute code, I guess.

Vulkan! Compute! Shaders! I hate compute-specific APIs so much. Use Vulkan!

Could you provide some pointers to where someone who's moderately familar with OpenCL should start looking to learn to do compute with Vulkan? I find the documentation quite fractured.

Re: Blender 3.0 takes support for AMD GPUs to the next level

#69

Post by tambre »

tim-- wrote: post #67
iforgotpassword wrote: post #55

Earlier quoted context omitted.

I don't. Imo it's still a clusterduck. Issues with modern kernels. Pull requests by volunteers that fix these issues go ignored for months. Like GP said, before the ryzen launch I could see why software is in such a bad state, but today there is no excuse for being that understaffed. Also their hardware is notoriously buggy. PCIe passthrough especially, google the PCI reset bug if you wanna know more. There is a proj…

To be fair, many of the newer cards don't have any reset issues, and work perfectly fine with pass thru. The new AMD graphics cards have drivers that ship as part of the Linux driver, and work perfectly fine. Better than Nvidia under a number of circumstances (where is Nvidia with Wayland support?) Hopefully rocm 5 will bring support for RDNA 2 cards, but I said that about rocm 4 too. https://github.com/RadeonOpenCom…

> where is Nvidia with Wayland support?

They released drivers at the end of October that support GBM. Since XWayland 21.1.3 hardware acceleration for X should work too. I haven't tried myself though, since Nouveau is enough for my basic desktop usage.

Re: Blender 3.0 takes support for AMD GPUs to the next level

#70

Post by techdragon »

tomovo wrote: post #47
philovivero wrote: post #27

Earlier quoted context omitted.

I wish I could be that guinea pig, but looks like this is a Windows-only thing, and I'm on a Mac.

Apple is contributing Metal support so there’s another chance.

Only because the move to their own customised ARM based unified memory architecture means that if they don’t want to completely hemorrhage the remaining loyal customers in the pro market paying for their hardware they have to support at least basic hardware acceleration in these apps.

So don’t expect support on anything but the latest hardware. Like their new Metal based Machine learning library junk. Oh whats that you have an Intel Mac with a beefy external GPU supported by Metal… too bad this is M1 only! Doesn’t matter that we supported this in the beta, we’re throwing out everything Intel related because the future is ARM and we no longer care about anything outside our garden.

I say all of this grumpily, as a progressively less and less happy Apple customer. Unless a glorious future of high performance x86 emulation of Virtual machines happens I’m forced to get cheaper hardware and buy a second laptop now in order to support GPU heavy windows software (Linux at least looks set to get some measure of support so hopefully it’s not all dire, but it’s still a massive down side for me in the otherwise amazing looking ARM hardware)

Post reply on HN