Using G'Mic in Krita with intensive filtering, only one of my 8 CPU thread is used... For example with theses filters : Artistic > Dream smoothing Repair > Smooth [thin brush] were multi-threading can be specified in option, even setting it to 8 thread result in a one thread usage, so computing time is much longer. In general with other filter were multi-threading is not explicit, Krita is still using only one thread, on the contrary to Gimp in the same conditions. Reproducible: Always Steps to Reproduce: 1. Open an image 2. Apply a G'Mic filter and set it to multi-thread 3. check you system monitor : only one CPU thread is occupied Tested with 2.9.11 and 3.0 Alpha 1 from AUR (krita-git)
*** Bug 360764 has been marked as a duplicate of this bug. ***
That is probably related to the fact G'MIC plug-in in Krita is compiled with MSVC, and without OpenMP support for enabling parallelization. Is there any plans to use the G'MIC newest C bridge and DLL for the plug-in soon ? That would solve the issue I think.
Lukas said he was looking into it, but the bridge really limits what we can do in the gui; there is no progress reporting possible and things like that.
Ha yes, you are right about the progress report. I'll ask Thomas to look into this problem, I'm sure this can be solved really easily.
Sorry, I'll ask *Tobias*, not Thomas :) He is the author of the libc interface.
Well, after looking more closely at the G'MIC libc interface, I've seen this is already possible to get access to the progress bar. Maybe Lukas can tell me what is missing exactly.
Er, wait, this whole discussion is bogus: this is about g'mic on _linux_!
So, maybe more info about how multi-threading is implemented and used in G'MIC. There are two different ways for G'MIC to use multiple cores for doing calculations: 1 - Either a G'MIC filter uses one of the "built-in" command (basically one method of the CImg Library) that has been parallelized (using OpenMP directives). 2 - Either the G'MIC script that defines a filter creates a thread explicitly (there are commands to manage your own threads in G'MIC). These two cases use different libraries and configuration variables to tell the compiler to use them. You can either activate 1 or 2, or the two at the same time (which is better of course). Basically, when you compile, you need to define the following compiler flags to enable (this is a copy/paste from the official G'MIC Makefile): 1. # Flags to enable parallelization of image processing algorithms, using OpenMP. OPENMP_CFLAGS = -fopenmp -Dcimg_use_openmp OPENMP_LIBS = -lgomp 2. # Flags to enable parallel processing. PARALLEL_CFLAGS = -Dgmic_is_parallel ifneq ($(OS),Windows) PARALLEL_LIBS = -lpthread endif That's it. If you compile the G'MIC library with all those flags enabled, it should use the multi-threading capabilities at its best.
Git commit 53d8d95ce68ba78725eec5e73e109b17ce19580e by Boudewijn Rempt. Committed on 17/04/2016 at 08:19. Pushed by rempt into branch 'master'. Add some missing gmic definitions This should fix the cross-platform gmic build by defining the os and the display explicitly and enable openmp properly: threading was already defined properly, so if that doesn't work, it probably isn't krita's faul. M +11 -0 plugins/extensions/gmic/CMakeLists.txt http://commits.kde.org/krita/53d8d95ce68ba78725eec5e73e109b17ce19580e
Many thanks to both of you ! I've just complied a fresh Krita 3 with AUR https://aur.archlinux.org/packages/krita-git/ to test your work … and parallel processing is now working, it's great ! BUT : Setting explicitly a limited number of thread (4 on 8 or 2 on 8 for example) IS NOT working : all threads are used any ways. So, situation is really much better, because most of the time we want to use the full processing power, but it's not entirely fixed. Should we reopen ?
I am tempted to say no... I could look into it, but in principle, all options are passed to gmic and then it's up to gmic to do stuff with it, and I cannot debug gmic itself.
Well, maybe there is filters remaining where the two parallelization methods are used in the same time (which is useless of course). Precisely, could you tell what filter allows you to choose the number of CPU and still works with all CPUs at the same time ? This is probably an error from my side, so I can correct it (basically, I'll remove the 'number of threads' option in this case). I don't have any options to choose the number of threads for OpenMP-parallelized algorithms in any case.
The two filters where I can set up the rationalization number I found are Artistic > Dream smoothing Repair > Smooth [thin brush] as mentioned above ;) There may be more, but I can't find any other right know… maybe there are some grep method to find all mention of "parallelization" in the G'mic code ? My G'mic version is 0.1.7.0… And I just checked the same filters in Gimp : they also use every thread whatever the setting, so Krita is not faulty here. (If you prefer Boud, we can move to a G'mic bug report ?) Thanks for your work in any case !