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…
Finally it is all sorted out. I think I may even understand part of it.
There is an AUR package called opencl-amd. Having cleared everything installed out again after each (failed) attempt this has worked.
AUR has its own section, linked from the main navigation bar on the Arch web site.
DT worked fully at initial installation but was excruciatingly slow. Some of the blacked out images from the previous attempt with rusticl were still blacked out. A couple of tweaks of the settings in “darktable preferences > processing > CPU / GPU / memory” soon solved that.
I now have a fully operational, lightning fast, instance of DT running on my PC.