Darktable hangs in lightroom > import > either option
How to delete a post (this is in the wrong place)
You should try to narrow down which file is causing your issues. Is it the configuration file darktablerc or one of the databases (data.db, library.db), or …?
See darktable 4.6 user manual - storage (create database snapshot). For me it works exactly as described.
Thought I’d give an update. Yes, it’s been a long time but I have not been well and it took a lot of time and research.
DT now runs cleanly with OpenCL since this morning. The problem was I misread the guidance in the Arch GPGPU wiki page, which are very clear, my own fault. The crux of how it was done is in this post, which may help anybody intending to run DT on Arch or any other distro using an AMD GPU.
3 Likes
Sorry folks, it’s back to square one. After making the above post I went back in to give the OpenCL version a try. The first film roll opened with some blacked out images and they were all blacked out in Darkroom. So I tried a few more and ditto.
The images are intact but they don’t show in the Darkroom workspace so I can’t do anything with them. Back to running DT with the --disable-opencl flag and even then it is flaky at best.
I really don’t have time for any more pain. Problems running DT on an AMD GPU are splattered all over the web across several distros. AMD are obviously and contrary to their public statements not at all interested in whether their hardware works with Linux.
Without OpenCL DT is the best. Is there a fork which has not jumped the gun by introducing OpenCL long before it is fit for purpose? Other wise I’ll give RT a try.
Thanks,
Mike
Something doesn’t quite add up here…
Indeed it doesn’t. I have images to process and I need to keep processing them whilst looking for another application and testing what I find. Unless it is a direct clone of DT but without the klutz that is DT with OpenCL on an AMD GPU.
The problem started when the new DT release came out tweaked for OpenCL. IIRC that was very early this year or very late last year. No options. The changes were there whether or not the user installed OpenCL. It broke my system and I have lost many hours, adding up to days, trying to sort it all out. Too much time in fact. The Arch devs and support staff don’t know what to do. I can’t see anything coming from DT. AMD support is totally absent so far as I can tell.
It seems indeed to be an AMD problem. But that’s not a problem darktable can solve (nor is it “using openCL before it’s ready”). NVidia works (for me at least) since several years with very few problems (and those were of my own making…)
Second, not many others show problems when running without openCL.
The easiest solution (if that doesn’t break other programs) would be to uninstall the (AMD) openCL libraries, perhaps? Not the drivers, just the oenCL part.
And remove the openCL kernels dt compiled (just to be sure). Those should be under ~/.cache/darktable in directories “cached_kernels…” or “cached_V1_kernels…” (note: ~/.cache is normally hidden!).
As for a DT version without openCL support, you may have to compile that yourself.
1 Like
If only the manual had a section about opencl…
You can start with
darktable --disable-opencl
Or just turn off in preferences
https://darktable-org.github.io/dtdocs/en/special-topics/opencl/still-doesnt-work/
1 Like
Thanks for the response. Correct. The DT devs can do nothing about it. What surprised me was the introduction into the code without first testing on what is one of the widest used GPUs in the world today and has been for years.
Removing rusticl, which made things worse not better, is an immediate priority. That should give me enough to improve things while I look for an alternative.
I’ve become all too familiar with the hidden user cache and config directories in Linux over many years, too. The problem with fiddling with those is that Arch, my distro of choice, is chosen by me precisely because it is a rolling distro and therefore permanently up to date. So my weekly updates would cause them to replace anew at least some of my changes.
@g-man over the past few months I’ve also become all too familiar with the CL flags available for the darktable command.
Thanks for the reminder of the docs pages on github. I’ll give that one a more thorough read when I get time. It’s a while since I first read it and didn’t find much of use then. Once again though, I don’t want to spend too much time keeping software running instead of processing images. I’ve done far too much of that already.
I was under the impression AP had started a branch some time ago. How is that progressing? It may be worth a look if it’s still going. I’ve also seen good reports of RawTherapee so will take a look at that.
What? You are using drivers that are not production ready and then blame the developers for your choice?
If you know the flags or how to disable opencl, why are you asking for a darktable without opencl?
Well, let me give my point of view. OpenCL has been in darktable for many years, so there has nothing been introduced in the time you are mentioning. In the last years we could identify a number of bugs in darktable OpenCL code that where only evident in AMD drivers - but dt bugs, sure.
What got a nuicance the last year or so, the AMD drivers are pretty “flaky” especially some distros seem to be more of a problem than others (just search this forum, for some reason arch and it’s derivates are not the best choice atm).
Also - just as a reminder - in current dt master we have runtime selection of common drivers so you can better test what works.
Last one, in >6years of darktable usage and 4years of dt developing i have had exactly 1week with a malfunctioning system and 1week with a problematic driver. Fedora and nvidia btw
Find him at https://ansel.photos/. But he also uses OpenCL. As others have said, darktable has used OpenCL for a very long time.
You can disable OpenCL in darktable, in your OS, switch to better drivers, or to another app like RawTherapee or ART (both supported via this same forum).
I don’t even see where a specific driver has been mentioned.
Oh well that’s obviously the problem. Alpha drivers 
Terrific responses and I’m grateful to all of you. From what I’ve learned over the past couple of days it seems OpenCL is ubiquitous and at the same time I’m stuck with my AMD GPU at least for the time being.
My operating system of choice for the past 20+ years has been Linux. Even if I were to change my attitude towards the rentier megacorporations it would be too great a learning curve for me to switch to 'Doze or mac now.
I’m not going to be drawn down rabbit holes of which hardware megacorporation to back or responding to amateur psychologists asking why I think what i think. They are unproductive.
My conclusion is that I will be better off sticking with DT even though I will have to do a lot of experimenting, hence using a lot of previously unforeseen time, with software in the shorter term.
1 Like
If your card is supported by amdgpu pro, it should work.
1 Like
@paperdigits the pro version is not required on Linux. The amdgpu module is required for the GPU to work at all though. The OpenCL driver is another entity and is also required. Confusingly, there are several of those and only one is likely to work. Thanks for the suggestions. I’m getting there slowly!
@kofa Problems began around the time updates flagged that something in DT had been done with OpenCL several months ago. It was the first time I had ever heard of OpenCL. That is what made me think OpenCL was something new in DT.
I’ve found in my own case that disabling OpenCL still leaves me with DT hanging among other problems.
I suspect you have tried to run DT with some new config files using the --configdir switch… just to see if you have some historic issue being carried forward… at the very least even this would likely be the best way to test things so that any legacy issues are not in play… just a thought if you have not…