I’m getting ready to build a new desktop pc in late 2024, and am unsure about whether to go with Nvidia, AMD or Intel ARC. I’ll be using the pc primarily for darktable work, some video editing in KdenLive, the usual office and social media activities. I plan on replacing my aging Dell monitor with a newer 4k display.
I plan at this point to install Fedora41 KDE spin as my OS. I don’t do any gaming, my biggest concern with the video card it getting OpenCL working reliably for darktable use.
I had originally thought that AMD video was a good way forward, but I really don’t know what the state of software is for OpenCL , AMD and Linux at this time.
I used to run NVidia cards with Fedora systems for many years. Rpmfusion drivers worked, but sometimes they lagged behind new kernel versions. This lag was more pronounced during major system updates (e.g. F39 - 40). After one particular upgrade (38 → 39 I think) I had major problems with NVidia drivers until I waited a few weeks after the release. Then I switched to AMD (Radeon RX 6600 8GB) with open source drivers and forgot about all the problems. Everything works without any fiddling, including OpenCL, DT flies with it now. And AMD prices are lower than NVidia for similar cards.
Philosophically, Linux does not like proprietary stuff and NVidia is part of it. While AMD is more friendly to Open Source.
Really depends on how big are your files, but in terms of brand, I switched from an Nvdia 2070RTX Super / 8GB to an AMD RX6700XT / 12Gb and all my drivers issues disappeared. I’m running Opensuse Tumbleweed, KDE and a part from darktable I’m using — as non pro user — blender, kdenlive, davinci without issues.
Thanks for the answers all. My files are generally 20mb (I shoot M43). I think I read in a post a while back that the suggested memory on the GPU was 16 GB. Still true?
You dont need that much. Above 4Gb is fine and 8Gb might be ideal. I have a 3060 12Gb and I also have a M43 camera. The system doesnt use all of the 12Gb.
Since I used rpmfusion I automatically used akmod. Lagging depends on how fast fpmfusion updates the driver on their side to be in sync with the new kernel version. Usually it is OK, but sometimes it is not.
Anyways, using proprietary stuff in Linux, especially Fedora, may require some tinkering to get it right. While open source drivers for AMD work as is.
it seems the amd drivers are often mentioned as “open source and juts works”. when working with these, you’ll notice there is the amdgpu and amdgpu-pro driver, as well as amdvlk or RADV/mesa as vulkan implementations… and not all of them work. luckily it seems the community/open source version (amdgpu/RADV) works most bugfree and fastest.
also especially under high load, the amd gpus draw more power and produce more heat than comparable nvidia counterparts. lastly, if you care, nvidia gpus support some more sophisticated extra features such as the cooperative matrix extension or ray tracing cores that work better. darktable will not make use of these.
i would agree to what was said about memory. everything over 4GB is probably useful, though vkdt struggles with 50MP images within this limit (and i believe darktable uses more memory).
i thought the arc A770 was a great gpu… can’t speak to the next generation, i hope they will continue building gpus at all. my impression was that intel was probably the last vendor who actually cared about opencl support.
I think NVidia are also moving to open-source drivers.
With the R515 driver, NVIDIA released a set of Linux GPU kernel modules in May 2022 as open source with dual GPL and MIT licensing. The initial release targeted datacenter compute GPUs, with GeForce and Workstation GPUs in an alpha state.
[…]
We’re now at a point where transitioning fully to the open-source GPU kernel modules is the right move, and we’re making that change in the upcoming R560 driver release.
(Source: https://developer.nvidia.com/blog/nvidia-transitions-fully-towards-open-source-gpu-kernel-modules/)
How relevant is this for image editing? For gaming, sure that makes a difference of some 20% of total power draw, but what is the power draw of a GPU card when editing in DT or vkdt? Is it short bursts of 100% when touching sliders?
But are consumer grade products like GeForce already on OpenSource drivers?
Intel cards seem to offer more GB of memory and memory bandwidth for the same price than AMD and NVidia.
AMD offers better gaming-value/money-spent than NVidia if you don’t need raytracing (I don’t know how relevant this is for linux, maybe with steamOS it is?).
Support is coming with the 560 series (I’m currently on 550 with Ubuntu), but only for newer cards. My 1060, based on the Pascal architecture, won’t get open-source drivers.
For newer GPUs from the Turing, Ampere, Ada Lovelace, or Hopper architectures, NVIDIA recommends switching to the open-source GPU kernel modules.
For older GPUs from the Maxwell, Pascal, or Volta architectures, the open-source GPU kernel modules are not compatible with your platform. Continue to use the NVIDIA proprietary driver.
Just mentioning my experience with issues on darktable github or here (without correct statistics as i don’t count them): The vast majority of reports on linux sytems - not genuine dt bugs - were related to AMD drivers on rolling distros like arch-based, whatever the reason is for that. Intel had a few problems some years ago… So guess what i have been using for years
well, for a good gpu i think it’s not even 100%, and yes, short bursts until you hold still or of course while exporting. i don’t know the exact percentage… but i can totally feel the temperature difference in a room after a day of work
heh same here. though i’m always interested in other devices, and since vkdt is so close to the hardware often the only way of really fixing issues is for me is access to devices of the vendor in question (thanks a lot to the folks who helped me with this in the past).
Genuine question: how is it possible to have the steam-deck work with hundreds if not thousands of games quasi issue-free when the AMD drivers on rolling distros are worse than nvidia drivers? do games use different features of a GPU? Is Valve not using amd-drivers? Is valve just hyper focused on rdna2, the architecture that the steam-deck uses? Would that mean that rdna2 gpus with amd-drivers should pose less issues in general?
Sorry for the barrage of questions. I have certain issues with nvidia from a consumer perspective (market dominance/ quasi monopoly and therefore pricing, and that they had to be quasi forced into opensourcing their drivers).
Games are 99% of the time run with vkd3d or dxvk which translates directX12 and 11/10/9 into Vulkan respectively. Native games used to use OpenGL but now almost all of them run vulkan as well. The problem with AMD for photography is that its OpenCL support using the open source driver was pretty poor and you ended up needing to use the proprietary AMDGPU-PRO driver anyway. The open source driver is great for general purpose usage and also for games using vulkan.
A good thing to remember is that historically whilst nvidia has had their drivers closed source, for the longest time if you wanted a good graphical experience in linux you needed to use them since AMD did not provide support.
Would be interesting to see some hard data regarding “pretty poor support for OpenCL” from open source AMD drivers. I installed rocm packages for Radeon RX 6600 card on Fedora and DT became much faster. Did not observe any problems after using this setup for more than a year.
An example. Just do a search on any search engine and there’ll be a lot of results for this issue. Maybe nowadays it’s better but for a long time that wasn’t the case.
Okay, I think I got it (I hope at least).
There are translations (like cross compilations?) from D3D to Vulkan which work quite nicely, since Vulkan works on AMD and Valve put a lot of work into this translation.
OpenCL is kind of passé in terms of support from the khronos group (they think Vulkan is the place to be) and with this driver support from AMD is a bit meh as AMD is happy to have Vulkan working.
As far as I can tell even having OpenCL work in a Vulkan context was planned at some point but didn’t happen (yet, at least).
That sounds like the current state is not so clear cut?!