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

101–110 of 117 posts

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

#101

Post by AnthonyMouse »

touisteur wrote: post #58
AnthonyMouse wrote: post #38

Earlier quoted context omitted.

AMD's biggest problem right now is overcoming Nvidia's inertia for compute. This is the classic case where open standards happen. Everybody but the incumbent joins in, then all of them put together is a large enough target to attract developers. Then the open standard and the proprietary one coexist as long as any of the vendors implementing the open standard is competitive, but if the vendor with the proprietary sta…

But wasn't it already tried with OpenCL... And quite failed to just do that? For now, in parallel to efforts to reach parity to cuda or something, I'd rather have them optimize the mother out of the necessary libraries (tensor basic blocks, basically reaching cudnn/tensorrt-level, crazy limit-of-hardware BLAS stuff, and most of the API landscape)... 47tflops that I can't use because I have to reimplement and optimize…

OpenCL was created by Apple, then Apple abandoned it. AMD picked it up, but at the time AMD didn't have competitive hardware and therefore didn't have the resources to make it good, and Intel wasn't in the GPU game then. Now AMD has money and Intel has even more money and they could certainly produce a competitive solution together if they tried.

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

#102

Post by AnthonyMouse »

pjmlp wrote: post #49
roenxi wrote: post #46

Earlier quoted context omitted.

They may literally be the last holdout among the hardware manufacturers. 15 years ago nearly every vendor was the same. They've all caved over time - can't fight OSS forever.

Except they all end up going shareware like model where the FOSS alone is useless without the proprietary magic dust.

Are you trying to claim that e.g. the AMD open source drivers can't be usefully improved by the community?

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

#103

Post by Const-me »

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.

In my experience, on Windows, DirectCompute shaders work OK on AMD too. For optimal performance they require optimizations for specific GPUs, though.

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

#104

Post by touisteur »

AnthonyMouse wrote: post #101
touisteur wrote: post #58

Earlier quoted context omitted.

But wasn't it already tried with OpenCL... And quite failed to just do that? For now, in parallel to efforts to reach parity to cuda or something, I'd rather have them optimize the mother out of the necessary libraries (tensor basic blocks, basically reaching cudnn/tensorrt-level, crazy limit-of-hardware BLAS stuff, and most of the API landscape)... 47tflops that I can't use because I have to reimplement and optimize…

OpenCL was created by Apple, then Apple abandoned it. AMD picked it up, but at the time AMD didn't have competitive hardware and therefore didn't have the resources to make it good, and Intel wasn't in the GPU game then. Now AMD has money and Intel has even more money and they could certainly produce a competitive solution together if they tried.

Ah I didn't know that part of history, thanks. Let's hope they can find someplace to meet that won't fragment this space more... Not a big fan of the churn on the Intel universe these last years. Just one example but between mkldnn, dnnl, onednn... The dead github 'this project has been superseded by project x' links are quite discouraging. And I'm not sure of the future of openvino in the oneapi offering it's really a blur, but maybe I'm following close enough. And I'm just a dabbler/noob. Can't imagine the effect on someone just trying to maintain an app over the last 5-10 years...

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

#105

Post by chmod775 »

ur-whale wrote: post #90
chmod775 wrote: post #54

Earlier quoted context omitted.

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

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

It's under a permissive license (MIT). What makes you say it is "just a hack"? What makes it a hack?

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

The same is true for OpenCL (layer above a proprietary layer) and pretty much any API interfacing with proprietary hardware/drivers.

Also it's not even proprietary software in the first place, even if you're trying to make it sound that way.

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

#106

Post by floatboth »

gspr wrote: post #68
floatboth wrote: post #62

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.

Don't try to use it directly, you need a higher level library.

https://github.com/KomputeProject/kompute seems like what's taking off. There are also smaller ones like https://github.com/Glavnokoman/vuh etc.

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

#107

Post by shmerl »

my123 wrote: post #72
floatboth wrote: post #64

Earlier quoted context omitted.

Why would anyone want pointers on the GPU?

Among other things: C++ on the GPU, with lots of common code between the two worlds. It’s one of the core reasons why CUDA took off. You could adapt your code instead of a full rewrite, even mixing code within the same file. Types are checked at compile time too.

I'd take Rust over C++ for the GPU.

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

#108

Post by my123 »

shmerl wrote: post #107
my123 wrote: post #72

Earlier quoted context omitted.

Among other things: C++ on the GPU, with lots of common code between the two worlds. It’s one of the core reasons why CUDA took off. You could adapt your code instead of a full rewrite, even mixing code within the same file. Types are checked at compile time too.

I'd take Rust over C++ for the GPU.

I don’t see why you’d want that, but if you want to do it you can.

nvptx64-nvidia-cuda is a Tier 2 Rust target. (see https://doc.rust-lang.org/nightly/rustc/platform-support.htm...)

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

#109

Post by volta83 »

jeeceebees wrote: post #99
volta83 wrote: post #95

Earlier quoted context omitted.

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?

This paper ported a CFD application, which had a tuned CUDA implementation, to std::par: https://arxiv.org/pdf/2010.11751.pdf .

In Table 3, first and last columns shows the performance of CUDA and std::par in % of theoretical peak.

The rows show results for different GPU architectures.

On V100, CUDA achieves 62% theoretical peak and std::par 58%.

The amount of developer effort required to achieve over 50% theoretical peak with std::par makes it a no brainer IMO.

If there is one kernel where you need more performance, you can always implement that kernel in CUDA, but for 99% of the kernels in your program your time might be better spent elsewhere.

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

#110

Post by shmerl »

my123 wrote: post #108
shmerl wrote: post #107

Earlier quoted context omitted.

I'd take Rust over C++ for the GPU.

I don’t see why you’d want that, but if you want to do it you can. nvptx64-nvidia-cuda is a Tier 2 Rust target. (see https://doc.rust-lang.org/nightly/rustc/platform-support.htm... )

I'd ask why wouldn't you want that?

I think this is more promising: https://github.com/EmbarkStudios/rust-gpu

Post reply on HN