About vectorization and planar channels in Krita

[JL VT]

On Mon, Oct 1, 2012 at 4:18 AM, Boudewijn Rempt <boud at valdyas.org> wrote:

> On Friday 28 September 2012 Sep, Dmitry Kazakov wrote:
> > Hi!
> >
> > After that long discussion about grayscale selections I decided to check
> > whether we really need planar channels for implementing the vectorization
> > in Krita. And it turned out, that we need *not* do it. The SIMD
> > instructions cannot work with bytes directly (we won't be able to
> multiply
> > anything), so in both of the cases, when we use planar bytes and not, we
> > will have to convert the pixel data into some other format: single
> > precision float or single word integer, doing some inevitable
> permutations
> > and wasting time on them. The flat channels will give us no help with it.
> >
> > What we really need to do is just to use the advantages of RGBA pixel
> > layout (better data locality and good alignment) and optimize our code.
> As
> > a proof of concept, I've written a small benchmark, that compares our
> > standard integer COMPOSITE_OVER algorithm against its SIMD (avx)
> > implementation. The streamed implementation showed a 3.3 times better
> speed
> > than the algorithm we use right now. More than that, this sketch was
> > written in just a day so it has lots of possibilities for optimization
> (it
> > can be modified to process 10.6 pixels at a time instead of 8, for
> example).
> >
> > The actual results of composing of 32 MPixels:
> >
> > TestAvxCompositeOverTest::testPerPixelComposition(): 370 msecs
> > TestAvxCompositeOverTest::testAVXComposition():      147 msecs
> > TestAvxCompositeOverTest::testAVXCompositionx2():    113 msecs
>
>
> 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.
>
>
Those are great news Dmitry.
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.

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.
However, RGBA optimization is better than no optimization, so go ahead
either way.


>
> > What I want to tell with this mail:
> > 1) There is no need to port the whole Krita to use some other channel
> > layouts. Even current layout gives us lots of possibilities to optimize
> our
> > code.
>
> Ok, that's good.
>
> > 2) We still need to decide what to do with grayscale selections.
>
> Yeah... Please go for optimization of the composite ops first, let's
> tackle this later.
>
> --
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20121001/b7181fb2/attachment.html>