Any Ryzen/Nvidia users using Darktable?

stratacast1

stratacast1

Around June last year I was using FreeBSD 11.1 with KDE Plasma and really loving it. However, not too long after I had the chance to take some photos with my DSLR and came to edit them in Darktable. That's when I found out any sort of user interaction with Darktable would spike my CPU usage to 100%. Zoom in on a photo, select the next photo, anything...CPU usage spiked at 100% until it was complete. This (and a couple other paper cuts that have been sorted out in Plasma) are the reason I dropped FreeBSD on my desktop. Now that it's almost a year later, there's a new FreeBSD release and Plasma has been fixed up, I really want to switch back to FreeBSD. So my question is, does anyone with similar hardware have issues like I described in Darktable? I'm not in the mood to nuke my daily workstation just to find out I have to revert back, and I don't have any similar hardware to test on
 
Are you sure that it really was usage at 100% and not just the clock that ramped up to the max?

If you want tasks to be finished as quick as possible, that's how it's done. Let the cpu clock ramp up quick, even though there isn't 100% load on the cpu (powerd's default is 75%).
On short tasks, you won't always notice big time differences between an agressive and a more balanced mode, but heat output (and noise if you have a bad cooler) will be noticable higher, with an agressive power mode.

How agressive the cpu clock should go up/down can be tuned with powerd(8) and even more with sysutils/powerdxx. There is a high chance that the OS you are using right now, simple handles the frequency changes in a more balanced manner by default.

Especially on laptops, powerdxx is really good, as you can adapt the heat output produced by your regular workflow, to the cooling capacity of your laptop.
It may take you a day or two of testing, but it's absolutely worth it imo.

If your workstation is a desktop and you want all the processing power you can get, then I would always prefer to buy a better cooler and quality thermal grease, then use powerd's agerssive hiadaptive mode.
 
k.jacker said:
Are you sure that it really was usage at 100% and not just the clock that ramped up to the max?
Click to expand...

100% positive. And it's not that I'm talking about the CPU being efficiently utilized. I'm saying if I simply switch to the next photo my CPU pegs at 100%...so if I switch between 10 photos it might take a full minute because the program is running like dog crap when on Linux I can sift through 10 photos before I can blink. This is a Darktable on FreeBSD problem
 
I decided to test this in a VM. Still broken. Simply switching between photos takes a long time and spikes the CPU load. Do it in Linux, my CPU doesn't even notice something happening. FreeBSD is literally the only OS that does this. Not in Linux, not in macOS, not in OpenBSD. I even tried contacting the port maintainer and got no response soooo...FreeBSD desktop remains dead to me
 
I no longer use graphics/darktable or graphics/rawtherapee for this very reason. Same issue: the UI of both apps becomes completely unresponsive immediately after startup. I don't believe the graphics card is at fault (or a factor) because I get the same behavior running on an on-chip Intel HD630. It looks like both apps are written with the same toolkit although I don't know what it is. I say that because they have a very similar look and feel. Could be that is the cause but I don't know enough about each app to offer any suggestions.

EDIT - I still use FreeBSD as my desktop; not changing because of one app. I just changed my workflow to accommodate. I am only a (very) amateur photographer so not really an issue for me.
 
I don't go out and shoot as much either, once a month when I get time, but it would mean I'd need a whole separate OS install just for one tool. And I already contacted the maintainer about it and I got 0 response. I don't even know why he bothers, it's been useless for a year now, maybe more but that's when I tried an FBSD desktop. He must not use the port. Should be scrapped if it will be updated but not maintained. Linux does everything I need so I have no choice but to stay here if FreeBSD can't do it. If I didn't do photography I would have stayed on FreeBSD
 
All have this issues with Darktable on FreeBSD. Probably, due to broken OpenCL support. But I can't tell this is show stopper for me. Recently I processed ~2k photos with it.
I think to switch to graphics/rawtherapee At least, it's devs care about FreeBSD support.
The problem is rawtherapee doesn't have masks support.
 
I have exactly the same issue with graphics/darktable and graphics/rawtherapee: they both lock up almost immediately after opening and if they do work, they are incredibly slow to react to UI input. I normally have to kill them using xkill or by killing the pid. I have the same issue on 2 completely different computers: one using an Nvidia GTX 1050Ti and the Nvidia driver and the other using an on-chip Intel HD 630.

I should submit a bug report as suggested, rather than just using different software - the maintainer may not know there is an issue...
 
I don't have 'general UI slowness' with darktable then. Operations that are not processing images (say, configuration editing) are not slow. As I told, I processed ~2000 of 30Mb RAW photos.
Image switching (with space button) is the most annoying. Probably, ~2 sec for 1 image.
 
I need to revisit this, install both apps and test again - it's been several months (I think) since I have had them installed.
 
Well, I'm not qualified to judge as I don't actually use darktable for anything. I did a basic "open a directory and switch between photos test" (no editing involved, so supposedly no OpenCL) and it is indeed rather slow. darktable -d all output mostly consists of sql queries to in-memory (?) sqlite db, so I suspect it might be just a "let's throw a bunch of blocking calls into UI event loop" antipatern rather than a specific bug. It's would be nice to collect a few more opinions though.
 
shkhln said:
I did a basic "open a directory and switch between photos test" (no editing involved, so supposedly no OpenCL) and it is indeed rather slow.
Click to expand...

Ok, I redid the test with only three 10x10 px png images just in case. I don't see any improvement.
 
Well, I did 2 tests: 1 with graphics/rawtherapee and the second with graphics/darktable, mainly because I wanted to compare them to the past behavior I experienced. Rawtherapee started fine but after a few seconds of opening a directory with several hundred photos, all 4 (8) cpu cores were pegged at 100% and the app became unresponsive. Eventually it recovered and I was able to close it without having to kill the pid.

I launched graphics/darktable using the same switches you did shkhln - darktable -d all and got the same terminal messages. No errors when the sql import was finished. The app seemed to work fine actually, but the UI is too sluggish for my taste. Scrolling through a directory of thumbnails is very jerky and takes quite a bit of time. I don't think there is anything wrong per se - the rest of the app seemed to work fine and I didn't get any crashes. Reducing the size of the thumbnails did not help - performance was the same.

So, I don't think there is anything wrong with the app. I am not sure if my video equipment is causing my sluggishness: running on an Intel HD 630 with a 34" widescreen at 3440x1440. That might contribute my sluggishness, who knows. No other apps are sluggish though and even gaming is smooth on this set up.
 
All image operations in darktable are OpenCL-capable taks. They processed by universal pipeline(s) called 'pixelpipe' in following manner RAW -> History stack -> Output. Pixelpipes are used in thumbnail generation, image generation on main view and image generation during export. The problem is that all pixelpipes are on CPU power for us. Darktable logs decision not to use GPU acceleration during startup and even explain why.
 
I realized (again) I am way off topic on this thread because I just noticed the title is "Ryzen/Nvidia users". I need to be more thorough when I read these 😝
 
Sorry for not being present guys, been out of country :p still am...I'll spin up a VM again and test on my boxen when I get back home to submit a proper bug report
 
You must log in or register to reply here.
Back
Top