[D3DPRESENT_PARAMETERS] UINT PresentationInterval

Bonjour,
J'aurais aimé avoir quelques renseignements. Voila dans la structure D3DPRESENT_PARAMETERS il existe UINT PresentationInterval.
J'ai lus ceci sur cette variable:

Citation:

---

PresentationInterval determines the maximum rate that the back buffers can be presented. The default, which is required for windowed devices, is D3DPRESENT_INTERVAL_DEFAULT. When you use fullscreen devices, you can either use the default or D3DPRESENT_INTERVAL_IMMEDIATE, which just waits for the vertical trace.

---

Ce que je ne comprends pas c'est pourquoi il y a une différence sur le nombre maximum de fois ou peut être présenté le backbuffer, que l'on soit en fenêtrer ou en plein écran. Je ne comprend pas trop le but et le principe de cette variable.
Si quelqu'un a une explication à me fournir :)
merci.

Cela fait un moment que j'ai arrêté DX9, mais je confirme qu'il était possible d'utiliser D3DPRESENT_INTERVAL_IMMEDIATE en mode fenêtré. Des artéfacts visuels risquent d'apparaitre, comme en mode plein écran. La doc du dernier SDK le confirme:

Citation:

---

Envoyé par D3DPRESENT

D3DPRESENT_INTERVAL_IMMEDIATE
The runtime updates the window client area immediately and might do so more than once during the adapter refresh period. This is equivalent to using D3DSWAPEFFECT_COPY in DirectX 8. IDirect3DDevice9:: Present operations might be affected immediately. This option is always available for both windowed and full-screen swap chains. See remarks.

---

Citation:

---

Windowed mode supports D3DPRESENT_INTERVAL_DEFAULT, D3DPRESENT_INTERVAL_IMMEDIATE, and D3DPRESENT_INTERVAL_ONE.

---

Je ne vois pas d'explication à l'extrait de doc ci-dessus. Vient-il d'un SDK datant de plusieurs années?

Il s'agit d'un tutoriel de gamedev.net http://www.gamedev.net/reference/art...rticle1943.asp
Il a pour but de montrer comment créer une Fenêtre Windows, d'initialiser le device de créer D3D, faire un rendu et détruire le device et D3D.
Quand tu me dit

Citation:

---

Des artéfacts visuels risquent d'apparaitre, comme en mode plein écran.

---

Tu entend quoi par la? il affichera des objets qui sont dans le tampon suivant? précédent? Quel est le but de mettre a jour le contenu fenêtre plus souvent que le taux de rafraichissement de l'écran?
merci

Merci pour le lien. Il s'agit donc soit d'une erreur de l'auteur, soit d'une modification du comportement de DX9 depuis que l'article a été écrit (il y a plus de 5 ans tout de même). Les extraits ci-dessus datent du dernier SDK de Juin 2008, donc sont certainement plus fiables que l'article.
Les problèmes visuels viennent du décalage entre les positions d'un objet entre 2 frame buffers. Si par exemple on a un objet qui tourne sur lui-même, et que le taux de rafraichissement est de 60 Hz pour l'écran et 61 Hz pour le FB, on voit la position suivante de l'objet en bas de l'image (pour un faisceau balayant de haut en bas) et la position courante en haut, avec une ligne pas franche de séparation (selon à quel pixel la coupure se produit, ce qui varie à chaque image). Pire, cette ligne monte lentement au cours du temps, à la vitesse moyenne d'un écran par minute...
Avec les écrans modernes, le rafraichissement de l'image est différent. Je ne suis pas au courant des techniques de rafraichissement pour les LCD, mais par analogie avec d'autres dispositifs électroniques je suppose que l'image est rafraichie en parallèle sur un certain nombre de bancs, d'après un échantillonnage du FB instantané par rapport au temps de réponse des cristaux liquides. Donc je pense qu'on ne peut plus voir apparaitre ces problèmes: les images intermédiaires sont tout simplement perdues. Il n'y a aucun intérêt à le faire, bien sur, mais c'est au moins c'est non nocif, contrairement à ce qui se produisait avec les vieux écrans.

Citation:

---

Envoyé par Astraya

Ce que je ne comprends pas c'est pourquoi il y a une différence sur le nombre maximum de fois ou peut être présenté le backbuffer, que l'on soit en fenêtrer ou en plein écran. Je ne comprend pas trop le but et le principe de cette variable.

---

