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

81–90 of 117 posts

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

#81

Post by my123 »

WithinReason wrote: post #77
DonHopkins wrote: post #73

Earlier quoted context omitted.

That reminds me of the line from the HP technical support person from the "X-Windows Disaster" chapter of the "Unix-Haters" handbook: https://donhopkins.medium.com/the-x-windows-disaster-128d398... >My super 3D graphics, then, runs only on /dev/crt1, and X windows runs only on /dev/crt0. Of course, this means I cannot move my mouse over to the 3d graphics display, but as the HP technical support person said “Why woul…

Except in this case the question makes sense, you don't have malloc on the GPU (it only allocates from a fixed array), and without dynamic memory allocation you could just use indices to an array any time you would use a pointer on the CPU. This also makes sense if you transfer your datastructure between GPU and CPU, since you don't need to translate pointers.

You share the same pointers between CPU and GPU. Pointers in structures for example are one of the use cases.

Also as an even more unique option, see cudaHostRegister (on CUDA) to make a CPU buffer not allocated through CUDA accessible from the GPU without a copy, at the same address[1]. This isn’t especially high performance because you have to go through the PCIe bus (on Tegra, this mechanism is even more attractive), it’s however very useful.

Your address space is unified between CPU and GPU, with the same pointers used between both.

[1] at the same address for host allocations registered through that mechanism is only there on recent GPUs. Allocations done through CUDA still share the same address on both worlds on GPUs where this is unsupported.

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

#82

Post by bavell »

theHIDninja wrote: post #61
hrnnnnnn wrote: post #60

Earlier quoted context omitted.

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.

Sounds like blender might not be for you. Personally I'm super happy with the new UI they revamped a year or so ago in 2.8 (which has barely changed since then). Plus there are tons of great YT videos at all skill levels for inspiration and help. Geometry nodes has been incredible for procedural modeling and I love the direction they're going with it!

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

#83

Post by moffkalast »

jjoonathan wrote: post #9

Glad to hear it. We're going on 10 years since Blender notionally got OpenCL support, I bought an AMD GPU on that basis, found out that the "OpenCL support" was so thoroughly dismal that it was slower than my CPU, sold my AMD card, ate the ebay fees, bought an NVidia card, ate the green tax, and got on with my work. I had to repeat that lesson a few years later with deep learning code before it stuck. Hopefully this…

This is mostly why I've stopped buying anything but Nvidia GPUs years ago, in 99% of software people just support CUDA and call it a day it seems.

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

#84

Post by incrudible »

roenxi wrote: post #45
mastax wrote: post #43

Earlier quoted context omitted.

Well ROCm and HIP are "open" and run on AMD and Nvidia GPUs. I'm sure AMD would've been happy for Intel to build on that. But they didn't. "oneAPI is a cross-industry, open, standards-based unified programming model..." I'm sure they'd be happy for AMD to build on that. But they won't. I think they'll both push their own APIs as the portable standard, but they can't rely on their competitors to contribute. Intel has…

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.

> Are ROCm and HIP considered any good?

I don't even care - yet. AMD hardware support has been criminal. Maybe in a few years we can talk about a parole hearing, then another year of probation, then we can talk about reintegration into society.

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

#85

Post by volta83 »

NVIDIA, Intel and AMD sit on the ISO C++ and ISO Fortran standard committees. They voted GPU support into the C++ 2017 and Fortran 2018 ISO standards. While NVIDIA implemented this YEARS ago, almost 5 years after these ISO standards were voted in, Intel and AMD have not even announced a plan for implementing GPU support for ISO standard languages on their GPUs.

Instead, Intel and AMD strategy is pushing applications to "rewrite CUDA with HIP/OneAPI", which are not real standards and are no more portable than CUDA. The people claiming that they are "open", probably also think that OpenACC is an open standard, even though it mostly only runs on NVIDIA GPUs.

If you care about portable GPU code, unfortunately, NVIDIA is the only vendor that actually delivers.

You can take your standard conforming C++ code _today_, not a single line of CUDA, OpenMP, OpenACC, etc. and the nvidia compiler compiles it and runs it on GPUs and multi-core CPUs. You can also take your normal Python NumPy code and run it on NVIDIA GPUs "as is" without changes.

It doesn't get any more portable than that.

I don't understand how there are so many people in these threads that apparently care about portability happy about AMD and Intel rewriting open source applications in their proprietary vendor-specific technologies, instead of angry about them pushing their proprietary technologies, instead of implementing GPU support for ISO standard languages, just like NVIDIA does.

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

#86

Post by incrudible »

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…

> I really hate NVIDIA, it's a horrible, greedy company with a shitty attitude.

NVIDIA is honest about what they are, whereas AMD brands itself as the puppy underdog that supports "open platforms" in order to sell you a product that doesn't work, but that you can "fix yourself". How's that for attitude?

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

#88

Post by nspattak »

volta83 wrote: post #85

NVIDIA, Intel and AMD sit on the ISO C++ and ISO Fortran standard committees. They voted GPU support into the C++ 2017 and Fortran 2018 ISO standards. While NVIDIA implemented this YEARS ago, almost 5 years after these ISO standards were voted in, Intel and AMD have not even announced a plan for implementing GPU support for ISO standard languages on their GPUs. Instead, Intel and AMD strategy is pushing applications…

On top of that, the only supported cards are radeon rx 6x00, as if the 10 miners who own these cards around the world even care about writing GPGPU code :)

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

#89

Post by washadjeffmad »

floatboth wrote: post #65
KennyBlanken wrote: post #26

Earlier quoted context omitted.

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.

They likely mean the GUI settings interface that competes with the GeForce Control Panel, not the driver itself.

I sometimes pass a W3100 through to a Windows VM so I only know the Radeon Pro interface, but I do feel like its designer's last project may have been building an AOL prog in Flash.

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

#90

Post by ur-whale »

chmod775 wrote: post #54
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.

> Luckily, AMD has an open-source solution for developers just for that. HIP (Heterogeneous-computing Interface for Portability) is a C++ runtime API and kernel language that allows developers to create portable applications for AMD and NVIDIA® GPUs from a single source code. This allows the Blender Cycles developers to write one set of rendering kernels and run them across multiple devices. The other advantage is th…

Yeah, I've read that.

But this is not an open standard, it's just a hack, and it is under the control of a vendor.

Worse, it is nothing but a thin layer above an even more proprietary layer.

Post reply on HN