Qu'est-ce qui peut provoquer une réduction de la fréquence d'images lors de la mise à niveau d'une carte graphique?

Question

Nous avons une application DirectX à deux écrans qui fonctionnait auparavant à une vitesse constante de 60 FPS (le taux de synchronisation des moniteurs) en utilisant un NVIDIA 8400GS (256 Mo). Cependant, lorsque nous avons échangé la carte contre 512 Mo de RAM, la fréquence d'images peine à dépasser 40 FPS. (Cela n'atteint que des valeurs élevées car nous utilisons le triple buffering.) Les deux cartes proviennent du même fabricant (PNY). Toutes les autres choses sont égales, c'est une application Windows XP Embedded et nous avons commencé à partir d'une nouvelle image pour chaque carte. Le numéro de version du pilote est 169.21.

L'application est entièrement 2D. C'EST À DIRE. juste un tas de quads texturés et beaucoup de graphiques pré-rendus (d'où la nécessité de mettre à jour la mémoire de la carte). Nous avons également des animations compressées que le CPU décode à la volée - ceci implique un verrouillage de texture. Les verrous prennent une éternité mais j'ai également essayé d'avoir une texture de mémoire système séparée pour que le processeur mette à jour puis mette à jour la texture rendue en utilisant la méthode UpdateTexture du périphérique. Pas de différence globale de performance. Bien que j'aie lu toutes les FAQ que je peux trouver sur Internet à propos des performances de DirectX, c'est toujours la première fois que j'ai travaillé sur un projet DirectX, donc des connaissances obscures que vous possédez seraient utiles. :)

Une autre chose pendant que je suis sur le sujet; lors de l'appel de Present sur les chaînes d'échange, il semble que DirectX attende que le présent se termine malgré le fait que j'utilise D3DPRESENT_DONOTWAIT dans les deux paramètres présents (PresentationInterval) et les drapeaux de l'appel lui-même. Comme il s'agit d'une application à deux écrans, cela pose un problème car les deux moniteurs ne semblent pas être genlockés, je travaille autour de cela en exécutant les appels présents via un pool de threads. Quelle pourrait être la cause sous-jacente de cela?

Answer 1

Les cartes sont-elles exactement les mêmes (les deux GeForce 8400GS), et seule la taille de la mémoire est différente? Assez souvent, avec des tailles de mémoire différentes viennent des fréquences d'horloge légèrement différentes (c'est-à-dire que votre carte avec plus de mémoire peut utiliser une mémoire plus lente!). Donc, la première chose à vérifier serait GPU core & cadences d'horloge de la mémoire, en utilisant quelque chose comme GPU-Z.

Answer 2

C'est un test facile de voir si le verrou de surface est le problème, il suffit de commenter la mise à jour de la texture et de voir si le framerate revient à 60hz. Malheureusement, l'écriture sur une surface bloquée et la mise à jour de la ressource tue la performance. Utilisez-vous des mipmaps avec les textures? Je sais que DX9 ajouté la génération automatique de mipmaps, pourrait prendre beaucoup de temps pour les générer. Si vous verrouillez constamment la même ressource à chaque image, vous pouvez également essayer de créer un groupe de textures, un peu comme le triple buffer, sauf avec les textures. Vous laissez le rendu utiliser une texture, et à la prochaine mise à jour, vous choisissez la prochaine texture disponible dans le pool qui n'est pas utilisée pour le rendu. A moins bien sûr que votre mémoire soit contrainte ou que vous ne fassiez que des différences avec la texture animée.