Blender 3.6 LTS Released
blender.org
blender.org
> Support for hardware ray-tracing acceleration has been added for AMD and Intel graphics cards.
Added experimental support for AMD hardware ray-tracing acceleration, using HIP RT. This improves performance on RX 6000, RX 7000, W6000, and W7000 series GPUs.
Known limitations:
Windows only, as HIP RT doesn’t support Linux yet.
Degenerate triangles may causes crashes or poor performance.
Shadows in hair are not rendering accurately.
> Windows only, as HIP RT doesn’t support Linux yet
Blender 3 taking so much time to give AMD Linux users hardware acceleration back makes me sad. I guess it's not misguided though, they got a lot of attention from the industry in recent years, and that's where funding comes from, so naturally they will focus on supporting the major use cases (i.e. Windows and Nvidia) and improving features. Though I do love the new and improved features, UV packing, for instance, was a longtime pet peeve of mine while using Blender compared to other (closed-source) modeling packages.
Blender is super good and I love it and support it via plugin contributing. I keep my fingers crossed :)
There's no reason to stick with Blender 2.8.
AMD ran a YouTube ad that claims it's a 30% performance improvement on RX 7000 series: https://youtube.com/shorts/BKzty6YdRNM
Of course it depends on the exact scenario, but in games it's already known AMD ray tracing performance is quite bad compared to Nvidia and Intel, so it's not surprising they're also slow in Blender.
The newer versions of Blender only support CUDA and HIP as render devices, whereas in Blender 2.83 we still had the option to use OpenCL for rendering. You could say the blame is on AMD for giving subpar HIP support on Linux, and that would be fair IF the OpenCL backend didn't exist in Blender 2.83.
Of course, to add insult to injury, they now don't port the RT acceleration to Linux, which just makes the experience truly inferior to Windows. As I pointed out in the original comment, this is a reasonable decision from a business standpoint. I just find it sad because Blender is one of the darlings of the open-source movement, so seeing them neglect Linux so much is frustrating.
The video and compute drivers were merged some time around the ROCm 5.0 release last year. If you have a sufficiently recent kernel, you shouldn't need to install any additional drivers.
On Debian Bookworm or Ubuntu 23.04, you can `apt install libamdhip64-dev` and you'll have everything needed to use Blender's HIP GPU rendering.
For blender you will also need rocm-hip-devel, since blender dlopens() libamdhip64 not by soname (libamdhip64.so.5), but by the name libamdhip64.so, and that symlink is in the devel package.
For what I can say, it does work with Vega64 and cycles is rougly twice as fast compared to cpu (ryzen 2920x in my case).
I briefly talked to the Fedora maintainer and they mentioned there was a known issue with their HIP package. I'd encourage you to file a bug report with Fedora (if one does not exist already). Their packages are under active development and I think you can expect the matter to be resolved promptly.
I believe the issue comes from AMD which disable/doesn't support their GPGPU libraries on Linux and Blender cannot do much about it. GPGPU support in general is much much better on NVIDIA thanks to CUDA, both for Windows and Linux.
In my experience nvidia has better Linux support. Just look at how many projects are using Linux and cuda and don't support AMD.
AMD's issues are more general and not really a particular problem with their Linux support: they're spotty in general (bad drivers on card release, spotty OS support a la no ROCm on Windows.) In practice it obviously matters if you still can't get the features you need, but in my experience trying to run a modern Linux desktop setup with NVIDIA cards is absolutely second-class at this point. I tried my hand at it with a 2060 and the card was out of the machine in a month so I could have a stable desktop that actually resumed from sleep properly again.
Granted, issues like that are very much case-by-case. Still; I can't even run SwayWM with NVIDIA as I do with AMD and Intel; even with patches to "fix" the flickering issues, XWayland stuff is broken. This makes no sense of course. It shouldn't need to be a snowflake case.
How do you know this is an NVIDIA issue, as opposed to a Wayland or wlroots issue?
This issue isn't new either. In fact, until very recently, it was significantly worse. But progress on NVIDIA's end has been slow, it seemingly gets completely stalled for years at a time.
On the other hand, Nouveau works quite well with Wayland compositors if your card is well-supported, AND you never have to wait on a kernel upgrade because NVIDIA's shim hasn't been updated yet.
There's basically exactly one driver that works this way. It's not a hardware problem, it's not a general GPU issue. There's just one thing it could be.
Previous machine with Nvidia GPU (on Xorg) couldn't resume and had atrocious performances because of overheating.
Also, xserver used to work with nvidia cards due to goddamn proprietary binary patching done by drivers.
>Maintainer of sway and wlroots here. The Nvidia proprietary driver does not support sway, not the other way around.
>Their standard, EGLStreams, is only implemented by their proprietary drivers, so in order to test that codepath we'd have to use a famously broken and undebuggable driver, which we're not interested in - and make no mistake, we get our hands dirty in the drivers all the time. Their standard also has serious technical problems - lots of really important features simply are not possible to implement based on the proprietary driver. We can't export buffers to clients, overlay planes don't work, buffer presentation timings are impossible... Supporting this driver would be a massive overhaul and would probably make the good drivers worse.
That said, in practice I expect this to suck. There's probably a lot of stuff in the Linux desktop stack that does not deal with heterogeneous graphics cards well right now.
Just for reference, what setup are you using? (Linux kernel, drivers, GPU, etc.)
https://developer.nvidia.com/blog/nvidia-releases-open-sourc...
From the repo readme[1], "GeForce and Workstation support is still considered alpha-quality."
Hopefully now that AMD has money they can afford the headcount to fix their bugs and some more headcount to make up for 15 years of lost time in the applications that matter. Hopefully. But I trusted them twice and got burned, so this time I need to see proof before I jump. I need to see blender renders, I need to see torch trainings, I need to see NAMD (or insert science code here) running on a compatibility layer. It is unfortunate that the actual compatibility situation seems to have hardly moved at all in 10 years (it was right around the corner in 2013 too, you see) but the fundamentals are different now so I hold out hope.
OpenCL1.2 worked fine for all the test code I made for myself. But OpenCL 2.0 was... horrid. Unworkable.
--------
My next step personally is to give DirectX 12 computer shaders a serious try. A lot of people are also talking about Vulkan shaders, as apparently that works well on Linux too.
ROCm on Linux is fine enough. But this weirdness of having a feature on ROCm Windows (when ROCm Windows isn't even public yet?) is well... weird. I guess its cool that AMD has worked with the Windows team to get everything squared up, but it'd be nice if ROCm on Windows were available to the masses.
That's because of the CUDA api specifically.
For the display support it's very hit/miss. Somethings work fine, then you want to try Wayland and things get odd...
When working correctly they Nvidia is mostly fine - Xorg games have support for everything except dlss3 AFAIK.
No, if they wanted to support AMD they would provide an alternative GPU implementation that worked on their. It's like saying an app only supports Windows because of the Windows API. If someone wanted to support multiple apps they wouldn't just use the Windows API.
AMD's implementation (ROCm) has historically been incredibly difficult to work with. As in their own examples won't compile.
Historically if you even wanted to _touch_ data-science you had to have CUDA hardware/software (it's been improving a bit but alternatives are still lacking).
> It's like saying an app only supports Windows because of the Windows API.
It's a little more nuanced than that because the CUDA api is specifically for one set of tasks - data science.
Nobody uses nvidia for their wide desktop support on linux - because it's terrible. Literally the only benefit of using nvidia + linux is either because of raw performance of the hardware and/or the cuda support. If you look at the arch wiki (applies to other OSes too) for anything graphics related you'll almost always seen specific sections dedicated to workarounds and fixes for nvidia hardware.
If you don't believe me then try setting up wayland with nvidia drivers. Steam just had a fun issue where they were crashing on nvidia hardware with their latest redesign (no idea how they didn't catch that?!). These types of issues are commonplace, and are largely avoided by using AMD.
thus why I say it's only really because of the cuda support.
Nvidia handled it ok.
-Up to 60x Faster copying mesh attributes
-10x Faster loading curve objects
-9x Faster loading point clouds
-4-6x Faster loading large meshes
I don't often do anything with text within Blender for this specific reason, if your text was anything more than really a word or two it was nothing but friction.
Excited to be able to use it in a much easier manner. Blender remains one of my favorite pieces of software out there.
And in Blender 3.5 a Metal background was added to the viewport https://code.blender.org/2023/01/introducing-the-blender-met...
I suggest you use it for Eevee or images in Cycles, but you probably don't have time to wait for Cycles video.
https://projects.blender.org/blender/blender/commit/c3dfe1e2...
A lot of the Blender redesign and big features is the community pushing over years to say: “this is what we need” and being shot down till someone finally breaks through. Many features stay in forks for ages because they get blanket statements turning it down until they’ve amassed enough hype in the community. See grease pencil and the 2.8+ redesign.
I would give the most credit these days to the folks around him who are more willing to listen to the community and work directly with them.
Not directly mentioned there is the income they get from selling merch in their store [2]. I guess it's small compared to their other sources of income.
https://www.blender.org/download/demo-files/
Those were nifty. ;)