Bon plusieurs choses:
- l'intervalle "default" n'est pas obligatoire en mode fenetre. Il faut prendre les articles gamedev.net avec des pincettes puisque n'importe qui peut publier sur le site (un peu comme Wikipedia sauf que les articles "out of date" ne disparaissent pas du site ou sont difficiles à corriger). C'est le cas pour tout article sur le web et les posts sur les forums (voire les bouquins).. Bref tout prendre avec esprit critique et recouper les infos.

- La différence entre default/immediate/one est expliquée dans la doc : le mode DEFAULT est le même que le mode ONE, la différence c'est que le mode ONE va aussi appeler timeBeginPeriod pour améliorer la résolution du timer système (par défaut 5/10/15 ms sur certains PC, peut-être réduit à 1ms avec timeBeginPeriod). L'appel a timeBeginPeriod va rendre les process switches plus coûteux parce que plus fréquents donc à n'utiliser que si cela améliore vraiment les choses : préférer DEFAULT, mais si besoin utiliser ONE (et appeler si besoin explicitement timeBeginPeriod pour régler ses propres problèmes de timing non liés à l'affichage). Les modes ONE/DEFAULT diffèrent de IMMEDIATE parce qu'ils attendent pour la synchronisation verticale. La synchronisation verticale est le moment où le balayage écran est fini et donc on peut changer la position du buffer affiché sans "tearing" (le tearing est quand la partie haute de l'écran affiche la frame N, la partie basse affiche la frame N+1 avec une déchirure au milieu, le vsync arrive juste avant que le balayage ne passe du bas vers le haut et donc la ligne de coupure n'est pas visible). Le tearing sans vertical sync est présent sur tout type d'écran, même les plus modernes, le balayage écran étant une réalité qui ne va pas disparaître demain : les programmes PC n'ont aucun contrôle sur le rafraichissement y compris sur écran LCD ! De plus comme la présentation en mode fenêtré est fait avec un BLIT (copy bit à bit) et non un FLIP (simple switch du DAC), même si il n'y avait pas de balayage le rafraichissement d'écran non synchronisé pourrait avoir lieu au milieu de l'opération de copie. C'est d'ailleurs à cause de cette opération de copie que la présentation en mode fenêtrée est un "best effort" (meilleur effort comme on dit par chez nous) et donc du tearing peut tout de même apparaître (même si le démarrage de la copie est synchronisée, la copie elle-même est non synchronisée). C'est réglé sous Vista avec le mode de bureau AERO glass accéléré qui utilise le mode de présentation FLIP pour supprimer complètement la possibilité de tearing en mode fenêtré (le tearing peut toujours arriver en mode plein écran sous VISTA si l'application a choisi explicitement de ne pas synchroniser verticalement). Le tearing n'est pas la même chose que le flickering/flashing (clignotement) qui sont généralement lié à l'absence de double buffer. Le flickering/flashing sont impossible à réaliser sous Direct3D (sauf par un effet volontaire ou par un code très bogué).

LeGreg

Ok! merci pour tout à vous deux.
Donc moi étant débutant dans ce genre de discipline :roll: il me faudrait mettre le mode défaut, si je ne veut pas avoir à gérer les timer services(Mode IMMEDIATE) et mes programmes n'étant pas des "bêtes de monstres affamées" demandant des temps de copie dans le buffer très long le mode ONE ne me sera pas d'une grande utilité.

J'espère avoir bien synthétisé?

DEFAULT : on s'occupe de rien, le mode s'occupe d'attendre la fin de l'affichage pour swap les backbuffers.(On s'occupe de rien, tu t'occupe de tout:aie:)
ONE : On s'occupe de rien, le mode s'occupe d'attendre la fin de l'affichage pour swap les backbuffers mais va appeler automatiquement timeBeginPeriod ce qui va accélérer le balayage vertical mais demande beaucoup plus de ressources systèmes.
IMMEDIATE : attention les dégâts si la fréquences de synchronisation des buffers et de l'affiche est différente.

ce que je ne comprend pas c'est ce que tu entend LeGreg par

Citation:

---

L'appel a timeBeginPeriod va rendre les process switches plus coûteux parce que plus fréquents

---

