It's good that AMD is providing support for some of their customers since OpenCL is being removed in 3.0. I hope that this is just the start of far greater investment into their software ecosystem. It was understandable that AMD invested less in drivers and support software when they were almost bankrupt but that excuse is drying up. There are rumors that future AMD GPU architectures will be quite good and it would be a shame for that advantage to be wasted by a lack of software support.
They should really get together with Intel on an open standard, now that Intel is doing real GPUs. They both have a shared interest in people not being stuck on proprietary Nvidia interfaces.
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 much more developer grunt and a much more confident start, though they're a latecomer to GPUs.
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 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.
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.
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.
> 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?
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 don't see it happening. AMD like Nvidia want to keep their big corporate clients locked into their ecosystem.
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.
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 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.
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 the basics isn't that interesting, except for supercompute.
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...
The only hope for opensource only if NVIDIA as a company ceases to exist - go bankrupt, for example. They are inherently hostile to FOSS and will never change (they didn't change in last decades, why they would in the future).
AMD and Intel benefit from having the same open source interface to their GPUs even if Nvidia doesn't use it, because it doubles the amount of target hardware for developers.
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.
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.
AMD didn't have the money to spend on software as much as Nvidia and intel were able to now that they do they seem to be investing heavily into software. Xilinx acquisition should also help with that.
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 time is different. I'm cautiously optimistic... but I'll let someone else be the guinea pig.
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)
> 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
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.
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 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.
The RX 580 is four years old. The RX 5xxx series is two years old. The current series is RX 6xxx and has competitive performance per watt.
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.
The overheating and crashing issues are fixed; I’m running a W5700 completely stable.
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.
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.
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.
> 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).
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.
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.
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.
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.
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 :)
Can we please let go of that meme - GPUs prices are currently high due to the chip shortage and mining demand, yes, but definitely not too high for professional users to afford them. It sucks if you want an entertainment device and are on a budget but let's not pretend that these cards are unavailable entirely.
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.
> 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 that the tools with HIP allow easy migration from existing CUDA® code to something more generic.
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.
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.
AMD software support is pretty bad for a company of its size. They’re trying to do the minimum. It’s almost as if they don’t want to compete with Nvidia due to collusion.
> 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 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.
This doesn't sound right to me. Vulkan 1.2 has support for pointers through an extension[1], and that's getting more widely available (certainly a lot more cards than can run ROCm). There's also support coming down the pike for buffer device address[2], which basically lets you use pointers to refer to resources when submitting work to the GPU instead of having to create bindings.
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.
> Pointers are an abstract type - they have no known compile-time size. Using a pointer type as the argument to the sizeof() operator will result in an undefined value.
> Pointer-to-integer casts must not be used.
> Integer-to-pointer casts must not be used.
> Pointers must not be compared for equality or inequality
The first one in that list is a quite big limitation, affecting a significant number of scenarios…
(And yes, you cannot actually make a compliant OpenCL 1.2 implementation on top of Vulkan, Vulkan has too few features for that purpose)
Thanks for the detailed explanation, that makes sense and is useful information. My understanding was that they were more like real pointers, but I see that is not the case.
You'd recommend Vulkan Compute over "CUDA" though for a path tracer? (I don't assume Cycles has any hybrid rendering in it, so there isn't much value in the traditional pipeline)
So it depends a lot on the goals. CUDA is a very good developer experience, and Vulkan compute shaders is (at the moment) a very bad one. But if the goal is to ship real compute on a wide variety of devices, Vulkan is pretty close to the only game in town.
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.
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 _does_ support them. However, AMD[3] and NVIDIA do not implement SPIR-V in their OpenCL drivers.
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.
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.
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.
>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.
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.
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.
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.
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.
I don't think that was an option. Kernel size limitations prevented Blender from ever supporting OpenCL well. Not to mention Apple dropping official support for it years ago.
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.
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.
I wouldn't go that far. Nvidia and even Intel have had hardware-accelerated features in Blender (RTX-acceleration and Optix, respectively), so this is more about getting them back on the same level. I do really like AMD GPUs though, I'd be interested to see how this performs on their APUs with the Vega graphics.
According to other posts, this won’t support Vega graphics; RDNA1 is the absolute minimum, with RDNA2 being the oldest architecture officially supported. Guess we’ll have to wait for new APUs to see how this fares.
> 1. What will the impact be for ROCm's Navi support on Linux?
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.
All future plans are subject to change, but official Navi21 support is expected in ROCm 5.0. It's been shipping unofficially since ROCm 4.2.
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.)
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 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
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.
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!
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.
