Blender 3.0 takes support for AMD GPUs to the next level
gpuopen.com
gpuopen.com
Also remember that AMD and Intel both make discrete GPUs and iGPUs but AMD has much more share in discrete GPUs and Intel has much more share in iGPUs, so this helps them both.
And then if either of them managed to hit one out of the park on the hardware side it would benefit both. A really interesting possibility there is to put a strong GPU in a HEDT CPU socket with a lot of memory channels to feed it, because then it shares a memory controller with the CPU and doesn't have to copy over PCIe. That could drive demand, and Nvidia can't do that on a PC without an x86 license but AMD and Intel both can.
If Intel were clever like a fox, they'd invest heavily in making oneAPI work well on both Nvidia and AMD platforms. As a new market entrant they have nothing to lose, but everything to gain by luring companies into a vendor agnostic solution.
They've already starting doing this to a degree, but only in partnership with some university. This should be one of their major KPIs, they've got plenty of cash laying about.
https://www.phoronix.com/scan.php?page=news_item&px=oneAPI-A...
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 standard stumbles in any way, developers abandon them.
Hardware vendors don't really need lock in. People buy your hardware again because you make it faster every year. And if your hardware stops being competitive then the lock in won't save you.
"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 much more developer grunt and a much more confident start, though they're a latecomer to GPUs.
Also their hardware is notoriously buggy. PCIe passthrough especially, google the PCI reset bug if you wanna know more. There is a project called vendor reset on github that reverse engineered the issues and works around them. The author is sure the issue can be fixed by a firmware update to those cards, but although initially AMD engineers showed interest, further attempts at coordinating proper fixes with them failed. Requests for documentation of affected cards were denied. Compare to Intel where you can freely download all the documentation about their GPUs, with registers, internal state, everything you'd need to write a driver from scratch. People want to fix AMD's shit for free but they don't want that.
We recently had calls with NVIDIA, AMD and Intel regarding their enterprise gpu offerings. NVIDIA and Intel were quick to respond and offer a meeting, AMD took forever. Followup questions, even very technical were answered within two days by Intel with concise to the point answers, no bullshit. With AMD they bounced around for two weeks until we got somewhat useful answers.
I really hate NVIDIA, it's a horrible, greedy company with a shitty attitude. I was excited about ryzen. I'm almost an AMD fan boy in the desktop space. I like competition, when the underdog rises from the ashes. But oh boy, AMD GPUs in the server/enterprise space a a clustersuck; buggy hardware, shitty drivers, clueless salesreps. You really have no choice but NVIDIA if you don't want to hire an expert working in getting these cards to work with anything more advanced than having them encode video in hardware or something.
We really hope Intel will deliver.
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...
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.
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?
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.
I had to repeat that lesson a few years later with deep learning code before it stuck.
Hopefully this time is different. I'm cautiously optimistic... but I'll let someone else be the guinea pig.
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)
Note that it’s temporary (as of today) because of bugs in Intel’s Metal graphics drivers. AMD GPUs are supported on TensorFlow/MLCompute.
This is not M1 only, just Intel GPUs are excluded.
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 steps. Switching to an NVIDIA card fixed it. Can't remember the last time a game crashed on me.
AMD's GPUs use significantly more power in their class. The RX 580 is a 185W TDP card. NVIDIA's 1060 is 120W and outperforms the RX 580. The 1070 is a 150W card and handily outperforms the 580. The 1070TI is still (slightly) under the RX580 (by 5W), and wipes the floor with it.
The 5xxx series cards were also garbage. AMD had nothing to respond to DLSS or RTX - and the RTX cards were a huge leap in compute performance in particular. The cards crashed like crazy because of driver problems, and people also discovered that all the "creators" with pre-release cards had been basing their performance tests off benchmark runs that lasted just long enough before the cards overheated. NVIDIA cards performed better if you planned on gaming for more than 5 minutes at a time.
You can't afford to buy one, but the equivalent Nvidia cards are no better. It's a terrible time to buy any GPU. The stupid old RX 580 costs more now than it did when it came out.
With the drivers sorted they aren’t significantly behind the 6000 (RDNA2) cards that superseded them. Maybe 5%, equivalent cards compared. Makes for a good deal in today’s market.
This says otherwise https://www.tomshardware.com/features/graphics-card-power-co... - it puts RX 6800 at the best performance per watt
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.
It is _enabled_ on 1st gen RDNA, but with no "official support" from AMD. (as such, no SLAs or any guarantees really)
On prior generations, it's not enabled at all. (Vega, Polaris)
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.
The RX 6000 series will have been out for a year tomorrow. I was able to grab one within a week after the release just by checking online stores a couple of times each day so while they did keep going out of stock, there was new stock coming in too.
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.
I tend to suspect that NVidia just invests far more in software than their competition. Hopefully now that AMD has money that will change.
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).
> 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.
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?
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.
So, that's it, OpenCL is out the door, no more standardized way to write GPU compute code, I guess.
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.
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.
I hate compute-specific APIs so much. Use Vulkan!
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?
https://github.com/KomputeProject/kompute seems like what's taking off. There are also smaller ones like https://github.com/Glavnokoman/vuh etc.
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.
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 limitations in how you can write kernels, in practice you can’t currently use pointers for example. But also, GPU vendors will recommend certain platforms for writing production renderers, provide support around that, and various renderers will use it. Choosing a different platform means you will hit more bugs and limitations, have slower or no access to certain features, are not likely to see library support like OSL, etc.
Our strategy for Cycles X is to rely on the GPU vendors to support us and provide APIs that meet our requirements. We want to support as many GPUs as possible, but not at any cost.
If an open source project of this scope came to me for advice, I would absolutely 100% recommend they base their stuff on Vulkan. It's getting very good quite quickly; there's basically nothing holding you back any more if you're willing to use the latest extensions. There is a tendency in open source to move more slowly though, and I understand that.
I agree with you that GLSL/HLSL is a bad programming language, but you can still get your work done in it. I'm personally excited about rust-gpu, but that is not ready yet.
[1]: https://www.khronos.org/registry/vulkan/specs/1.2-extensions...
[2]: https://community.arm.com/arm-community-blogs/b/graphics-gam...
I also expect the language support and tooling to get a lot better. The fact that it's based on SPIR-V means it doesn't lock you into any one language, it's possible to develop good tools that run on top of it. That's happening to a large extent in the machine learning space with IREE, much less so here though.
I should also say, I'm not disagreeing with the strategy Blender has chosen, specifically getting vendors to support tuned ports to their hardware. I'm just saying that these specific criticisms of Vulkan (like lacking pointers) aren't really valid.
Language support and tooling are never better than the alternatives.
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 _does_ support them. However, AMD[3] and NVIDIA do not implement SPIR-V in their OpenCL drivers.
[3] it’s a trainwreck, they supported the original SPIR but then https://community.amd.com/t5/opencl/spir-support-in-new-driv... happened. It never came back since then.
Migrating back down to GLSL/HLSL from that makes absolutely no sense. The options above, using C++ as a device language, allow much more code sharing with a CPU backend.
Portability is also a good story, the adaptation is mostly in the glue layer, if your GPU vendor is _not_ AMD and has a proper software stack.
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.
However, MS failed to capitalise on it and bailed out (too early). Has been limping along dead since years, finally acknowledged as deprecated in VS2022.
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.
nvptx64-nvidia-cuda is a Tier 2 Rust target. (see https://doc.rust-lang.org/nightly/rustc/platform-support.htm...)
I think this is more promising: https://github.com/EmbarkStudios/rust-gpu
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 would you ever need to point to something that you’ve drawn in 3D?”
>Of course, HP claims X has a mode which allows you to run X in the overlay planes and “see through” to the graphics planes underneath. But of course, after 3 months of calls to HP technical support, we agreed that that doesn’t actually work with my particular hardware configuration. You see, I have the top-of-the-line Turbo SRX model (not one, but two on a single workstation!), and they’ve only tested it on the simpler, less advanced configurations. When you’ve got a hip, forward-thinking software innovator like Hewlett-Packard, they think running X windows release 2 is pretty advanced.
What does Brecht Van Lommel know about writing 3D graphics code and GPU kernels, anyway?
https://www.blenderdiplom.com/en/interviews/400-interview-br...
https://devtalk.blender.org/t/2021-08-31-blender-rendering-m...
So the hip, forward-thinking HP technical support person was right after all, decades ago! Makes me wonder why they're not still in business. Such nice hardware! Too bad about the software.
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.
Probably meant Embree
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.
1. What will the impact be for ROCm's Navi support on Linux?
2. Does this mean they're getting more confident at handling simultaneous display AND compute with ROCm?
You will see that supported officially in ROCm 5.0, the next ROCm release. Note that ROCm 5.0 drops support for first generation Vega GPUs. (Radeon Instinct MI25)
The only consumer card to have shipped with second gen Vega is the Radeon VII.
Official Navi support (5000-series cards), however, is expected in a later release. In current releases, I think the only ROCm library shipping unofficial support is rocBLAS.
(I work for AMD on ROCm. All opinions are my own.)
Furthermore we're focusing our efforts on ProRender going forward through USD. https://github.com/GPUOpen-LibrariesAndSDKs/BlenderUSDHydraA... Adding USD workflows to blender and other apps while using ProRender for the rendering solution in USD.
Let's see if AMD takes over the GPU top list.
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 comprehend video tutorials when they're pressing keyboard shortcuts at 20k wpm without explaining them and scouring over every detail trying to understand what they're doing turning an hour long tutorial into a day of confusion
I made a shitty donut and don't even know how I did, that's it
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.
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.
So far Blender is not. I'm impressed.
If AMD will succeeds, at the very least there will be a long period where they will undercut prices in order to gain market share.