Kivy doesn't feel like using my GPU.... and then lags

[Damien Frikha]

Hello there,

I have horrendous lag issues on my computer running my Kivy application while playing with a fair amount of widgets (hundreds), and after having monitored my PC I realized that it was only using a single core of my CPU to do all the graphic calculations. I know that Kivy is 32bit-only so a single core doesn't surprise me, but no GPU usage is quite harsh.

 

My PC has a high-end sandy bridge core-i7 (8 virtual cores, so kivy can't use more than a 1/8 of it) and a AMD HD6700 (4 of them actually, but Crossfire doesn't work for a strange reason, didn't had the time to investigate that it has been my workstation for 2 weeks now).

My graphic drivers are up to date (checked yesterday) and GPU is working fine with other applications.

 

Is there anything then to do with Kivy to ensure that he uses my GPU ?

 

Thanks.

[Akshay Arora]

Depends upon your app, and the way you have written it. Did you follow http://wiki.python.org/moin/PythonSpeed/PerformanceTips. make sure you follow the performance tips mentioned in the article.

Python is generally restricted to using one processor only so that's a limit of python you are hitting. You can look into using multiprocessing on the desktop if your workload requires that. be forewarned though it's not supported on mobile os, where you can look into using native services/threads.

As for gpu utilization I guess your app does work that is cpu heavy and not gpu heavy. I'm just guessing as we don't have your code/snippet that reproduces the issue to be able to judge the real problem.

Best Regards

--
You received this message because you are subscribed to the Google Groups "Kivy users support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kivy-users+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Damien Frikha]

What's taking so long to perform in my code is when i'm trying to move and rotate a lot of Scatter Widgets, like this :

for i in range(0,len(scatter_widgets)):
     self.scatter_widgets[i].rotation=-thetai
     self.scatter_widgets[i].center=(xi,yi)

where len(scatter_widgets) can be up to 500-600, and this code is called at each new frame.

 

But maybe this isn't GPU work, the issue is the same if my widgets are empty (they contain a canvas-drawn symbol normally), you must be right. In that case i might be asking too much to my CPU, but I find it strange that it couldn't manage to execute that smoothly, but maybe i'm wrong ?

 

What could I do then (aside doing something completely different) ?

[Akshay Arora]

The link I posted for performance tips, mentions minimizing your dot look ups. So first try

    for widget in scatter_widgets:
        widget.rotation = -thetai
        widget.center = (xi,yi)




Secondly try and consider if your app really need 500-600 widgets or could this work better if you just draw directly to the canvas.


Without much context with that loop Can't really say, you'd need to do the tests yourself.



Best Regards


[Damien Frikha]

These optimisations don't change anything, this is just as slow as if was before. Even if I don't even add the widgets aren't added to a parent widget to be drawn somewhere, it is just as slow, meaning that I was wrong to consider this like GPU work.

 

These widgets each contain a canvas-drawn symbol that together form a map. The map needs to be upgraded at each frame because all coordinates of those widgets must be calculated from the map center, which represent a "moving" object (namely a plane) that remains at the center of the screen (like a radar). Moving the entire map doesn't work because the coordinates on the map depend on the position of the plane in space. The map rotates but the symbols have to keep the same orientation, hence the scatter to compensate the global rotation.

 

Would it be solve my performances issue if i stopped using widgets, replacing them by drawing directly on the canvas and clear/redraw everything at each frame ? It would be a pain to code properly to keep the good position and orientation of each symbol but it seems doable.

[Mathieu Virbel]

Hi,

It seems you're confuse about what is currently slowing down. Scatter
got matrix calculation done... in python. That's expensive, even if we
use Cython.

500/600 is a lot of widgets, and if you are rotating them separately, 60
times / seconds, yes it can be time consuming, but still, it should works.

What you need to check:
- anything related to the scatter center/pos will be updated when you
set force the center to xi,yi. If you have propertiers/widgets/graphics
instruction that depends on them... then they are updated as soon as you
move the center
- if it's graphics instruction, just imagine that you are updating the
content (and re-upload the content to the GPU) of the graphics
instruction, 600 * 60 times per seconds. Still, i'm sure your GPU is fine.
- ensure they are not in a layout: the layout will listen to the pos of
the childrens. so it will stress the layout for nothing.
- learn about quad tree: even if we don't have a widget at all, i don't
see what's the use case of having 600 scatters rotating. you might a
more intelligent way to order the scatter rather than all in a list
- if each scatter have lot of graphics instruciton, see how much it need
to draw one frame, and act using this information (maybe use an
intermediate Fbo to lower the usage of graphics pipeline, but that's the
ultimate case).

If you want us to have a clearer view about your case, give us a test
case :)

