D'après-vous est-il possible de copier le contenu d'une texture en mémoire vidéo, vers une autre texture en mémoire vidéo, sans passer par la mémoire système? Ceci bien sûr tout en supportant les textures compressées.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Copier le contenu d'une texture vers une autre texture.
D'après-vous est-il possible de copier le contenu d'une texture en mémoire vidéo, vers une autre texture en mémoire vidéo, sans passer par la mémoire système? Ceci bien sûr tout en supportant les textures compressées.
je ne vois pas l'interet, mais tu doit pouvoir passer par un render to texture...
autant utiliser le multitexturing
sinon, tu peux nous dire un peu l'idée qui te passe par la tête ?
J'ai une quantité de mémoire fixe allouée pour les textures, donc au démarrage de l'application j'alloue un certain nombre de 2048x2048, 1024x1024, 512x512 , etc..., je ne peux pas les supprimer ensuite, et je dois faire des glTexSubImage pour remplir le contenu de ces textures en fonction des objets rendus dans la scène. De cette façon mon application est plus performante et je diminue les probabilités de glith pendant le rendu.
Lorsqu'un nouvel objet est ajouté à la scène, je charge le contenu de ses textures en mémoire en utilisant une ou plusieurs des textures non-utilisées. De la même façon, lorsque cet objet sort de la scène, ses textures sont marquées comme non-utilisées et peuvent être utilisées par d'autres objets.
Maintenant lorsqu'un nouvel objet est ajouté à la scène, ce ne sont pas tous ses mipmaps qui sont chargés en mémoire, mais seulement ceux qui sont requis en fonction de la position de l'objet. La raison ici n'est pas de diminuer le temps de chargement, mais bien parce que pour une scène donnée je n'ai pas suffisament de mémoire vidéo pour allouer tous les mipmaps de tous les objets.
Donc lorsque l'objet se déplace, il est possible que les mipmaps plus détaillés, que je n'avais pas chargés lorsque l'objet est entré dans la scène, deviennent requis. Dans ce cas je dois utiliser une texture de plus grande dimension et charger tous les mipmaps. C'est ici que j'aimerais être capable de copier directement de texture à texture, car le contenu des mipmaps les moins détaillés est déjà en mémoire vidéo dans la texture que j'avais initialement.
Bien sûr le render to texture ne fonctionne pas, car comme je l'ai spécifié plus tôt on ne peut pas rendre dans une texture compressée. On ne peut pas non plus faire un CopyTexImage dans une texture compressée, car son contenu ne sera plus compressés.
Le mipmapping n'est pas obligatoire, si tu es limité en mémoire vidéo tu peux toujours le désactiver, essayes au moins une fois sans pour voir ce que donne le rendu, selon les textures utilisées il n'est pas toujours utile
en tout cas ton idée de préallouer des surfaces avant de t'en servir n'est, de mon point de vue, pas très logique et encore moins intéressante
Le mipmapping est obligatoire si tu veux avoir une bonne qualité d'image.Envoyé par shenron666
Pour ce qui est de préallouer les surfaces, c'est certain que je ne me suis pas levé un matin en me disant que j'allais essayer cette solution. Ça vient d'une longue analyse, et c'est un des points qui me permettra d'avoir de meilleures performances et un plus grand déterminisme.
Je ne comprend pas ce qui t'a poussé à avoir cette idée donc désolé de buter là dessus, mais je ne vois pas où est le gain de performance que tu obtiens à préallouer tes textures et ensuite devoir faire des transferts de texture à texture
je n'ai jamais fait de test concernant ce genre de situation donc tu m'apprendrais peut-etre bien quelque chose
à propos de ton rendu, c'est du temps réel ? ça m'a l'air gourmand en resources, tu pourrais en dire plus à ce sujet ?
Oui, oui c'est du temps réel. D'ailleurs je doit toujours rouler à 60 fps sinon c'est un bug. Le seul temps de chargement alloué est au démarrage de l'application. Je ne peux donc pas arrêter le rendu lorsque l'utilisateur se déplace et afficher "loading" pour charger toutes les ressources qui non pas été alloués. La quantité de donnée qui peuvent possiblement être affichées est très importante(plusieurs Go), beaucoup plus grande que ce qui peut être contenu par la carte vidéo. Je dois donc continuellement ajouter et enlever du contenu sur la carte vidéo, et ce toujours à 60 fps.
En allouant toutes mes textures au début et en ne les supprimant jamais, je diminue de beaucoup les chance que des glitchs de plusieurs millisecondes se produisent dû à l'allocation de surface en mémoire vidéo. Il y a donc moins de chance que je tombe en bas de 60 fps.
En étant capable de copier le contenu d'une texture vers une autres texture, j'évite l'overhead important lié à la copie de mémoire système vers la mémoire vidéo. Je peux donc transférer plus de donnée à chaque itération, avec un même budget de chargement de texture.
je ne voit vraiment pas comment tu peut gagner des perf en copiant des textures dans d'autres textures alors que tu ne sait même pas si le driver va te les mettre en memoire video ou en memoire central... il ne faut pas oublier qu'en openGL, tu ne peut pas savoir ou sont placé les textures, c'est le driver qui decide...
de plus, il sera toujours plus rapide d'envoyer une texture deja alloué en memoire central vers la memoire graphique que de changer le contenu d'une texture... dans le premier cas, tout les calcules sur la texture sont deja effectué, alors que dans le second cas ils ne le sont pas...
Peu importe où se trouve la texture en mémoire, si elle est en mémoire centrale, il sera toujours plus rapide de la copier directement de mémoire centrale à mémoire centrale que de la charger à travers l'API d'OpenGL
Je n'ai pas suffisament de mémoire centrale pour allouer toutes les textures de l'application. Si je ne m'alloue pas un budget pour les textures, je serai obligé d'ajouter et supprimer des textures pendant le rendu pour éviter les out of memory. Ces opérations de création et de suppression sont coûteuses, alors que le chargement d'une texture peut être réparti sur plusieurs frames ce qui me permet de rencontrer mes contraintes de temps.
le probleme n'est pas la copie de memoire central a memoire central, c'est d'envoyer de la memoire central à la memoire graphique...
si tu n'a pas assez de memoire central pour stocker tes textures, inutile d'essayer de feinter, la seul methode utilisable est de baisser le niveau de detail des textures... (ou de compter sur la memoire virtuelle)
non, non ça ne s'appelle pas essayer de feinter, ça s'appelle trouver une solution au problème. Tout ce dont je te parle ici fonctionne déjà, mon but n'est pas de prouver que ça fonctionne, mon but est seulement d'accélérer une partie des transferts en copiant de texture à texture directement.
à part utiliser glTexImage2D et/ou glTexSubImage2D je ne vois pas
regardes la doc opengl au sujet de ces fonctions voir si elles te sont utiles
sinon il n'y a pas, à ma connaissance, de fonction de copy de texture à texture directement
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager