Les bugs OpenGL

[nystep]

différences GLSL entre nvidia et ATI:

- utilisation de gentype frac( gentype x ):

frac est une fonction Cg et HLSL, mais pas GLSL. Il est pourtant possible de l'utiliser dans les shaders sans encombre sur les cartes nVidia. sa version dans le language GLSL est fract. (ndlr: ancien, je ne sais pas si ce bug se retrouve aujourd'hui).

- utilisation de gentype round( gentype x ):

les drivers ATI compilent, alors que les drivers nVidia sortent une erreur qui rappele qu'il faut utiliser #version 130 au minimum en début de shader afin d'utiliser cette fonction.

- constantes float: dans les anciens drivers GLSL ATI, les constantes du type .0 et 0. ne sont pas float. Il en résultera des erreus de compilation de shader. (ndlr, je ne sais pas de nos jours).

- utilisation du mot clé varying:

Les drivers ATI autorisent son utilisation dans les nouvelles versions de GLSL, alors que les drivers nVidia nous rappelent que le mot clé est déprécié depuis la version 130. utiliser in et out à la place (seulement un warning).

[ponce]

Attention si vous êtes sur ATI n'utilisez pas Catalyst 10.10, j'ai un bug au déchargement de la DLL du driver qui vient de partir en repassant au 10.9.

[nystep]

Il y a pas mal d'informations intéressantes sur cette page:

http://www.opengl.org/wiki/GLSL_:_common_mistakes

[ponce]

N'utilisez pas Catalyst 10.11, sauf si vous voulez redécouvrir les joies du BSOD. 
Et puis le bug http://forums.amd.com/devforum/messageview.cfm?catid=392&threadid=141999&enterthread=y est toujours là.

[nystep]

Une fois n'est pas coutume, un bug sur le driver nvidia.

les cubemaps ne sont pas seamless par défaut.

il faut donc rajouter une paire de ligne de code et une extension pour pallier à ce bug dans votre initialisation (sur ATI les cubemaps sont seamless par défaut).

Code: [Sélectionner]

     if (GLEW_ARB_seamless_cube_map)
        glEnable( GL_TEXTURE_CUBE_MAP_SEAMLESS_ARB );


[mawww]

Sous MacOS, avec une ATI 4870

- Bug dans glUniformMatrix4x3fv: Les matrices sont lues comme des 4x4, donc si on charge un tableau de matrice, seul la premier est valide
- Plus de 256 uniforms (soit 64 mat4) et on passe en software silencieusement (mis a part les FPS, qui crient)
- glGenerateMipMaps sur une texture NPOT est tres lent, je soupcone que ca soit fait au CPU

[LLB]

Sur (certaines ?) NVidia, la première ligne marche correctement, mais pas la 2e :

Code: [Sélectionner]

for(o=s*.5+.5;i>0.;i--)
for(o=s*.5+.5;0.<i;i--)

De même, toujours sur NVidia :

<las> i had even more funny bugs...
<las> for (int f = 32; f > 0; f-=2) ...
<las> did not work properly...
<las> instead i then used
<las> for (int f = 32; f > 0; f--,f--) ...
<las> and the shit worked.

<las> i just checked it on my linux
<las> it seems to be a problem for more than one driver version
<las> and not OS bound... WHAT THE FUCK

On dirait qu'il y a des soucis avec les boucles for décroissantes.

[ponce]

Pourquoi pas épingler ce sujet ? J'ai vu que u2Popsy faisait plein d'OpenGL en ce moment mais je ne sais pas si il a vu le sujet.

[MsK`]

Pas vraiment un bug mais ça peut éviter à des gens d'y passer plusieurs heures :
Quand on fait du render to texture, ne pas oublier de générer les mipmap sur la texture une fois le rendu terminé et si on a le filtrage activé. Même si le niveau de mipmap 0 est utilisé, le sampler renvoie du noir si les mipmap sont pas *toutes* présentes...

[flure]

@ponce : Euh non u2 fait du DirectX il me semble... Mais oui épingler ce sujet me semble une bonne idée en effet...