Mathieu

Le 25/07/2013 09:49, Damien Frikha a �crit :

> These optimisations don't change anything, this is just as slow as if
> was before. Even if I don't even add the widgets aren't added to a
> parent widget to be drawn somewhere, it is just as slow, meaning that I
> was wrong to consider this like GPU work.
>
> These widgets each contain a canvas-drawn symbol that together form a
> map. The map needs to be upgraded at each frame because all coordinates
> of those widgets must be calculated from the map center, which represent
> a "moving" object (namely a plane) that remains at the center of the
> screen (like a radar). Moving the entire map doesn't work because the
> coordinates on the map depend on the position of the plane in space. The
> map rotates but the symbols have to keep the same orientation, hence the
> scatter to compensate the global rotation.
>
> Would it be solve my performances issue if i stopped using widgets,
> replacing them by drawing directly on the canvas and clear/redraw
> everything at each frame ? It would be a pain to code properly to keep
> the good position and orientation of each symbol but it seems doable.
>

> Le mercredi 24 juillet 2013 20:29:11 UTC+2, qua-non a �crit :

>
> The link I posted for performance tips, mentions minimizing your dot
> look ups. So first try
>
> | forwidget in scatter_widgets:

> widget.rotation= -thetai

> widget.center = (xi,yi)
>
>
> |
> |Secondly try and consider if your app really need 500-600 widgets
> or could this work better if you just draw directly to the canvas.
> |
> |Without much context with that loop Can't really say, you'd need to
> do the tests yourself.
>
> |
> |Best Regards
> |
> ||
>
>
> On Wed, Jul 24, 2013 at 7:18 PM, Damien Frikha <damien...@gmail.com
> <javascript:>> wrote:
>
> What's taking so long to perform in my code is when i'm trying
> to move and rotate a lot of Scatter Widgets, like this :
> |
> fori inrange(0,len(scatter_widgets)):

> self.scatter_widgets[i].rotat__ion=-thetai
> self.scatter_widgets[i].cente__r=(xi,yi)

> |
> where len(scatter_widgets) can be up to 500-600, and this code
> is called at each new frame.
>
> But maybe this isn't GPU work, the issue is the same if my
> widgets are empty (they contain a canvas-drawn symbol normally),
> you must be right. In that case i might be asking too much to my
> CPU, but I find it strange that it couldn't manage to execute
> that smoothly, but maybe i'm wrong ?
>
> What could I do then (aside doing something completely different) ?
>

> Le mercredi 24 juillet 2013 14:59:56 UTC+2, qua-non a �crit :

>
> Depends upon your app, and the way you have written it. Did
> you follow

> http://wiki.python.org/moin/__PythonSpeed/PerformanceTips
> <http://wiki.python.org/moin/PythonSpeed/PerformanceTips>.

> from it, send an email to kivy-users+...@__googlegroups.com.
>
> For more options, visit
> https://groups.google.com/__groups/opt_out
> <https://groups.google.com/groups/opt_out>.

>
>
>
>
> --
> You received this message because you are subscribed to the
> Google Groups "Kivy users support" group.
> To unsubscribe from this group and stop receiving emails from

> it, send an email to kivy-users+...@googlegroups.com <javascript:>.

> For more options, visit https://groups.google.com/groups/opt_out

> <https://groups.google.com/groups/opt_out>.

[Kovak]

If your use case as it sounds, mainly drawing several hundred textures and rotating each one, you will probably find much better performance doing this directly on canvas and avoiding scatter entirely. My guess is that you also do not actually have all 600 icons visible at once, at this would completely fill most screens. You will need to create some sort of spatial index such as a quadtree as mathieu suggested. For an example of the direct to canvas method: You can find the widgets for rendering many objects to screen on one canvas with a variety of indexing forms in my game engine here: https://github.com/Kovak/KivEnt/blob/master/kivent_cython/kivent_cython/renderers.pyx If you actually desire all of the behaviours of scatter, scatter might still be a better way to accomplish your goal, but if you only desire a subset of scatter behaviours in can be faster to do what you want on canvas.