Discussion :

[Invité]

Ok, je pensais faire des tiles semi-transparentes d'eau ou bien de sable qui se croisent pour faire des effets de "submersion" ou bien de "tremblement de terre" ou tout autre effet qui pourrait être sympa (du genre une partie d'une tile d'eau qui submerge le sable et inversément, ainsi, je peux faire varier la quantité d'eau et de sable en 2D de manière très simple) mais malheureusement je me suis rendu compte que ça ne fonctionnera pas avec un seul draw call si image load store ne fonctionne pas.

De plus pas moyen de faire des per-pixel-linked-list sans ça. :/

En fait je voudrais faire un terrain qui change en fonction du climat. (Sans utiliser de particules car cela serait trop coûteux. :/)

[LittleWhite]

Pour du changement de terrain suivant le climat (qui est classe), je pense à la méthode naïve : le multitexturing ou le shader.
http://www.pouet.net/prod.php?which=52938

[maeiky]

Si on laissait ce problème de transparence de côté car de toute façon je ne peux pas avancer là dessus pour l'instant. (Même si il y a des solutions que tu m'as déjà donna comme par exemple le tri, ça pose problème pour les scènes plus complexe avec nécessité de décomposer les polys qui s'entrecroisent (ce qui surcharge trop le CPU))
D'ou la nécessité de faire un tri par fragments au niveau du GPU!

Et pour la solution du OIT par Weight, que je t'ai donné il y a presque un an?

https://mynameismjp.wordpress.com/20...d-blended-oit/

[Invité]

Si je regarde bien le code de la méthode du weight il faut dessiner tout les objets opaques avant de dessiner les objets transparents donc il y a aussi besoin de faire un tri.

Avec ma méthode il n'y a pas de tri à faire, à part le fait qu'il faut juste que je balaie l'écran toujours dans le même sens, sinon, je n'ai pas la même couleur au blending, mais ça s'est rapide à faire et ça se fait à l'aide de deux boucles for qui parcourent les axes x et y de la bouding box du champ de vision de la caméra dans le monde ce qui est très rapide au niveau du CPU, mais bien trop coûteux pour me permettre de faire un tri (si je travaille avec des coordonnées négative ou bien des flottants), à part cela, peu importe la valeur de z, que j'ai 10 tiles, 20, ou 30, et que je change leur z, les couleurs au blending restent les mêmes. (J'ai tester)
Même en 3D je compte faire des rendus à base de tiles car je trouve cela beaucoup plus simple à mettre en place.

Le weight semble donc plus complexe à mettre en place hors que moi je veux rester dans la simplicité. (Avec image load store ça sera parfait)

De ce fait j'optimiserai les appels CPU->GPU en réduisant le nombre d'appel à draw sans surcharger le CPU avec des tris ou bien du découpage de polygones.

PS : je ne veux pas faire du muli-texturing non plus.

[Iradrille]

Si je regarde bien le code de la méthode du weight il faut dessiner tout les objets opaques avant de dessiner les objets transparents donc il y a aussi besoin de faire un tri.

Le tri est fait une fois : au chargement du niveau tu stock tes objets dans 2 conteneurs en fonction de s'ils sont opaque ou non.
Hop, 0 tris au runtime.

Le weighted OIT, j'y avait jeté un oeil, ça semble bien plus simple que des listes chainées.

[Invité]

Ok, il faudra que j'essaye cela une fois que j'aurai plus de temps ...

Cette technique semble intéressante mais n'impose t'elle pas aussi de devoir faire du readback ?
Car je vois des appels à texelFetch dans le code, ça fait quoi exactement ?

Bref du readback j'ai besoin d'en faire également pour générer une texture de profondeur de la scène dans le but de calculer l'éclairage donc je ne pourrai quand même pas faire cela avec un seul draw.

Donc le weitghted blending ne résoudra pas tout les problèmes. :/

Hors que avec imageloadstore je pourrai générer une depthtexture et une shadowmap avec un seul draw call. (Chose que je souhaiterais faire pour optimiser le FPS de mon moteur)

Je vais essayer d'installer ubuntu 15.4 en espérant qu'il intègre les nouvelles versions de mesa, si pas j'attendrai la mise à jour qui supporte l'opengl 4.2, ce n'est pas bien grave.

[maeiky]

