Discussion :

[gybe]

Le document de NVidia ne dit pas exactement ce que tu dis dans ton message. Si on ajoute le triple buffering à l'alternate frame rendering on peut avoir une latence très élevée, mais dans des situations normales cette latence n'est pas requise. Je comprends que tu aies pu utiliser un système très préci pour calculer ta latence, et je ne remets pas en cause les valeurs retournées par ce système, mais si ton application est mal conçue tu ajouteras par erreur un ou plusieurs frames de latence à ton système ce qui invalidera tes conclusions.

[ceydric]

Je ne crois pas que NVidia parlait du triple buffering dans leur article...
Cependant je veux bien croire qu'il y ait une coquille quelque part dans mon appli qui me rajoute une frame (ca fait 3 semaines que j'essaie de changer le moteur graphique sans succès)
Mais cependant, si c'est bien le cas (ce que je prefererai largement, honnetement) et si les drivers ne rajoutent pas implicitement une frame, l'exemple le plus simple au monde n'aurait pas le même probleme que mon appli.
Hors, le moindre petit exemple pris chez Nehe (entre autre) ou il n'y a qu'un carré blanc, me montre, encore une fois, l'existence de ces buffers.
Alors, je veux bien croire que des moteurs graphiques super évolués et super optimisés existent et supriment cette frame supplémentaire, mais je me demande vraiment quel est le truc magique qui permet cela ...
D'ailleurs, je suis loin de tout connaitre sur OpenGL et DirectX (c clair ) et je suis vraiment tres curieux de connaitre ce petit (gros) truc que peu de gens savent faire. D'ailleurs je crois avoir essayé toutes les commandes OpenGL existantes (les fences ne donnent pas mieux).
Peut-etre aurais-je plus de souplesse avec DirectX, ou en virant GLUT pour faire du code Windows entièrement, mais vu qu' un exemple simpliste windows ne donne pas mieux j'en doute ...

[ceydric]

En tout cas merci beaucoup de m'avoir lancé des pistes et expliqué l'enchainement logique de swap et de synchro CPU GPU. C'est vrai que c'est à ca que je m'attends, mais sans succès pour l'instant.

[gybe]

L'exemple très simple de nehe n'a aucune synchro.

essaie qqch comme ça:

Démarrage:

-Rendu Frame 0
-glSwapBuffer 0 -> la commande se fera au VSYNC, mais le GPU retourne la main au CPU
- glFinish qui bloque le cpu tant que le swapbuffer n'a pas terminé

VSync 0 :

- le swapbuffer 0 s'exécute, donc le glFinish débloque
- le frame 0 va commencer à être affiché
- Rendu Frame 1
- prendre le temps initial
- envoyer un événement à ton système avec photo diode pour calculer la latence
-glSwapBuffer 1 -> la commande se fera au VSYNC, mais le GPU retourne la main au CPU
- glFinish qui bloque le cpu tant que le swapbuffer n'a pas terminé

VSync 1 :

- le swapbuffer 1 s'exécute, donc le glFinish débloque
- le frame 1 va commencer à être affiché, donc ton système avec photo diode devrait détecter l'affichage et tu pourras calculer la latence.

[ceydric]

Oui, c'est vrai que j'ai bien relu hier soir ton post ou tu parlais de cette synchro et de la maniere dont les swap sont effectués.
J'espere que c'est bien la qu'est mon pb ...
En tout cas tu as clairement compris mon pb et cette réponse semble plausible dans mon cas, expliquant d'ou vient cette frame supplémentaire. Je vais refaire ma synchro pour modifier ca aujourd'hui. Merci beaucoup, si cela règle tout tu m'auras enlevé une sacrée épine du pied

[ceydric]

Ok, ca commence à donner quelque chose ...
Je n'avais pas réalisé jusqu'alors que le premier swapbuffer était exécuté immédiatement, le CPU pouvant continuer son chemin, et le GPU s'occupant de swaper tout seul, au VSYNC venu.
Donc effectivement, ma synchro étant mauvaise, je me retrouvais à demander un nouvreau swap, qui mettait alors mon CPU en attente, avec donc ce fameux lag constaté.
Merci du GRAND coup de pouce, avec ton explication nickel, ca m'a vraiment aidé à comprendre comment marchait le swap en concordance avec le VSYNC.
Bon ma sync n'est pas encore parfaite, mais j'arrive à constater des délais moins important déjà.
Encore un grand merci

[gybe]

ah c'est une bonne nouvelle ça

[shenron666]

Des nouvelles concernant OpenGL 2.1 qui pourraient intéresser ceydric et surement d'autres personnes :

