Avez-vous expérimenté une situation dans laquelle C ++ OpenGL application fonctionne plus rapidement et plus fluide lorsqu'il est exécuté de Visual Studio? Lorsqu'il est exécuté normalement, sans débogueur, je reçois un framerate inférieur, 50 au lieu de 80, et une limite étrange, où les FPS plongeent environ 25 images / sectes de 20-30th. Y a-t-il un moyen de résoudre ce problème?
EDIT :
Nous utilisons également de nombreuses listes d'affichage (créées avec glnewlist). Et l'augmentation du nombre de listes d'affichage semblent augmenter la traîne.
EDIT :
Le problème semble être causé par les fautes de la page. Réglage du processus de fonctionnement du processus avec SETProcessworkingSetsIFEx () n'aide pas.
EDIT :
Avec quelques grandes modèles, le problème est facile à repérer avec l'utilisation de la mémoire GPU de ProceXP-utility. L'utilisation de la mémoire est très instable lorsqu'il existe de nombreux appels GLCalllist par image. Aucune nouvelle géométrie n'est ajoutée, aucune texture chargée, mais l'allocation de la mémoire GPU fluctue + -20 Mo. Après un moment, cela devient encore pire et peut allouer quelque chose comme 150 Mo en une fois.
3 Réponses :
C'est probablement le fil ou la priorité du processus. Visual Studio pourrait lancer votre processus avec une priorité légèrement plus élevée pour vous assurer que le débogueur est réactif. Essayez d'utiliser setPRiorityClass () A> Dans le code de votre application: SetPriorityClass(GetCurrentProcess(), ABOVE_NORMAL_PRIORITY_CLASS);
Seens raisonnable, mais quelle est la relation de votre réponse avec la différence de performance entre les versions de débogage / libération?
N'a pas aidé. Le taux FPS est toujours "instable" lors de l'exécution séparément de Visual Studio. BTW J'utilise toujours la version de version, mais j'exécute à Visual Studio ou normalement.
Également modifier la construction de setProcesspriorityBoost n'aide pas.
Je crois que ce que vous voyez est le débogueur enfermer certaines pages afin qu'ils ne puissent pas être échangés pour être immédiatement accessibles au débogueur. Cela apporte des mises en garde pour le système d'exploitation au moment de la commutation de processus et est en général non recommandé.
Vous ne voudrez probablement pas m'entendre dire cela, mais il n'y a pas de bon moyen de résoudre ce problème, même si vous le faites.
Utilisez des VBO ou d'au moins des tableaux de sommet, celles-ci peuvent être censées être optimisées beaucoup mieux dans le pilote (faire face aux listes d'affichage des affichages deviennent obsolètes). Les listes d'affichage peuvent être facilement enveloppées pour générer des tampons de sommet afin que seul un peu l'ancien code doit être modifié. En outre, vous pouvez utiliser "GRAPHIQUES" liés "qui a été conçu pour éviter les défauts de page du pilote (GL_EXT_DIRECT_STATE_Access).
Avez-vous une carte graphique nvidia par hasard? Nvidia OpenGL semble utiliser une implémentation différente lorsqu'il est attaché au débogueur. Pour moi, la version non-débogueur Feaking est une mémoire allant jusqu'à 1 Mb / sec dans certaines situations où je dessine sur le tampon avant et n'appelle pas Glclear chaque image. La version de débogueur est absolument bien.
Je n'ai aucune idée de la raison pour laquelle il a besoin d'allouer et (parfois) dérouler autant de mémoire pour une scène qui ne change pas.
Et je n'utilise pas les listes d'affichage.
Merci! Je confirme que les pilotes NVidia OpenGL ont une différence de performance substantielle (X100) entre la version et les versions de débogage dans certaines conditions. J'ai eu un projet OpenGL qui utilisait des animations à la peau et il fonctionnerait à .4fps sur deux machines Windows basées sur Nvidia différentes. Cependant, le projet fonctionnerait à environ 30fps sur des machines AMD ou sur le matériel NVIDIA de MacBook. Toutefois, sur les machines Windows / Nvidia si je faisais le projet avec la fenêtre du profileur d'unité ouverte, il accélérerait de .4fps à 30fps, et si je faisais l'autonome via un outil de débogage OpenGL, il fonctionnerait également à 30fps.
@ Hiazrizvi Je rencontre actuellement des problèmes similaires et je me demandais quel outil OpenGL de débogage que vous utilisiez?
C'était il y a quelque temps, mais je pense que c'était ce gratuit one OpenGL.org/sdk/Tools / gdebugger . Ma conclusion a été que les DLL OpenGL de Windows intégrées pour débogage, fonctionnent mieux que la version de version, pour les animations à la peau, car l'exécution du projet via l'outil de débogage entraîne une chargement des versions de débogage des pilotes OpenGL. Encore une fois, cela c'était il y a deux ans - pas sûr si c'est toujours le cas.
Exécutez-vous plein écran, vs pas en plein écran dans le débogueur? Cela indiquerait que la synchronisation V est activée.
Pas plein écran, mais maximisé. V-Sync doit être désactivé dans les deux cas. Parfois, je reçois des tarifs FPS plus de 100 ans et je suis toujours à la traîne.
Vous devez utiliser quelque chose comme un explorateur de processus pour voir quelles DLL sont chargées dans les deux cas et si la même DLL est chargée des chemins de différencage.
Tous les fichiers DLL semblent correspondre. Il y a quelques dlls qui ne sont présents que lors de l'exécution de Visual Studio: Audiodev.dll, wmvcore.dll, wpdshext.dll, gdiplus.dll, wmasf.dll, wmasf.dll. En théorie, cela ne devrait pas affecter la finesse du rendu OpenGL.
Lorsque vous exécutez le programme en dehors de VS, utilisez-vous la version de débogage ou la publication?
OpenGL.org/resources/faq/technical/displaylist.htm Ceci La FAQ suggère que la suppression de la mémoire est souvent une contrainte de performance avec des listes d'affichage. Votre application hérite peut-être de la priorité de la mémoire ou de la taille du cache du processus parent. Essayez de démarrer votre application en tant qu'administrateur ou à partir de la ligne de commande Visual Studio pour voir s'il y a une différence. Essayez également de regarder des paramètres de mémoire tels que des défauts de page dans le gestionnaire de tâches et de voir s'il y a une différence significative.
+1. J ai exactement le même problème.
@PETert: Oui, lors de l'exécution de VS, il n'y a pratiquement aucun défaut de page, alors que normalement, il y a environ 80 défauts de page par seconde. HMM, une idée de l'optimisation de l'allocation de la mémoire afin de minimiser les défauts de la page?
@Aarep essayez de définir la taille de jeu de travail avec
SETProcessworkingSetSetSIsize () à une grande valeur. N'oubliez pas de vérifier la valeur de retour pour les erreurs, car cette fonction risque d'échouer si vous ne faites pas attention.@RODRIGO: Je vais essayer, mais il semble que ces valeurs soient les mêmes dans les deux cas. J'ai ajouté Imprimer des valeurs getProcessworkingSetsizeex () et il n'y a pas de différence.
Et que se passe-t-il si vous exécutez le programme en dehors de VS, puis joindre le débogueur au processus d'exécution?
Vous n'avez pas fourni code source. Sans code source que vous pourriez aussi bien demander à Fortune-Teller.
Vous avez probablement mis en œuvre la fenêtre repeindre de manière inefficace - à l'aide de la minuterie ou de quelque chose de similaire, ou si vous calculez de manière incorrecte des FPS. Ou utilisez le sommeil entre les cadres et calculer le délai de manière incorrecte. Une application OpenGL opengl qui efface simplement la fenêtre et les tampons de swaps devraient donner 600..1200 FPS sur pratiquement n'importe quel ordinateur. Si vous n'obtenez pas que beaucoup de cadres, vous avez un problème de programmation quelque part et que la fenêtre de mise à jour / repeindre est inefficace (il faut se faire faire pendant le "traitement inactif" ou directement dans la boucle de message après PEEKMessage). Quoi qu'il en soit, il n'y a pas assez d'informations pour comprendre le problème.
"Et que se passe-t-il si vous exécutez le programme en dehors de VS, puis attachez le débogueur au processus d'exécution?" - Même résultat que l'exécution sans débogueur, les FPS sont en retard.
"Vous avez probablement mis en œuvre la fenêtre repeindre inefficacement" - j'ai chronométré l'exécution. Le temps inutile est passé des glicatlistes, lors du dessin de nombreuses listes d'affichage. Donc, le problème est dans ces défauts de page, qui ne se produisent que dans une exécution normale.
Pouvez-vous vérifier (avec ProcessExplorer) si le répertoire actuel et la ligne de commande sont exactement les mêmes dans les deux cas? En outre, vous avez vérifié que la plupart des DLL sont courantes dans les deux cas, mais avez-vous vérifié qu'ils chargent tous les deux exactement la même version des DLL? Notez que certaines DLL ont beaucoup de versions avec le même nom, mais également un répertoire différent (regardez la colonne "chemin", pas le nom, dans ProcessExplorer).
Aarep: Les appels de rendu chronométrant ne sont pas une bonne idée, car le rendu peut être effectué de manière asynchrone et être terminé après la fin de l'appel. Vous pouvez mesurer de manière fiable la durée entre les swaps tampons, mais c'est tout - toutes les autres données de synchronisation ne sont pas très dignes de confiance. Et encore une fois - si vous voulez de l'aide, postez le code source illustrant le problème.
Je crois que personne ne peut répondre à votre question, il existe des possibilités infinies, c'est inhabituelles et impossibles à traquer la question sans code source.