[News] OpenGL

[Møgluglu]

Non mais on n'en est pas là de toute façon, faudrait déjà qu'il rattrape les 8 ans de retard en OpenGL avant de passer à CL. La dernière fois que j'ai regardé les FBO/PBO n'étaient pas supportés, il fallait passer par les infâmes pbuffers. Pas de texture float ni de render target float non plus, mais ça ça ne serait pas grave si le driver n'appliquait pas de manière fasciste une fonction de correction gamma sur les pixels des pbuffers, ce qui est moyen quand on veut récupérer ses données.

Si vous voulez imiter les pionniers du GPGPU, mais 10 ans après, essayez Intel.

[xheyther]

Certains de ces trucs ont du être ajouté récemment dans Gallium sous Linux, vu que je crois bien reconnaître des noms qui sont dans la to-do list pour le support d'OpenGL 3.0, qui est censé arrivé avec 7.12 ou 7.13 (et qu'on appellera 8 du coup).

[rOut]

Bon, je tente le coup ici au cas ou.

Quelqu'un a déjà utilisé des sampler integer ? Genre des usampler/isampler ? Je n'arrive rien à en tirer...
J'ai un shader qui fonctionne en sampler flottant, mais quand je veux passer en integer, j'ai l'impression que le shader n'arrive pas à sampler quoi que ce soit... Comme d'habitude c'est la grosse merde pour savoir ce qu'il se passe exactement dans le fragment shader, s'il sort 0 ou c'est la conversion vers le renderbuffer (flottant lui) qui déconne...

Je pense charger correctement les données dans ma texture, je n'ai aucune erreur retournée, et quand je lis les données depuis la mémoire de la carte (GetTexImage), j'ai bien tous les bits que je lui ai donné...

Est-ce qu'il y a quelque chose qui pourrait être lié à une mauvaise création de contexte ? Je modifie du code existant utilisant la SDL, et je doute que le contexte créé soit en core profile 3.x, ça pourrait jouer ? Je viens de penser à ça, je vais tester avec un contexte créé à la mimine.

Sinon j'ai tracé avec apitrace dont on parlait plus haut... Bah il aime pas mes integer texture. Il me dit que le paramètre format de TexSubImage est inattendu (RGB_INTEGER), mais pas d'erreur retournée par OpenGL, donc je pense quand même que je fais ce qu'il faut.

[Tomaka17]

Essaye gDEBugger, c'est le must-have pour le débuggage OpenGL
Tu pourras au moins voir si ta texture est correcte, et débugger ton shader en regardant quelle valeur contient chaque variable

[rOut]

Ca ne marche pas. Déjà il me demande /usr/lib64/libGL.so.1 qui n'est pas là (mais qui est ailleurs, et je n'aime pas les applis qui présupposent des trucs à la con comme ça), et ensuite il fait un segfault dans une lib gtk au lancement de l'appli...

---------- Post added at 20h12 ---------- Previous post was at 20h06 ----------

La vache, c'est bien la premiere fois que je vois ça... Le segfault n'était pas à cause de l'appli, mais à cause... d'une image PNG chargée pour l'explorateur de fichiers... En éditant l'image dans GIMP et en la resauvegardant, ça corrige le problème.

---------- Post added at 20h28 ---------- Previous post was at 20h12 ----------

Bon ben pareil, gDebugger arrive à lire ma texture sans problème, le format est bien integer et il y a bien les données attendues dedans... par contre je ne sais pas comment on voit la valeur des variables dans le shader. Et toujours rien d'affiché.

Idem en recréant le contexte à la main en demandant explicitement un contexte core profile 3.2.

[Møgluglu]

J'ai un shader qui fonctionne en sampler flottant, mais quand je veux passer en integer, j'ai l'impression que le shader n'arrive pas à sampler quoi que ce soit... Comme d'habitude c'est la grosse merde pour savoir ce qu'il se passe exactement dans le fragment shader, s'il sort 0 ou c'est la conversion vers le renderbuffer (flottant lui) qui déconne...

Il a quelle gueule ton shader ?

[rOut]

Il est très con.

- last_frame est un compteur de frame mis à jour à chaque frame, tournant en boucle de 0 à 255
- last_update est une texture qui contient le numéro de frame à laquelle a été mis à jour le point en (x,y)
- characters contient des données arbitraires pour le point (x,y)
- toutes les textures font 128x128
- width & height sont des valeurs < 128 correspondant à la portion des textures qui contiennent pour de vrai les données.
- vertex.coordinates contient des valeurs de 0 à 1 (0x0 pour le point en bas à gauch du viewport, 1x1 pour en haut à droite).
- les calculs bizarres avec ipos, c'est pour remettre à l'endroit les textures.

En gros au final, je m'attends à avoir, sur output_image.r la donnée qui vient de characters (je la vois bien), sur output_image.b une valeur valant 1 pour les points qui viennent d'être mis à jour, puis diminuant au fil du temps (là je ne vois rien), et output_image.g est un check pour voir si j'ai effectivement des 0 partout, et c'est bien le cas.

Et si je change ma texture en float et mon sampler en float aussi, tout en chargeant exactement les même bits (last_frame que je convertis en float entre 0 et 1, et last_frame toujours chargé avec le numéro de frame, en byte entre 0 et 255 et est normalizé par OpenGL en valeur flottante entre 0 et 1 quand je le sample).

#version 330 core

uniform uint width;
uniform uint height;

uniform uint last_frame;
uniform usampler2D last_update;

uniform sampler2D characters;

in vert {
  vec2 coordinates;
} vertex;

out vec4 output_image;

void main() {
  vec2 size = textureSize(characters, 0);
  vec2 pos = vertex.coordinates;
  uint maxsize = max(width, height);
  pos.x = pos.x * maxsize;
  pos.y = (1 - pos.y) * maxsize;
  ivec2 ipos = ivec2(pos.y, pos.x);
  
  vec4 c = texelFetch(characters, ipos, 0);
  output_image = c;

  uvec4 last = texelFetch(last_update, ipos, 0);
  output_image.b = (float(last.r) / last_frame) * (float(last.r) / last_frame);

  if(last.r == 0u) {
    output_image.g = 1.0;
  }
}

Et pour la version integer, j'apelle évidemment glTexImage avec:
internalformat = GL_RGB8UI
format = GL_RGB_INTEGER
type = GL_UNSIGNED_BYTE

Pour la version float, je ne sais plus mais ça marche donc c'est pas important.

---------- Post added at 23h55 ---------- Previous post was at 23h49 ----------

Tiens sinon rien à voir mais je suis tombé là dessus, je trouvais ça pas mal:
http://www.iquilezles.org/apps/shadertoy/index.html

(C'est un shader designer pour webGL)

[rOut]

Bon ben j'ai eu la réponse sur les boards officiels : il faut penser à mettre le MIN_FILTER et MAG_FILTER à NEAREST, sinon la texture n'est pas considérée comme complete...

Exactement le genre de détail qui me rend dingue avec OpenGL. Tu passes trois jours à chercher pourquoi ton pixel reste noir, alors que tout semble bon et qu'il n'y a aucune erreur. A croire qu'il faut apprendre chaque page de la spec par coeur pour pouvoir utiliser l'API.

Bon, maintenant que j'ai trouvé ces contraintes supplémentaires, je vais tâcher de me les coder quelque part une bonne fois pour toute.