Comment l'état des tampons OpenGL peut-il persister entre les exécutions du programme?

J'écris un programme OpenGL qui dessine dans un Buffer Auxiliaire, puis le contenu du Buffer Auxiliaire est accumulé dans le Buffer d'Accumulation avant d'être GL_RETURN-ed dans le buffer Back (essentiellement pour être composé à l'écran). En bref, je fais une sorte de flou de mouvement. Cependant, la chose étrange est, quand je recompile et réexécute mon programme, je voyais le contenu du tampon auxiliaire/d'accumulation du programme précédent s'exécute. Cela n'a pas de sens. Ai-je mal compris quelque chose, l'état d'OpenGL ne devrait-il pas être complètement réinitialisé quand le programme redémarre?Comment l'état des tampons OpenGL peut-il persister entre les exécutions du programme?

J'écris un programme SDL/OpenGL dans les pilotes Linux Gentoo nVidia 195.36.31 sur GeForce Go 6150.

Source

2010-11-06 Lie Ryan

Non - il n'y a aucune raison pour que votre GPU à jamais clairement sa mémoire. Il est de votre responsabilité d'effacer (ou d'initialiser) vos textures avant de les utiliser.

Source

2010-11-06 08:20:13 EboMike

Merci, au moins maintenant je sais que ce n'est pas un comportement inattendu, même si c'est tout simplement effrayant ... –

Je suis d'accord. Vous voulez ajouter: dans certaines conditions, les pilotes vidéo sont invités à initialiser la mémoire allouée à zéro, en raison de considérations de «sécurité» (le programme malveillant peut vouloir savoir ce que les autres dessinaient). C'est ridicule (je dirais que ce devrait être la responsabilité de ce programme qui veut cacher sa production intermédiaire), mais c'est ainsi que les choses se passent. – valdo

J'ai fait beaucoup de Direct3D à travers l'ère DirectX9. Quand je commençais, les framebuffers, les surfaces, etc. étaient invariablement non initialisés et le code pouvait facilement exposer le contenu d'une exécution précédente. À un moment donné, Microsoft ou les fournisseurs de pilotes doivent avoir décidé de «réparer» cela et vous obtiendrez des tampons vides à la place. Je crois que cela a été fait au nom de la sécurité. Je dirais que les problèmes de sécurité sont valables; nous ne tolérerions pas un système qui remettrait aux RAM des processus utilisateur contenant les débris non nettoyés de l'autre utilisateur et la RAM du framebuffer ne devrait pas être considérée différemment. – timday

En fait, l'état OpenGL est initialisé à des valeurs bien définies. Cependant, l'état GL comprend des paramètres comme tous les commutateurs binaires (glEnable), le mélange, le mode de test de profondeur, etc., etc. Chacun de ces paramètres a ses paramètres par défaut, qui sont décrits dans OpenGL specs et vous pouvez être sûr qu'ils seront appliqués lors de la création du contexte.

Le point est, le framebuffer (ou les données de texture ou les vertex buffers ou quoi que ce soit) n'est PAS une partie de ce qu'on appelle "état GL". L'état GL "existe" dans votre pilote. Ce qui est stocké dans la mémoire GPU est totalement différent et il n'est pas initialisé tant que vous n'avez pas demandé au pilote (via des appels GL) de l'initialiser. Il est donc tout à fait possible d'avoir les restes de la précédente exécution dans la mémoire de texture ou même dans le tampon de trame lui-même si vous ne l'effacez pas ou ne l'initialisez pas au démarrage.

Source

2010-11-13 13:14:18 Kos

Comment l'état des tampons OpenGL peut-il persister entre les exécutions du programme?

Répondre

Questions connexes