| Summary: | G'Mic for Krita is limited to one CPU thread | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | Camille Bissuel <welcome> |
| Component: | G'Mic for Krita | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | David.Tschumperle, halla, regulus2626 |
| Priority: | NOR | ||
| Version First Reported In: | 2.9.11 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/krita/53d8d95ce68ba78725eec5e73e109b17ce19580e | Version Fixed In: | |
| Sentry Crash Report: | |||
|
Description
Camille Bissuel
2016-02-05 15:16:26 UTC
*** 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 ! |