Hello!<br><br>As you may already know right now I am working on making vector optimizations for Krita work on different CPUs when distributed as a binary package. To achieve this goal I used some cmake magic (borrowed from Vc project ;) ) to produce multi-arch builds for the hottest parts of pigment and Krita. That is a single .cpp file is compiled several times with different compiller flags; the resulting .o files are put into a single .so library (libpigmentcms.so) and the choice of the exact version of the code occurs on the fly when the colorspaces are created. <br>
<br>This approach has several pros and cons and we need a kind of compromise here, that is why I would like to ask for your opinion:<br><br>Pros:<br>1) We can have prebuild versions for all the architectures supported by Vc (Amd XMA4 and XOP are not supported by Vc yet), it means we can redistribute optimized binary version of Krita.<br>
   <br>Cons:<br>1) Currently the code depends on Vc's 'staging' branch, so it can't be put in master. For now all the changes are kept in 'vector_compositioning_kazakov' branch.<br>2) I used fat-binary approach for code generation. It means that all the versions of the code are put into a single binary (libpigmentcms.so) and therefore are loaded into user's RAM on the start. This is a matter of excessive 3 MiB of user's RAM (libpigmentcms.so grew 15MiB -> 18MiB [1])<br>
3) If we want the binary to be redistributable, the compiler optimization for the rest of the code (not hotspots) must be disabled. In the benchmarks it leads to a slight (~20%) performance degradation on *some* of the tests. This is actually not much in comparison with the gain we get from using vector instructions, but still...<br>
<br><br>In my opinion the mentioned disadvantages are not much serious. The only concern I have is the size of the binary. The solution for it might be the use of separate .so libraries for each implementation, but I guess (at least for now) we can ignore it. 3MiB is not that much.<br>
<br>The problem of the speed degradation, I believe, cannot be (at least easily) solved without distributing per-architecture compiled kritaimage.so library. Each instance of this library takes 45MiB. Which leads to additional 7*45=315MiB in the distribution package. That is not worth it.<br>
<br>Taking all this into account I decided to introduce a new option for the Calligra build system: PACKAGERS_BUILD.<br><br>When the option is ON, the per-architecture builds are activated. The optimization for all the other parts is disabled. This is exactly what is needed by packagers.<br>
When the option is OFF, the whole Calligra project is optimized for the host CPU. No per-arch build are, therefore, done. This option is the best choice for users who build Calligra themselves.<br><br>By default the option is OFF. It means that we need to tell packagers to activate it. Where should I write about it? Do we have any packager's manual?<br>
<br>I would appreciate any comments from you about this! :)<br><br><br>[1] - in commit message I told about the growth 11->17MiB. I was wrong because measured it on the wrong binary.<br><br>-- <br>Dmitry Kazakov<br>