Well, users are expected to grossly underestimate the amount of work their requests will need.
In any case, modules are layers AND widgets, à la Photoshop, not merely widgets à la Lightroom, and if we lose the connection between widget order and layer order, then the whole thing becomes impossible to understand and manipulate.
I suppose that’s probably different from saying that vkdt can be made useable on any CPU since 2012. Would be great if (at least) darktable-level performance were possible without a GPU on vkdt. I only managed to get it work once I’d upgraded my GPU.
That’s most likely an issue of drivers. But having a pure CPU path in addition of the GPU one is the main performance bottleneck right now in mainstream dt. Just open darktable -d opencl -d perf and look at how much time is lost in the control queue and in the buffer copies… it’s between half and 3/4 of the pipeline runtime depending on the modules you use. That’s completely insane for something that will be thrown to the screen by the GPU in any case at the end.
Thanks, and that makes perfect sense. I get that there’s a limit to what an application can do under its architecture. I don’t expect to have one software that does it all, so that’s why I turn to different applications that handle the job better
That sounds wonderful. If you don’t mind me asking… Do you guys have an estimate timeline for that transition to start happening? What’s the current state of vkdt?
Nope!
Usable, but not much there.
Blender is in the same direction. They don’t have a specific release date but are working on it.
I think the comment from @anon41087856 should be taken as the opinion of a darktable developer, not a statement as to the agreed future of the project. The darktable project will continue as long as there are people willing to contribute to it.
It might be a ways off but it is also hard to imagine that AP would have time to dedicate to both projects esp if he is determined and focused to migrate modules to vulkan so for sure the DT project is not entirely tied to that but a large part of the core modules that have been introduced in the last few years have been a result of his input…You could see it as an opportunity for some others to fill a void should one arise and to look at things with fresh eyes…or perhaps it might go the other way…time will tell…
You know that most of the work I do in dt is not actually on dt, but on more fundamental colour handling and image-processing methods. I have gathered quite a lot of C libs doing colour work that could work for virtually any imaging app. Other people handle the UI, metadata and files I/O matters.
Having said that…what would be a pie in the sky guess at what it would take to come up with a workable vulkan version that you could use to process your images. I have no idea of what it takes to go from your C libs for color processing to a module ??
I can’t conjecture on that. For now, darktable is the only way to get work done from start to finish. When the color pipeline will be state-of-the-art from input to display transform, then we will have a solid inefficient workhorse and then will be the time to build a faster one.
And some developers can be expected to develop software primarily to satisfy their own needs.
That’s what they are paid for (in dt at least)
Well then you know what to do : become one of the self-serving devs.
Thanks. What surprises me actually is that no one has taken the dt source and created forks for different purposes and audiences.
I think most people just submit changes as pull requests to the darktable project. The vast majority of PRs are accepted by the team so it makes little sense to create your own fork that you then have to maintain.
not really surprising - stripping down functionality dosen’t give a more capable tool and developing and maintaning a fork for multiple platforms is not a one man show…
So it’s more efficient to spend effort on improving the original 
Again, underestimating the amount of work involved.
See Glimpse, cosmetic fork of Gimp for offendees. Their best success is their ambitious website. Their Github repo is merge commits from upstream Gimp, install scripts updates and labels changes. And it’s now abandonned.
The multiplatform support is the worse offender, it’s simply too much for a small team, let alone a single dude.
Finally, there is not one current dev who fully understands the 350 k lines of code in there, involving metadata handling, input devices support, GUI stuff, not the mention the color handling stuff with some serious maths and ICC support.
Treating an image software as just a piece of code is dev’s mistake number one and the reason why only 2 open source software are doing alpha blending properly (and Photoshop does not). Color science is as hard as it is overlooked by the tech bros who vaguely remember “color = wavelength” from physics class.
which ones? please