Auto-référencement de Renderbuffers dans OpenGL

Question

J'ai du code OpenGL qui se comporte de manière incohérente entre différents Matériel. J'ai du code qui:

1. Crée un tampon de rendu et lie une texture à son tampon de couleur (Texture A)
2. Définit ce tampon de rendu comme actif, et ajuste la fenêtre d'affichage, etc.
3. Active un pixel shader (flou gaussien, dans cet exemple).
4. Dessine un quad en plein écran, avec la texture A dessus.
5. Dissocie le tampon de rendu, etc.

Sur ma machine de développement, cela fonctionne bien et a le effet de flou sur la texture "en place", mais sur d'autres matériels cela ne semble pas fonctionner.

Je l'ai réduit à deux possibilités.

A) Rendre un tampon de rendu se rendre à lui-même n’est pas censé fonctionner, et ne fonctionne que sur ma machine de développement à cause d'un coup de chance.

Ou

B) Cette approche devrait fonctionner, mais quelque chose ne va pas.

Des idées? Honnêtement, j'ai eu du mal à trouver des précisions sur ce problème.

Answer 1

A) est la bonne réponse. Le rendu dans le même tampon tout en le lisant n’est pas défini. Cela pourrait fonctionner, mais pas nécessairement, ce qui est exactement ce qui se passe.

En ce qui concerne OpenGL, extension de framebuffer_object a section "4.4.3 Rendu lorsqu'une image d'un objet de texture lié est également jointe au framebuffer " qui raconte ce qui se passe (fondamentalement, non défini). Dans Direct3D9, le processus de débogage se plaint fort si vous utilisez cette configuration (mais cela peut fonctionner en fonction du matériel / du pilote). Dans D3D10, je pense que le runtime sépare toujours la cible utilisée comme destination.

Pourquoi c'est indéfini? Une des raisons pour lesquelles les GPU sont si rapides est qu’ils peuvent faire beaucoup d’hypothèses. Par exemple, ils peuvent supposer que les unités qui récupèrent des pixels n'ont pas besoin de communiquer avec les unités qui écrivent des pixels. Ainsi, une surface peut être lue, N cycles plus tard, la lecture est terminée, N cycles plus tard, le pixel shader termine son exécution, puis il est placé dans des tampons de fusion de sortie sur le GPU et, à un moment donné, il est écrit en mémoire. En plus de cela, les GPU rastérisent en " undefined " ordre (un processeur graphique peut rasteriser en lignes, un autre dans un ordre respectant le cache, un autre dans un ordre totalement différent), de sorte que vous ne sachiez pas quelles parties de la surface seront écrites en premier.

Vous devez donc créer plusieurs tampons. En cas de flou / éclat, deux suffisent généralement - restituer en premier, puis lisez & amp; flou que lors de l'écriture en seconde. Répétez cette procédure si nécessaire de manière ping-pong.

Answer 2

Dans certains cas particuliers, même le backbuffer peut suffire. Vous ne faites simplement pas glClear, et ce que vous avez dessiné précédemment est toujours là. La mise en garde est, bien sûr, que vous ne pouvez pas vraiment lire à partir de la mémoire cache. Mais cela fonctionne pour des effets comme le fondu enchaîné.