Krita performance.

Sven Langkamp sven.langkamp at
Tue May 21 19:55:25 UTC 2013

On Tue, May 21, 2013 at 9:14 PM, Boudewijn Rempt <boud at> wrote:

> On Tuesday 21 May 2013 May 21:08:19 Sven Langkamp wrote:
> >
> > I think we need to do something significantly different to get to this
> > performance level.
> Yes, that is my fear as well.
> > I don't think the current approach can
> > be optimized enough to do it. We discussed that on the last sprint and we
> > had no idea what Photoshop is doing. In meantime they are going for GPU
> > support like Mari.
> There must also be something with deferred processing or something like
> that. There's no way one is going to get a 14032x9632 in 32f in gpu memory,
> not even on a quadro 400 and still have space for something else...

Newer nvidia cards have up to 6 GB of graphics memory, so it should fit.

> I've been experimenting a bit, and an ordinary layerstack (a4, 300dpi)
> with a dozen layers works fine on my intel gpu and a little bit of graphcis
> memory, though.
> I want to experiment some more here -- but the trick is arriving at
> a) a good, extensible technology choice (glsl? cuda? opencl? whatever?)
> b) a good, extensible design
> c) something that krita can grow into, because we don't want to do full
> rewrites (I hope...)

a) I would go with OpenCL. CUDA is nvidia only and glsl is a bit ugly for
this purpose.

b) and c) is very tricky. There is the most simple way were you write the
content of the layer into a buffer and push that to the graphics card,
process it and get it back. This can be done without many rewrites, but you
get a memory transfer bottleneck. This would give us a speedup of very
computationally intense calculation, but not much or even negative on
memory bounds ones.

The other option is to have all the tiles on the GPU, but that sort of
difficult to integrate with the current codebase.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the kimageshop mailing list