[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    A report about profiling openGL pipeline in Krita
From:       Dmitry Kazakov <dimula73 () gmail ! com>
Date:       2014-06-07 19:13:58
Message-ID: CAEkBSfWSb2jsFF8PKEMM+aoKpxFy8PfWnd_jLUADwaGZmrMXZQ () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Hi!

Today I new about the existence of apitrace... :)

Here is a small report with numbers, which I'd like to share with all of
you:

Preconditions:

1) I tested on a RGB8 image 6000x6000 pixels in size. To test the updates
pipeline I filled the image with color (which caused the full update of the
openGL textures).
2) Tested on Intel Haswel integrated GPU.


Uploading of textures:

Uploading of the whole image to GPU takes:
* Texture Buffers enabled: 640 ms
* Texture Buffers disabled: 413 ms

During every upload we spend about 30% of time on handling Qt's queued
signals. The overhead is about 1 ms per patch (default is 512x512 piece),
which is about 120 ms for a 6k image. This can (and must) be fixed.
Probably with aggregating these signals somehow.


Rendering of the image:

* First update (mipmaps are not yet generated): 160 ms
* Consequent updates (mipmaps are already in cache): 59 ms

We also have a drain of efficiency in drawDecorations() call
(kis_opengl_canvas2.cpp:242). It does nothing, but eats about 10ms per
every update. More than that, this value is constant(!), that is doesn't
depend on the dirty area size.


-- 
Dmitry Kazakov

[Attachment #5 (text/html)]

<div dir="ltr"><div><div><div>Hi!<br><br></div>Today I new about the existence of \
apitrace... :)<br><br></div>Here is a small report with numbers, which I&#39;d like \
to share with all of you:<br><br></div><div>Preconditions:<br> <br></div>1) I tested \
on a RGB8 image 6000x6000 pixels in size. To test the updates pipeline I filled the \
image with color (which caused the full update of the openGL textures).<br \
clear="all"><div><div><div><div>2) Tested on Intel Haswel integrated GPU.<br> \
<br></div><div><br>Uploading of textures:<br><br></div><div>Uploading of the whole \
image to GPU takes:<br></div><div>* Texture Buffers enabled: 640 ms<br></div><div>* \
Texture Buffers disabled: 413 ms<br></div><div><br></div> <div>During every upload we \
spend about 30% of time on handling Qt&#39;s queued signals. The overhead is about 1 \
ms per patch (default is 512x512 piece), which is about 120 ms for a 6k image. This \
can (and must) be fixed. Probably with aggregating these signals somehow.<br> \
</div><div><br><br></div><div>Rendering of the image:<br><br></div><div>* First \
update (mipmaps are not yet generated): 160 ms<br></div><div>* Consequent updates \
(mipmaps are already in cache): 59 ms<br><br></div><div>We also have a drain of \
efficiency in drawDecorations() call (kis_opengl_canvas2.cpp:242). It does nothing, \
but eats about 10ms per every update. More than that, this value is constant(!), that \
is doesn&#39;t depend on the dirty area size.<br> </div><div><br><br>-- <br>Dmitry \
Kazakov </div></div></div></div></div>



_______________________________________________
Krita mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop


[prev in list] [next in list] [prev in thread] [next in thread]