"texelFetch" c'est la même chose que "texture", mais au lieu d'une position normalisé, il prend des coordonnées entière, tout comme dans Paint

Hors que avec imageloadstore je pourrai générer une depthtexture et une shadowmap avec un seul draw call. (Chose que je souhaiterais faire pour optimiser le FPS de mon moteur)

Quel est l'utilité de générer une depthtexture et une shadowmap avec un seul draw call? C'est pas 2 drawcall qui va plomber tes perfs.
Oublie imageloadstore, c'est pas fait pour être performant.

Bref du readback j'ai besoin d'en faire également pour générer une texture de profondeur de la scène dans le but de calculer l'éclairage donc je ne pourrai quand même pas faire cela avec un seul draw.

Qu'est-ce que tu raconte, on s'en fou que ton rendu prennent 10 drawcalls, c'est quand tu en as des centaines que ça à un impacte.

Donc le weitghted blending ne résoudra pas tout les problèmes. :/

Bien au contraire, commence dont par apprendre à utiliser ton GPU.

[Invité]

J'ai besoin d'une centaine de drawcalls pour dessiner la map tile par tile..., afin de générer la shadowmap ainsi que toutes les textures pour calculer la lumière, etc...

Oublie imageloadstore, c'est pas fait pour être performant.

Je ne sais pas mais j'aimerais bien tester quand même.

[maeiky]

J'ai besoin d'une centaine de drawcalls pour dessiner la map tile par tile..., afin de générer la shadowmap ainsi que toutes les textures pour calculer la lumière, etc...

Sérieusement?



Le principe de ne pas être dépendant d'un ordre d'affichage, ou OIT, Order-independent transparency

C'est de pouvoir grouper tes éléments et les dessiner en même temps, comme tes tiles.

Oublie imageloadstore, c'est pas fait pour être performant.

Je ne sais pas mais j'aimerais bien tester quand même.

Si tu veux perde une autre année c'est toi qui vois ...

[stopviolence]

J'ai besoin d'une centaine de drawcalls pour dessiner la map tile par tile..., afin de générer la shadowmap ainsi que toutes les textures pour calculer la lumière, etc...

On ne trace SURTOUT PAS une tilemap tuile par tuile, tu vas tuer les CPU avec des centaines de drawcalls !

Une tilemap se rend avec UN seul drawcall.

Voilà différentes techniques qu'on utilise:

1/ avec des ombres prédessinnées sur des tuiles reservées aux ombres

- moteur de rendu software, logique pixel par pixel

- displacement mapping, logique au pixel également

- un maillage avec deux triangles pour chaque tuile (plus rapide que la technique précédente sur les gpu qui gèrent le hardware vertex, plus lente sur les gpu qui ne gèrent pas le hardware vertex)

2/ avec des ombres générées en temps réel

- rendu 3d orthographique avec un shader d'ombres

[Invité]

Sérieusement?



Le principe de ne pas être dépendant d'un ordre d'affichage, ou OIT, Order-independent transparency

C'est de pouvoir grouper tes éléments et les dessiner en même temps, comme tes tiles.

