Discussion :

[Omeyocan]

Bonjour tout le monde. Je résume, le probleme pour ceux qui auraient eu le même, et j'explique plus en détail apres :

Sous linux, quel que soit la tête de mon programme de fragment shader, j'ai beau assigner des valeurs en float à gl_fragColor, il ne me réstitue que des couleurs "booléan". Pour etre plus claire, si je fais

gl_fragColor = vec4(0.75, 0.85, 0.27, 1.0); j'obtiens du NOIR

si je fais :

gl_fragColor = vec4(1.0, 0.25, 0.5, 1.0); j'obtien un joli ROUGE

si je fais :

gl_fragColor = vec4(1.0, 1.0, 0.5, 1.0); j'obtien un magnifique JAUNE pétant

Vous aurez compris que toute valeur qui n'est pas "1.0" devient "0.0". j'ai pu observer des réactions étranges du shader, alors meme que le lui assigne une couleur uni, il continue à me faire fonctionne un algorythme qui normalement n'est plus utilisé... enfin bref, les fragment shader c'est tres étrange sous Linux. Je précise que sous Linux comme sous windows, les shaders sont compilés et linké sans probleme et utilisé en hardware ! c'est à dire que je n'ai meme pas le luxe d'obtenir un quelconque message d'erreur de GLSL...

Là ou c'est emmerdant, c'est que le MEME programme, avec le MEME sahder sous windows, fonctionne tres bien

Les différences d'implémentation de mon programme sont minimes entre linux et windows, evidemment, je crée une fenetre autrement (utilise X au lieu de Winapi), et j'utilise glx au lieu de wgl, mais le reste, c'est la même chose, et j'insiste, la meme chose.

Alors évidement, je commence à me poser questions et perdre la boule :
- Est-ce que c'est moi qui fais pas comme il faut ? (peut-être faut-il utiliser les pbuffer et les fbuffer sous linux pour que les shader fonctionnent correctement ? ça m'étonnerait puisque pas besoins sous windows ?)
- Est-ce que j'initialise mon front/back buffer sous linux pas comme il faut, ? pourtant si j'utilise l'implémentation standard GL, je n'ai aucun probleme de couleurs que ce soit sous linux ou windows, ça tourne en 24bits + alpha +depth sans probleme tant qu'on utilise pas les shaders...
- Est-ce que les pilotes ATI de ma carte sous linux chient des bulles avec les shaders ?

Si quelqu'un pouvais m'éclairer, je lui en suis reconnaissant d'avance...

[Laurent Gomila]

- Est-ce que les pilotes ATI de ma carte sous linux chient des bulles avec les shaders ?

A priori je pencherais pour cette solution. Mais peut-être aussi qu'il y a une bourde dans ton code, c'est difficile à voir.

[Omeyocan]

A priori je pencherais pour cette solution. Mais peut-être aussi qu'il y a une bourde dans ton code, c'est difficile à voir.

Ben oui c'est dificile à voir sans le code c'est sur, mais je me vois mal copier coller tout le code respectif qui pourrait etre en cause...
A mon sens, si c'est dans le code qu'il y'a un probleme, ça ne peut etre qu'au niveau de la création du contexte opengl, car c'est la seule partie du code qui differe entre windows et linux, sachant que le reste est exactement le meme, et il n'y a pas d'erreur possible, puisque ce sont les memes fichiers header qui sont utilisé aux deux compilations séparés...
Il y'a une derniere solution que j'avais envisagé : mauvaise gestion (moins tolérante) des shaders program sous linux par les pilotes ATI, sachant que, petit détail, nulpart dans mon code je ne "détruis" les shaders et les programs, je me contente de killer Opengl sans nétoyer les shader... alors j'avais pensé à un probleme de ce coté là, car meme en refaisant un shader différent, sous linux, le programme semble quand meme utiliser UNE PARTIE dans l'ancien programme... à la limite je me suis meme demandé comment c'était possible...
Probleme, je ne sais pas comment netoyer proprement les shaders, avant de quitter le programme... je fini par me demander si ce n'est pas le compilateur GLSL des pilotes ATI qui sont completement à la ramasse... pourtant je ne dois pas etre le seul à faire du fragment shader sous linux, pourquoi ce bug personne n'en parle nulpart ?

