<div class="gmail_quote">On Mon, Oct 1, 2012 at 4:18 AM, Boudewijn Rempt <span dir="ltr"><<a href="mailto:boud@valdyas.org" target="_blank">boud@valdyas.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Friday 28 September 2012 Sep, Dmitry Kazakov wrote:<br>
> Hi!<br>
><br>
> After that long discussion about grayscale selections I decided to check<br>
> whether we really need planar channels for implementing the vectorization<br>
> in Krita. And it turned out, that we need *not* do it. The SIMD<br>
> instructions cannot work with bytes directly (we won't be able to multiply<br>
> anything), so in both of the cases, when we use planar bytes and not, we<br>
> will have to convert the pixel data into some other format: single<br>
> precision float or single word integer, doing some inevitable permutations<br>
> and wasting time on them. The flat channels will give us no help with it.<br>
><br>
> What we really need to do is just to use the advantages of RGBA pixel<br>
> layout (better data locality and good alignment) and optimize our code. As<br>
> a proof of concept, I've written a small benchmark, that compares our<br>
> standard integer COMPOSITE_OVER algorithm against its SIMD (avx)<br>
> implementation. The streamed implementation showed a 3.3 times better speed<br>
> than the algorithm we use right now. More than that, this sketch was<br>
> written in just a day so it has lots of possibilities for optimization (it<br>
> can be modified to process 10.6 pixels at a time instead of 8, for example).<br>
><br>
> The actual results of composing of 32 MPixels:<br>
><br>
> TestAvxCompositeOverTest::testPerPixelComposition(): 370 msecs<br>
> TestAvxCompositeOverTest::testAVXComposition():      147 msecs<br>
> TestAvxCompositeOverTest::testAVXCompositionx2():    113 msecs<br>
<br>
<br>
</div>Well, that's very much worth it, I think. How about tackling the composite ops first, while we think about the selection issues? Please do use the Vc library when working on the composite ops in Krita, though, so we have only one api to learn.<br>

<div class="im"><br></div></blockquote><div><br></div><div>Those are great news Dmitry.</div><div>I was going to look into the composite ops, but I have my hands full; I only have time to devote to vectors, which I'll be looking after now.</div>
<div><br></div><div>One comment I have to do is that eventually Krita should support realistic color mixing. If the optimizations you make are specific to RGBA, then the few artists that work in CMYK, as well as the people who will do color balancing in CIELAB and painters using Kubelka-Munk color mixing will miss the optimizations.</div>
<div>However, RGBA optimization is better than no optimization, so go ahead either way.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
><br>
> What I want to tell with this mail:<br>
> 1) There is no need to port the whole Krita to use some other channel<br>
> layouts. Even current layout gives us lots of possibilities to optimize our<br>
> code.<br>
<br>
</div>Ok, that's good.<br>
<div class="im"><br>
> 2) We still need to decide what to do with grayscale selections.<br>
<br>
</div>Yeah... Please go for optimization of the composite ops first, let's tackle this later.<br>
<span class="HOEnZb"><font color="#888888"><br>
--</font></span></blockquote></div>