Ca ne marchera pas, les textures ne sont mise à jour qu'après l'appel à draw. (Et pas à chaque rendu d'un pixel)
Hors, j'ai besoin de calculer la profondeur de chaque tile pour calculer les ombres.

avec des ombres prédessinnées sur des tuiles reservées aux ombres

Cette technique ne marche pas pour la 3D, je ne dessine pas les ombres des tiles du sol et donc, j'ai peu de drawcalls.
Mais je pourrai en avoir plus avec des modèles en 3D.

PS : je pourrai aussi vouloir dessiner les ombres des tiles du sol avec un sol non plat mais je devrais encore faire plus d'appels à draw.

De quoi tuer le CPU...

Bref pour le moment je ne connais pas de moyen de le faire sans tuer le CPU sauf avec imageloadstore.

[maeiky]

Sérieusement?
Le principe de ne pas être dépendant d'un ordre d'affichage, ou OIT, Order-independent transparency
C'est de pouvoir grouper tes éléments et les dessiner en même temps, comme tes tiles.

Ca ne marchera pas, les textures ne sont mise à jour qu'après l'appel à draw. (Et pas à chaque rendu d'un pixel)
Hors, j'ai besoin de calculer la profondeur de chaque tile pour calculer les ombres.

T'as vraiment rien compris et tu mélange tout.

#1 Ta aucunement besoin de lire un pixel qui à été écris dans un même drawcall
#2 C'est une très mauvaise idée de lire un pixel écris dans un même drawcall, (le même FBO que celui que tu génère)
#3 Normalement on fait une shadow map dans un autre buffer, donc un drawcall différent

[NevilClavain]

#1 Ta aucunement besoin de lire un pixel qui à été écris dans un même drawcall
#2 C'est une très mauvaise idée de lire un pixel écris dans un même drawcall, (le même FBO que celui que tu génère)

Je plussoie, personne n'a jamais eu besoin de faire ce genre de bidouille. S'il y avait eu un réel manque par rapport à ça, il y a longtemps que les mainteneurs de toutes les couches (GPU/drivers/D3D/OpenGL) auraient mis en place une solution pour faire ça.

C'est probablement plutôt ta conception logicielle qui est "viciée" à la base. Tu devrais envisager la solution de faire table rase pour repartir sur quelque chose de plus sain et mieux bâti. C'est douloureux (ça m'est arrivé aussi) mais y a que comme ça qu'on avance...

Une fois de plus je ne saurais trop vanter la puissance du deffered shading, qui permet de faire à peu près tout ce que tu peux imaginer, et même davantage -> https://en.wikipedia.org/wiki/Deferred_shading

Il n'y a que la transparence qui doit être gérée de façon particulière, mais rien d'insurmontable...

Et si ça ne te convainc pas, regarde un exemple (brillant) de ce que cette technique permet de faire -> http://www.adriancourreges.com/blog/...raphics-study/

[Invité]

#1 Ta aucunement besoin de lire un pixel qui à été écris dans un même drawcall.

Ca aurait été bien de pouvoir le faire quand même dès le moment ou les shaders sont apparus, ils ont juste attendu la version 4.2 d'opengl pour le faire.

Tout ce que ça faisait avec les anciennes versions c'était une copie du buffer dans la texture après chaque drawcall sur un FBO.

Le but premier des shaders c'est quand même d'écrire et de lire des données avec le GPU.

Au lieu de cela le depthtest à été implémenté directement dans le pipeline.

OpenGL lis bien les données des buffers pour les comparer avec ce qui va être dessiner si on active le depthtest.

Alors pourquoi avoir attendu pour pouvoir le faire manuellement avec un shader ?

Je plussoie, personne n'a jamais eu besoin de faire ce genre de bidouille. S'il y avait eu un réel manque par rapport à ça, il y a longtemps que les mainteneurs de toutes les couches (GPU/drivers/D3D/OpenGL) auraient mis en place une solution pour faire ça.

Ils sont sûrement passé à côté de quelque chose car sinon ils n'auraient pas implémenter image load store, ni les bindless textures.
Et OpenCL n'existerait pas non plus.

Les appels trop nombreux à glBindTexture et à glDraw sature le CPU et dans les cas plus complexe ont est obligé de faire du rendu par section.

Beaucoup n'ont pas besoin de faire de la lecture et écriture de pixels avec un seul draw call et un seul FBO, donc, sur ce point là je te rejoins mais pas pour le reste.

PS : maintenant si ils ont envie de le faire ou pas ça ne dépend que d'eux hein.

[maeiky]

Ca aurait été bien de pouvoir le faire quand même dès le moment ou les shaders sont apparus, ils ont juste attendu la version 4.2 d'opengl pour le faire.

Tout ce que ça faisait avec les anciennes versions c'était une copie du buffer dans la texture après chaque drawcall sur un FBO.

Le but premier des shaders c'est quand même d'écrire et de lire des données avec le GPU.

Au lieu de cela le depthtest à été implémenté directement dans le pipeline.

OpenGL lis bien les données des buffers pour les comparer avec ce qui va être dessiner si on active le depthtest.

Alors pourquoi avoir attendu pour pouvoir le faire manuellement avec un shader ?

Mais pourquoi attendre pour faire l'ordinateur quantique, comme ça on pourrait coder avec les pieds sans problèmes.

Beaucoup n'ont pas besoin de faire de la lecture et écriture de pixels avec un seul draw call et un seul FBO, donc, sur ce point là je te rejoins mais pas pour le reste.

PS : maintenant si ils ont envie de le faire ou pas ça ne dépend que d'eux hein.

Si tu n'as pas envie d'écouter les conseils ça ne dépend que de toi, hein.

Bon ... Vas en paix, tel un Shadok. Amen. (À réciter 5 fois)

[Invité]

Je pense avoir trouvé une meilleur technique mais y a t'il moyen de lier une texture 3D à un FBO ?

Ainsi avec un seul draw call, j'écris tout dans la texture 3D. (les z des fragments et la couleur)

Ensuite je fais une seconde passe qui écris toutes les couches de la texture 3D (dans l'ordre) sur une texture 2D.

Il y a t'il moyen de faire quelque chose comme ça ?

Ca m'éviterai de devoir lire et écrire dans ma texture 2D avec un seul FBO et un seul drawcall.

[Iradrille]

C'est possible, mais tu est limité par la taille de ta tex3D :
Avec une taille de 1920*1080*16 tu auras 16 calques. C'est aussi très lourd.

1 octet par pixel: 1920*1080*16*1 -> 33 Mo;
4 octets par pixels: 1920*1080*16*4 -> 132.7 Mo;

[Invité]

Ouais ça va être lourd par contre niveau mémoire car, si par exemple j'ai un zfar élevé de 1000 je vais avoir 1000 couches.

Mais bon ça sera déjà mieux que de faire des opérations atomiques qui sont lente ou de faire 1000 drawcalls.

Bref, je vais tester.

Si je ne veux pas faire de lecture et écriture dans un même FBO je n'ai pas le choix je dois convertir le z (qui est en float) en int et stocker toute la scene dans une texture 3D. :/

[maeiky]

Ainsi avec un seul draw call, j'écris tout dans la texture 3D. (les z des fragments et la couleur)
Ensuite je fais une seconde passe qui écris toutes les couches de la texture 3D (dans l'ordre) sur une texture 2D.

C'est possible, mais tu est limité par la taille de ta tex3D :
Avec une taille de 1920*1080*16 tu auras 16 calques. C'est aussi très lourd.
1 octet par pixel: 1920*1080*16*1 -> 33 Mo;
4 octets par pixels: 1920*1080*16*4 -> 132.7 Mo;

Ouais ça va être lourd par contre niveau mémoire car, si par exemple j'ai un zfar élevé de 1000 je vais avoir 1000 couches.

Mais bon ça sera déjà mieux que de faire des opérations atomiques qui sont lente ou de faire 1000 drawcalls.

Bref, je vais tester.

Si je ne veux pas faire de lecture et écriture dans un même FBO je n'ai pas le choix je dois convertir le z (qui est en float) en int et stocker toute la scène dans une texture 3D. :/

Non, mais tu te rend compte du ridicule de la chose! 1000 couches sérieusement?? Et tu pense que transformer 1000 couches en une texture 2d va être plus rapide. Sérieusement, 1000 couches ça tient juste pas en mémoires, 33 mo par calques, non mais sort ta calculatrice 2 secondes, combien font 1000 couches :

33 * 1000 = 33 000 = 32 go! T'as une carte graphique de 32 go toi?

Je crois qu'on ne peut qu'en conclure que le rendu graphique ce n'est juste pas à la porté de tout le monde.

[Invité]

Non mais de toute façon ça ne fonctionnera pas.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
"#version 130 \n"
                   "in mat4 projMat;\n"
                   "uniform sampler2D texture;\n"
                   "uniform float haveTexture;\n"
                   "uniform vec3 resolution;\n"
                   "void main() {"
                   "    vec2 position = ( gl_FragCoord.xy / resolution.xy );\n"
                   "    vec4 color = texture2D(texture, position);\n"
                   "    vec4 pixel = (haveTexture==1) ? gl_Color * texture2D(texture, gl_TexCoord[0].xy) : gl_Color;\n"
                   "    float z = (gl_FragCoord.w != 1.f) ? (inverse(projMat) * vec4(0, 0, 0, gl_FragCoord.w)).w : gl_FragCoord.z;\n"
                   "    int layer = int(z * resolution.z);\n"
                   "    gl_Layer = layer;\n /*Ne fonctionne pas!*/"
                   "    gl_FragColor = pixel;\n"
                   "}";

Dans le fragment shader on ne peut pas choisir la couche sur laquelle on veut écrire, on ne peut le faire que dans le geometry shader avec gl_Layer.

Et en effet j'ai calculé et les cartes graphiques avec 32 giga je ne pense pas que ça soit pour demain.