[Laurent Gomila]

Le moyen de s'en assurer serait de tester d'autres programmes utilisant les shaders. Il n'y a pas des équivalents des FX-Composer ou RenderMonkey pour Linux ?

[Omeyocan]

Le moyen de s'en assurer serait de tester d'autres programmes utilisant les shaders. Il n'y a pas des équivalents des FX-Composer ou RenderMonkey pour Linux ?

Ca c'est une tres bonne question... cependant j'avais fais réussis à faire tourner la démo de quake4 sur mon ubuntu, et je pense que quake4 en use et abuse des fragments shader...

[bafman]

tu a shader designer qui tourne sous linux
http://www.typhoonlabs.com/
mais perso, je penche plus pour un probleme de driver (ATI + Linux + OpenGL, c'est pas vraiment le combo ultime )

[Omeyocan]

tu a shader designer qui tourne sous linux
http://www.typhoonlabs.com/
mais perso, je penche plus pour un probleme de driver (ATI + Linux + OpenGL, c'est pas vraiment le combo ultime )

J'ai "installé" la version linux de shader desinger, mais manifestement la version linux de ce logiciel est tres tres en cours de développement... Globalement, je n'ai pas réussi à lui faire compiler un seul shader (pas meme ceux des exemples livrés) il me sort systématiquement une erreur soit segfault soit autre que je ne connais pas... merci quand même, je vais essayer de trouver d'autres programmes censé "shaderiser" sous linux...

[Omeyocan]

Je donne quelques nouvelles, des fois que ça intéresserait du monde.

Apres multiples bidouillages, il semblerait en fait que ce soit effectivement un bug lors de la compilation des shader. En fait, le compilateur semble ne pas lire ou interpréter correctement les "constantes" float mises en dur dans le code, type "float gg = 0.75f;" ou "float gg = 0.75;" ou encore "if(gg < 0.9f)" etc... il n'en retire qu'une valeur entière (voir booléenne, a verifier). j'ai compris le probleme lorsque j'ai commencé à utiliser des variables qui ne faisaientt appel à aucune assignation constante et n'était que des résultat de calculs "internes" à GLSL :

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
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
#version 110
 
varying vec3 normal;
varying vec3 lightToVtx;
 
 
 
void main()
 
{
 
	float intensity, r, g, b;
 
 
	vec3 lv = normalize(lightToVtx);
	vec3 nn = normalize(normal);
 
 
 
	intensity = dot(lv, nn);
	r = gl_FrontMaterial.diffuse.r * intensity;
	g = gl_FrontMaterial.diffuse.g * intensity;
	b = gl_FrontMaterial.diffuse.b * intensity;
 
 
	gl_FragColor = vec4(r,g,b,1.0f);
 
}

là et seulement là, le shader se comporte de maniere cohérante... Je n'ai aucune idée précise de la source du probleme, bien qu'il semble en effet que cela doit etre un bug des drivers ATI...
Je précise que j'ai essayé plusieurs "styles" d'écriture : 0.75, 0.75f, 0.75F, aucun ne fonctionne correctement, le probleme s'étend à tout constant float intégré en dur dans le code, meme dans les oppération de comparaisons "if(prout > 0.1f)" etc...

[zenux]

Salut,

Voila 5 jours quand j'ai commencé à utiliser les shaders sur Linux et sur Windows, j'avais aussi des problèmes avec les float uniquement sur Linux.

Le problème venait de la langue...vu que en français on utilise des "," pour les nombres à virgule et l'anglais utilise des "." !

Aurait-tu le même problème ?
Pour corriger se problème j'ai utilisé cette fonction : "setlocale(LC_NUMERIC, "C");" que je place à l'init de mon application...
Je croit que cette fonction se trouve dans stdlib.h ou stdio.h.