Live data from Hacker News

Blender 3.0 takes support for AMD GPUs to the next level

gpuopen.com

91–100 of 117 posts

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

#91
post #68

Earlier quoted context omitted.

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.

> I find the documentation quite fractured.

This has been my experience as well: the few Vulkan Hello, World I've seen all have a mile and half boilerplate code before you can open a window and draw an effing pixel in it.

Also, from an admittedly quick glance at Vulkan ... I haven't really seen specs for a full-fledged CUDA / OpenCL modern replacement.

Did I miss something?

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

#92
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…

just playing devils advocate here, but if only one vendor is conforming to these standards - could it be that the standards are heavily biased towards their implementation?

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

#93
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…

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

Absolutely false. First, GPU code is inherently unportable in terms of performance. Switch to another vendor's GPU, or to another microarchitecture, and you may need to rewrite your entire kernel.

But even other than that: NVIDIA promotes its own proprietary and mostly-closed-source ecosystem, named CUDA, and has actively hampered the adoption and development of OpenCL, which was supposed to be the open standard. Not that OpenCL was not "betrayed" by others, but still.

> They voted GPU support into the C++ 2017 and Fortran 2018 ISO standards

There is no GPU support in the C++ standard. If you mean something like `std::par` as an execution strategy for standard library algorithm, that's rather limited in scope and not really GPU-specific.

> While NVIDIA implemented this YEARS ago

Again not quite sure what you mean. Are you talking about how you can't write GPU kernels in C++17? Or about `std::par` implementations for the standard libraries?

> 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.

This doesn't make sense, and it's also not true. On a GPU, you would not use a lot of the standard library to get things done; that would either be exceedingly slow or just not work. Also, some language features (like exceptions) don't work on GPUs, and for good reason; hence anything in the standard library which relies on exceptions for error handling also doesn't work as-is - which is perfectly ok.

> You can also take your normal Python NumPy code and run it on NVIDIA GPUs "as is" without changes.

This is the only part of what you've written which is mostly-true (and I haven't fully verified even this since I don't do Python work).

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

#94
post #92
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…

just playing devils advocate here, but if only one vendor is conforming to these standards - could it be that the standards are heavily biased towards their implementation?

Intel and AMD voted to add GPU support to the C++ and Fortran ISO standards.

Are you implying that they did a bad job and added the wrong GPU support to ISO C++?

Or maybe that Intel and AMD don't care about C++, and either added GPU support to it that they could not implement, or don't care about adding C++ support to their GPUs?

Playing devil's advocate here, no matter how you want to frame this, it just does not look good for Intel and AMD.

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

#95
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…

> If you care about portable GPU code, unfortunately, NVIDIA is the only vendor that actually delivers. Absolutely false. First, GPU code is inherently unportable in terms of performance. Switch to another vendor's GPU, or to another microarchitecture, and you may need to rewrite your entire kernel. But even other than that: NVIDIA promotes its own proprietary and mostly-closed-source ecosystem, named CUDA, and has a…

TL;DR: the parent doesn't know what they are talking about and for some reason is burnt over OpenCL which is a horrible ""standard"" (Khronos extension over C and C++, not actual C++ support, in the C++ ISO standard proper). Maybe the reason people like HIP and OneAPI is because they are not aware that you can program GPUs using ISO C++ and ISO Fortran because... Intel and AMD don't support those?

> Absolutely false. [...] If you mean something like `std::par` [...] not really GPU-specific

std::par is the ISO C++ standard feature for parallel programming, this includes multi-core CPUs, SIMD, GPUs, FPGAs, etc.

NVIDIA compilers run std::par on both CPUs and GPUs.

I've been using it for over a year, and so have a lot of people I work with.

You claim that this is false, but this is demonstrably true, and there are many peer-reviewed papers of people using this with NVIDIA compilers already.

The claim that this model of GPU programming is not portable, is false as well, since Intel and AMD claimed that this is portable to their GPUs when they added it to the C++ standard in 2017.

The claim that this does not deliver performance portability is also false, since we have verified performance portability across 3 NVIDIA GPU architectures, and using Kokkos, which exposes a similar programming model, also to Intel and AMD architectures.

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

#96

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…

Is it a 'green tax' when NVIDIA's product is superior in almost every way? There's only two negatives to NVIDIA products right now: poor MacOS support and their linux drivers aren't quite as good as AMD's. Everything compute uses NVIDIA/OptiX. AMD's Windows drivers suck. I had no end of problems with games crashing and micro-stuttering. I used DDU to remove the old drivers, ran Tron, all sorts of troubleshooting step…

If anyone is reading this and wondering, I've run a Radeon RX 5600 XT for about 16 months with no issues at all. Fan noise is super well controlled (Sapphire Pulse three fan model.) Power draw was generally below 115 W. (Performance is roughly comparable to a GeForce RTX 2060.)

More recently, I upgraded to a 6700 XT. Rock solid stable, excellent performance, great cooling. Haven't really watched power draw closely, but I think it might be closer to 130-150 W. I'll try to remember to check this when I play games after work today. But if you care, you'll go read reviews anyway! (Performance is roughly comparable to a GeForce RTX 3070.)

Both were/are powered by a 13 year old Corsair 620W power supply. Almost all my gaming is done at 1440p.

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

#97

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.

They constantly make small changes to the UI to improve it. These are good-faith changes aimed at making things clearer, easier to use, and more consistent overall.

Since I use blender a lot I can absorb these changes easily. If you're not using it very often it might be harder. However, I'd contest the idea that the "UI changes every month" since there are usually only two or three releases a year.

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

#98
post #92
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…

just playing devils advocate here, but if only one vendor is conforming to these standards - could it be that the standards are heavily biased towards their implementation?

If it was just that I'd expect catch-up to happen within a couple years and a generation of cards, but the problem has persisted for many years and many generations of cards.

I tend to suspect that NVidia just invests far more in software than their competition. Hopefully now that AMD has money that will change.

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

#99
post #95

Earlier quoted context omitted.

> If you care about portable GPU code, unfortunately, NVIDIA is the only vendor that actually delivers. Absolutely false. First, GPU code is inherently unportable in terms of performance. Switch to another vendor's GPU, or to another microarchitecture, and you may need to rewrite your entire kernel. But even other than that: NVIDIA promotes its own proprietary and mostly-closed-source ecosystem, named CUDA, and has a…

TL;DR: the parent doesn't know what they are talking about and for some reason is burnt over OpenCL which is a horrible ""standard"" (Khronos extension over C and C++, not actual C++ support, in the C++ ISO standard proper). Maybe the reason people like HIP and OneAPI is because they are not aware that you can program GPUs using ISO C++ and ISO Fortran because... Intel and AMD don't support those? > Absolutely false.…

How does the performance between GPU programs written with std::par compare to those written in CUDA?

Do you happen to know of any online resources that show a comparison of the kernel code and performance of the two frameworks on common tasks?

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

#100

> 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.

Have you heard of SYCL[1]? :)

[1]: https://www.khronos.org/sycl/

Post reply on HN