Quesque tu entend par process switches? vocabulaire que je ne connais pas:(

Donc quand je coche par exemple "synchronisation verticale" dans un programme cela sous entend que le mode est ONE et que je demande a faire appel a timeBeginPeriod et timeEndPeriod pour stopper le tearing c'est ça?

Citation:

---

Envoyé par Astraya

Quesque tu entend par process switches? vocabulaire que je ne connais pas:(

Donc quand je coche par exemple "synchronisation verticale" dans un programme cela sous entend que le mode est ONE et que je demande a faire appel a timeBeginPeriod et timeEndPeriod pour stopper le tearing c'est ça?

---

timeBeginPeriod n'a qu'une relation très lointaine avec le tearing..

Pour résumer : ton OS est un OS multitâche, c'est à dire qu'à un moment donné il y a N applications différentes qui peuvent s'exécuter : on va les appeler Processus (process en anglais) - même si théoriquement application et processus peuvent être différents -, et à l'intérieur de chaque processus il y a des fils d'executions différents (thread en anglais) qui s'exécutent en parallèle. Comment l'OS fait cela ? Et bien il va diviser le temps d'execution processeur en tranches. Si application A et B tournent en même temps : il va donner la première tranche d'execution à A, puis la deuxième tranche à B etc. Si les tranches sont petites alors pour l'utilisateur c'est effectivement comme si A et B s'exécutaient en simultané. Les threads natifs et la gestion des process de l'OS est indépendant du nombre de cores du CPU, il y a peu la plupart des PC vendus avaient un CPU avec un seul core.
Le truc c'est que le multitâche est invisible pour l'application, ce qui facilite la programmation d'applications mais complique l'OS qui doit empêcher une tâche de prendre plus de temps que sa tranche. Il fait ça en lançant des interruptions toutes les n nanosecondes (via un timer interne), lorsque l'interruption arrive, meme si l'application A n'a pas fini sa tache courante, on l'interrompe et on donne la main à l'application B.
Bien entendu ce changement est relativement coûteux (en temps processeur, ça arrive tout de même des centaines de fois par secondes) : il faut sauver l'état de A (son contexte) pour que quand B a fini, A puisse reprendre comme si de rien n'était. Ce coût doit donc être amorti sur un grand nombre d'instructions pour pouvoir être négligé. Si on fixe chaque tranche à 10ms, cela donne un bon paquet d'instructions exécutables avant d'avoir à changer de contexte.

Seul problème, cette division en tranche de 10ms est plutôt bonne pour les applications génériques et les serveurs (ce pour quoi NT/2K étaient chargé à la base) mais elle est mauvaise pour toute application qui nécessite un timing très précis (temps réel, rendu vidéo etc). En effet une application qui passe la main, n'est pas sûre d'être rappelée avant N * 10ms, N le nombre d'applications qui attendent leur tour pour être exécutées. Si tu n'as pas besoin de beaucoup de temps de calcul CPU (attente active) mais tu aimerais être prévenu d'un évènement avec un délai court (moins de x millisecondes) alors ce n'est pas idéal.
Mais en échange quand tu passes la taille de chaque tranche à 1ms à la place de 10ms (par exemple), tu causes un process switch toutes les 1ms au minimum soit dix fois plus souvent, et le coût de l'échange peut donc être amorti sur beaucoup moins d'instructions qu'avant. D'où le coût CPU supplémentaire à charge apparemment équivalente. À toi de voir si tu te trouves dans la situation où la granularité du process switch te pose un problème. Par ailleurs en mode exclusif (seul le jeu s'exécute et pas d'autres process) ce n'est pas dit que ce soit nécessaire.

J'espère que c'est à peu près clair.

LeGreg

Ok merci je vois parfaitement de quoi. j'avais pas fait le rapprochement avec le terme anglais.
Etant donné le programme:

Code:

---

1 2 3 4

while(1) { PeekMessage(...)... }

---

le processeur est demander à "99%" enfin du moins il prendra tout le processus inactif pour lui et laissera le minimum selon les règles de process switch au autres programmes. Donc l'avantage d'augmenter la résolution de timer système est de donné plus souvent le processeur à mon application mais moins longtemps pour que l'effet "temps-réel" soit plus significatif.
L'application ne se verra pas plus rapide en exécution pour autant puisque elle n'aura pas plus de temps de calcul a sa disposition!
donc le faite de mettre à 1ms le CPU servira a récupérer plus souvent le contexte. Ce qui permettra de vérifier toute les 1ms que les calculs de la trame sont finis et ainsi on PEUT éviter le tearing si le backbuffer n'a pas a attendre les 9ms restante et peut swap les buffers dès que le calcul processeurs est fini a 1ms près au lieu de 10ms c'est ça?