Discussion :

[alpha_one_x86]

Bonjour,

Sur mon Core i5 en full HD avec ma carte graphique Intel graphic, J'ai fait:

https://github.com/alphaonex86/Catch...atedbackground

15-20% de CPU.

https://github.com/alphaonex86/Catch...atedbackground

5-8% de CPU

Cela semble vraiment très haut pour un simple background défilant.

Es normal ou pas? Quel chiffre puis-je espérer en OpenGL pur? Peu être avez vous un moteur de jeux à me conseiller en argumentant sur les performances pour ce genre de cas.

Cordialement,

[Kannagi]

Ben avec un Intel graphic n’espère pas faire du full HD , il te faut une bonne Carte graphique pour ça
Moi perso cela me choque pas (surtout que bon y'a pas de VRAM dédié , alors ce genre de truc se fait avec un bus partagé avec le coeur principal du x86/x64).

Sinon OpenGL n'est pas le meilleur pour avoir les meilleur perf , Vulkan te permettra d'avoir de bien meilleur perf (mais bon pas sur qu'on peut faire du Vulkan avec un Intel graphic).

[LittleWhite]

Bonjour,

Pouvez-vous préciser la génération de votre i5 (le numéro qui en suit, par exemple i5 8250).
Les HD Graphics supportent Vulkan (à partir du HD Graphics 520, semble t-il ( https://vulkan.gpuinfo.org/ )).

Vous utilisez Qt et Qt fait pas mal de chose en fond. Donc c'est dur à dire ce qui se passe. Notamment, au lancement de Qt, vous pouvez changer l'API utilisée pour la 3D (DirectX/OpenGL/Software).
L'équipe de Qt a aussi fait des conférences sur les performances (notamment sur les jeux) avec Qt.
Et sinon, il y a le moteur VPlay (qui a changé de nom ) qui est étroitement lié à Qt, qui pourra vous intéresser (mais niveau perf, je ne sais pas).

[alpha_one_x86]

Kannagi:
Trés bizard ce que tu dit, ca veut dire que je ne devrai pas pouvoir voir une video full HD, et jouer à des jeux 3D en full HD, hors je n'est aucun problème avec cela.

LittleWhite:
Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz
vulkan est trop bas niveau, les temps de draw avec Qt sont de 1ms, soit 1000FPS téorique.

[LittleWhite]

En effet, Vulkan est très bas niveau, mais il enlève la surcouche du pilote exécuté sur le CPU et c'est sur ce point que vous reposez.
Avez vous une mesure du draw avec une précision en dessous de 1ms ?

Après, vous pouvez toujours utiliser un profiler et voir où cela pêche, mais avec une surcouche comme Qt, il ne faut pas s'étonner qu'il y a une certaine surcouche sur le CPU. D'où, d'après moi, la différence entre les deux exemples. Toutefois, utiliser la simple charge CPU (et j'imagine que vous avez isolé votre processus et que ce n'est pas la charge globale du système) ne me semble pas être une mesure convaincante. Vous pouvez très bien rester à ~10%, alors que vous allez afficher 100 sprites de plus.

[Kannagi]

Une vidéo HD oui ça demande moins de puissance , par contre un jeu en full HD ça m’étonne plus deja que la PS4 à du mal à faire du HD en 60 FPS
Franchement la puissance du Intel HD Graphics 530 , je l'estimerais vers une Radeon HD 5670/ GeForce GT 640 (perso je l'estimerais encore moins).
Et c'est pas des CG qui font du HD

[alpha_one_x86]

Sauf que la on parle d'un sildeshow pour la demo, juste d'image qui défile.

Et pour le jeu final, je pense pas aller plus loin que un jeu NES, voir super NES, pas d'effet, juste des sprites basiques.

Au MAX mais en full HD, avec la loie de moore, les puissances ont été multiplier par 32768 depuis ces 30 dernières années:


La plus part de jeu similaire tourne sans problème avec moins de 5% de CPU:

[Bousk]

Le CPU va mettre à jour le jeu et envoyer les commandes au GPU.
Le CPU pourra au mieux être assez rapide pour ne pas ralentir le GPU, mais il doit travailler avec le GPU qui doit pouvoir maintenir X fps @ Y resolution.
Et bien sûr ça va dépendre de combien de sprites tu affiches, comment tu les stockes et tries, etc.

[Kannagi]

Si c'est pour un jeu 2D basic , il fallait le preciser !

Je pense pas aller plus loin que un jeu NES, voir super NES, pas d'effet, juste des sprites basiques.

Vu le screen que tu met c'est plus qu'une Nes.
Et bien plus que ce que pourrait faire un SNES aussi

[LittleWhite]

Faire du 5% sur le CPU, c'est facile. Il suffit de se limiter à 60 images par seconde (ou trente) et de mettre un sleep pour le temps qui reste. Ainsi, la charge CPU pour votre programme est libérée et vous voyez bien un 5% (ou même un 1%) sur le moniteur système.
C'est pour cela, que je trouve que la mesure n'est pas super représentative (je suis plus pour une mesure en microseconde, du temps du rendu). De plus, Qt fait pas mal de choses en fond, donc une certaine surcharge.

[alpha_one_x86]

Ok, merci a tous pour les info.

LittleWhite: pour l'instant je me suis limité a 20FPS et 3 sprites et pourtant j'ai 15% de CPU.
Donc je vais regarder d'autre piste (comme themanaworld: SDL2)

[LittleWhite]

LittleWhite: pour l'instant je me suis limité a 20FPS et 3 sprites et pourtant j'ai 15% de CPU.

Arf, quand même. Enfin, si ce ne sont pas des sprites plein écran, c'est inquiétant. Un profileur pourrait aider à mieux comprendre la raison, mais ça risque d'être caché dans les entrailles de Qt.

J'allais ajouté que, une telle consommation ne peut arriver que si vous faites des opérations autre que du rendu dans le pain() et lorsque je me suis un peu replongé dans le code je vois :

Code qt :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
void CCBackground::paint(QPainter * paint, const QStyleOptionGraphicsItem *, QWidget * widget)
{
    QTime time;
    time.restart();
    unsigned int targetZoom=getTargetZoom(widget);
    if(zoom!=targetZoom)
    {
        //std::cout << "new zoom: " << targetZoom << " with " << width() << "*" << height() << std::endl;
        cloud=QPixmap(":/cloud.png");
        if(cloud.isNull())
            abort();
        grass=QPixmap(":/grass.png");
        if(grass.isNull())
            abort();
        sun=QPixmap(":/sun.png");
        if(sun.isNull())
            abort();
        treeback=QPixmap(":/treeback.png");
        if(treeback.isNull())
            abort();
        treefront=QPixmap(":/treefront.png");
        if(treefront.isNull())
            abort();
        if(targetZoom>1)
        {
            scalePix(cloud,targetZoom);
            scalePix(grass,targetZoom);
            scalePix(sun,targetZoom);
            scalePix(treeback,targetZoom);
            scalePix(treefront,targetZoom);
        }
        grassMove=rand()%grass.width()*targetZoom;
        treebackMove=rand()%treeback.width()*targetZoom;
        treefrontMove=rand()%treefront.width()*targetZoom;
        zoom=targetZoom;
    }

Chargez vous les images à chaque frame ? Faites vous le redimensionnement à chaque frame ?
Je vous conseille cette lecture. En bref : dans la méthode draw/paint() ne faites que les opérations de rendu (soit, les drawPixmap) et rien d'autres. Dans un programme simple, ça ressemble à :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
Pour tous les sprites
   afficher le sprite à la position voulue

[alpha_one_x86]

En fait c'été due au theme oxygen, je passe sur fusion de Qt, et bof je tombe a 2% de CPU...

[LittleWhite]

Ah, bien joué !
Avec les deux programmes du départ vous obtenez 2% ?

[alpha_one_x86]

Avec Qt Widgets, j'ai pas tester avec l'autre.
Et encore 2% car je cache pas le draw du texte.