Ah, that answers my question. Thanks for working on it guys!
It took me a while, and my hair is now even thinner than it was, but I seem to have things working, though I suspect in quite a fragile manner.
To use openCL, one needs to use the GPU. I had this working, using the proprietary NVIDIA drivers. There are user space libraries as well as a kernel module.
To use the AI features, one needs an onnx runtime, which in turn requires the CUDA toolkit.
I got the onnx runtime from its github site and CUDA from the NVIDIA developers site
I could use the AI routines, but found they were only using the CPU. Looking at the system logs, it showed that the kernel module and CUDA had incompatible versions.
I had to go to the NVIDIA drivers site to get the latest kernel driver.
Providing I use the appImage, I can now use the AI features running on the GPU.
However, this does mean that I am now running various bits of software that are not in the openSUSE repositories. What happens when I do system upgrades, I don’t know, hence my supposition that this could be fragile.
1 Like
NVIDIA seems to offer their cuda tookit through repos which are compatible with zypper and SUSE distributions, why not use that?
Hindsight is a wonderful thing.
Initially, I found a web page advising getting the toolkit from the NVIDIA site, which I did. It was only later that I found another site which said that there was an OpenSUSE repository for CUDA.
I have added the repository to the ones I search for updates. However, I don’t know whether you have looked at it, it appears to be a “bag of holding”, with every release that NVIDIA have ever produced and lots of seemingly auxiliary software. There is a meta-package, but you only get to see what it would install, after it has been installed!
Its a bit of a Jenga tower at the moment, but I will stick with what I have got until SUSE produce the genuine version, and hope that my regular system updates don’t break anything.
1 Like
Yeah, the CUDA toolkit package is a “monster”, takes up a few GB and it’s usually all or nothing.
1 Like
rocm is even worse.
What an interesting little fella. Great shot 
!
ONNX is just an interface definition. Darktable depends only on ONNX Runtime. Our release packages come with ONNX Runtime bundled. GPU support is explain in user manual.
Don’t forget that you also need cuDNN 9 installed.
It is much safer right now to use CUDA Toolkit 12. It has better driver support as now.
Not really. Its downloaded.
If we are talking about Linux AppImage, Windows and macOS installation packages, they all come with ONNX Runtime bundled. The only difference is that on Linux it comes without GPU support by default.
Details on what comes bundled and what can we installed additionally are explained in user manual
Same for me, I couldn’t wait so I built it. The build.sh worked like a charm. darktable gets put in /opt/, so no problem if I want to go back to the version coming from arch linux repositories. The AI mask tool is damn good
4 Likes
To those who are interested: I can provide preliminary packages for Debian (with and without AI features enabled), which will become the next official Debian packages for darktable 5.6. There are just some housekeeping tasks to do (updated copyright metadata) for which I currently lack motivation.
2 Likes
I’ve only dipped my toes in so far, running the 5.6 appimage on two Manjaro machines (a laptop with integrated graphics and a desktop with older Nvidia graphics card) and it already blew my socks off!
I’m still playing with the two masking engines and undecided which one is “better”, most likely they both have their uses. I’ll explore this as I go along.
The AI noise reduction is somewhat less essential/successful to me as I’ve been using NeatImage for so many years with great results and it does batch mode but I totally understand we are at the beginning of a long process and seeing the first steps.
Kudos to the team for keeping the AI disconnected from the cloud - for me that would potentially have been a deal-breaker.
5 Likes
I have been learning DT (on Linux) this last month. I was getting to the stage where I was producing results I was happy with, and understanding the basic set of modules.
I opened DT today to find it is the updated version to 5.6. My library of processed images I’ve been working on for the last month are all now showing over-exposed, I’d estimate around 0.5ev to 0.7ev.
Is there some new setting I am missing which would explain this?
The over-exposure is consistent, ie an exported image is also over-exposed compared to the same image exported last week in DT 5.4, with the same history stack.
Thank you.
I second this.
To all the non technical Linux users: building from sources is a rite of passage that sooner or later must be done
And in the case of darktable the most difficult part is installing all the dependencies, which are not many and listed in the README.
3 Likes
I know how to do it and I have done it several times, but I still prefer to install so that it is managed by my distro’s package manager.
Also, darktable 5.6 is finally in Arch’s testing repository. It should be available, soon.
1 Like
That raises a few questions: which version were you using before, what kind of package are you using (flatpak, snap, distro binary, …) and what Linux distro are you using? Normally you don’t get unexpected/forced updates, and what you describe is certainly not supposed to happen (and didn’t happen for me, but I compile the binary myself)
Don’t forget to install the binaries (libraries) and the development packages of the dependencies (if you want to build dt). If you have used a dt version through your package manager before, there’s a good chance the binarie packages are installed already, the -devel packages most likely are not.
2 Likes
Yep.
In Fedora they are the *-devel packages (basically header files) which automatically pull down also the actual library binaries, as dependencies. Otherwise they would be of little use by themselves.