Deux nouvelles extensions sont prévues. [...]
La seconde est nommée ARB_synch_object et apporte des perspective très intéressante au niveau de la synchronisation entre le CPU et le GPU. Jusqu'à présent, seuls deux mécanismes permettent de gérer cette synchronisation, glFinish et glFlush. glFlush force les commandes émises précédemment à commencer leur exécution et glFinish force l'achèvement de toutes les commandes OpenGL. Cette extension permet de force l'achèvement d'une partie du code. Par exemple, lors de l'upload des vertrices, cette extension permet de s'assurer que les données ont bien été envoyées dans la mémoire de la carte graphique avant de les modifier. Cette extension est basée sur NV_fence, disponible pour toutes les cartes nVidia depuis le GeForce 256.

Source : http://www.g-truc.net/ - News du 25/03/2006 - OpenGL 2.1 et futur

[ceydric]

Merci pour l'info shenron666, c'est intéressant et bon à savoir

[ceydric]

ReSalut a tous.
Dis moi gybe, j'ai un peu de mal à me faire une synchro nickel
J'ai essayé pas mal de trucs, comme un driver me permettant d'accéder au signal de vertical retrace de la carte graphique, où essayer de se mettre dans une fréquence de rafraichissement "sympa", mais les fréquences sont ce qu'elles sont et on n'aura jamais du 85Hz parfait.
La dernière idée, qui devrait marcher mais qui n'est pas la plus jolie, je dirais, c'est de récupérer le signal de synchro venant du pin 14 de ma carte graphique, pour le renvoyer sur un pin du port parallèle et donc le réintégrer dans mon soft. Le but étant de récupérer ce signal de synchro, à 1ms près, ca me va. Donc résultat je me retrouve à avoir un petit montage sortant du cable vga, avec un petit circuit pour augmenter le temps de présentation du Vsync de ma carte (qui ne dure que 30 microsecondes) afin d'etre sur de le capter par mon port parallele, en le faisant durer 1ms).
Vi c'est du bricolage, mais pour l'instant je seche quand a la manière de faire ca plus simplement.
T'aurais un tuyau sur une facon plus propre ?
Le probleme est que je ne dois pas passer trop de temps à chercher ce signal de synchro, j'ai beaucoup trop d'autres choses à faire et le traitement d'autres données ne doit pas etre perturbé par ca. Donc même l'utilisation d'un autre thread dédié à ca n'est pas envisageable. A moins d'avoir 2 CPU et de lancer le thread de vsync sur l'autre CPU, mais c'est pas mon cas...

[gybe]

hum, je ne suis pas vraiment spécialisé hardware. Tu connais ça sûrement beaucoup mieux que moi. Je ne connais pas non plus les ressources qui sont à ta disposition, mais s'il est possible pour toi de connaître à tout moment ton écart avec le VSync tu pourrais implémenter un mécanisme avec un timer ou avec des sleeps (du moment que le sleep ou le timer soit suffisament précis et qu'il soit temps réel) ce qui déchargerait ton CPU. Ton mécanisme va probablement te donner de meilleur résultat.

[ceydric]

Ouais, c'est bien ca le probleme, je n'ai pas de moyen de connaitre le temps du VSYNC, c'est pour ca que je vais passer par ce petit montage, pour effectivement utiliser un timer afin de ne pas surcharger mon CPU.
J'essaierai ca dans les jours qui viennent. On verra bien les résultats.

[LeGreg]

Si tu étais sous Direct3D tu pourrais utiliser

IDirect3DDevice9::GetRasterStatus
Returns information describing the raster of the monitor on which the swap chain is presented.

HRESULT GetRasterStatus(
UINT iSwapChain,
D3DRASTER_STATUS * pRasterStatus
);

Je ne sais pas s'il y a un équivalent OpenGL.

LeGreg

[ceydric]

Mince, c'est sympa ca, ca aurait vraiment été le top.
Des fois je me demande si j'aurais pas du me lancer dans DirectX plutot qu OpenGL ... mais bon si je veux faire tourner mon appli sous Linux en plus de Windows, ca aurait été quelque peu problématique ... a moins d'avoir deux moteurs, un en OpenGL et un en DirectX, mais bon deux fois plus de boulot ...
Merci en tout cas pour l'info. c'était pile poil ce qu'il me fallait, meme si je suis pas sou DirectX.

[Lightness1024!]

désolé d'arriver 4 mois après la bataille

mais il est possible de régler cette latence au niveau des pilotes chez nvidia sous le nom de "Max Frames to Render Ahead" (dans performance / quality)
et chez ati sous le nom "flip queue size". (réglable dans le tray tool il parait)

si ca peut marcher...