2010-09-25 5 views
1

J'ai commencé à utiliser des objets Pixel Buffer et même si je comprends comment les utiliser et l'essentiel de ce qu'ils font, je ne sais vraiment pas ce qui se passe sous le capot. Je suis conscient que la spécification OpenGL permet une marge de manœuvre en ce qui concerne la mise en œuvre exacte, mais cela me dépasse toujours. Pour autant que je sache, l'objet tampon réside généralement côté serveur dans GRAM; Bien que cela puisse apparemment varier en fonction de cible et utilisation. Cela prend tout son sens car ce serait la raison pour laquelle les appels OpenGL sur les BOs fonctionneraient si vite. Mais dans quels cas cela résiderait-il dans AGP ou dans la mémoire du système? (question subsidiaire: le PCI-e a-t-il un équivalent de mémoire AGP?)Opérations internes OpenGL Buffer Object?

De plus, glMapBuffers() renvoie un pointeur vers un bloc de mémoire du BO afin que les données puissent être lues/écrites/changées. Mais comment est-ce que c'est fait? Les manipulations se déroulent côté client, donc les données doivent encore passer du serveur au client. Si c'est le cas, comment est-ce mieux que glReadPixels()? PBO sont évidemment mieux que glReadPixels() comme il est évident par la différence de performance, je ne comprends tout simplement pas comment.

Je n'ai pas encore utilisé les FBO, mais j'ai entendu dire qu'ils étaient meilleurs à utiliser. Est-ce vrai? si oui, pourquoi?

Répondre

0

Je ne peux pas vous dire dans quelle mémoire l'objet tampon sera alloué. En fait vous avez surtout répondu à cette question vous-même, alors vous pouvez espérer qu'un bon conducteur le fera de cette façon. GlMapBuffer peut être implémenté de la même manière que les fichiers mappés en mémoire. N'oubliez pas la différence entre la mémoire physique et l'espace d'adressage virtuel: lorsque vous écrivez dans un emplacement de mémoire, l'adresse est mappée via une table de pages vers un emplacement physique. Si la page requise est marquée comme permutée, une interruption se produit et le système charge la page requise à partir de la permutation vers la RAM. Ce mécanisme peut être utilisé pour mapper des fichiers et d'autres ressources (comme la mémoire GPU) vers l'espace d'adressage virtuel de votre processus. Lorsque vous appelez glMapBuffer, le système alloue une plage d'adresses (pas de mémoire, uniquement des adresses) et prépare les entrées appropriées dans la table de pages. Lorsque vous essayez de lire/écrire sur ces adresses, le système le charge/l'envoie au GPU. Bien sûr, ce serait lent, donc un tamponnage est fait sur le chemin.

Si vous transférez constamment des données entre CPU et GPU, je doute que les PBO seront plus rapides. Ils sont plus rapides lorsque vous effectuez de nombreuses manipulations sur le GPU (comme charger à partir du buffer d'image, changer quelques texels avec CPU et l'utiliser à nouveau comme texture sur le GPU). Eh bien, ils peuvent être plus rapides en cas de processeur graphique intégré ou de mémoire AGP, car dans ce cas, glMapBuffer peut mapper les adresses directement sur la mémoire physique, éliminant ainsi une opération de copie.

Les FBO sont-elles meilleures? Pour quoi? Ils sont meilleurs quand vous avez besoin de rendre à la texture. C'est encore parce qu'ils éliminent une opération de copie de données.

+0

donc si je fais un appel à glMapBuffer() le pointeur qu'il retourne peut être à une partie de mon espace d'adressage virtuel de processus qui mappe vers GRAM? –

+0

@ jay.lee: Oui de votre point de vue. Non dans le sens où il ne peut pas être un accès direct (sauf si GRAM est dans la RAM). Je ne sais pas s'il est possible de mapper directement le bus PCI sur votre mémoire. Je ne suis pas un gars de bas niveau. Sinon, il doit passer par un tampon supplémentaire. – ybungalobill