Discussion :

[Guildem]

Bonjour,

Je fais des tests de shaders et j'ai voulu essayer un pixel shader tout simple, qui me renvoi le pixel avec sa couleur d'origine, or lorsque j'active le programme dans mon code opengl, tout devient noir ! voici mon code du ps en assembleur :

Code :

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

1
2
3
ps_2_0
dcl v0
mov oC0, v0

et celui en cg que j'ai fait au cas ou...

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
struct pixel_in {
	float3 color : COLOR0;
};
 
struct pixel_out {
	float3 color : COLOR;
};
 
pixel_out main(pixel_in IN, uniform sampler2D texture :TEXUNIT0)
{
	pixel_out OUT;
	float3 color = IN.color;
	OUT.color = color;
	return OUT;
}

pour le code cg, ya de l'optimisation a faire, mais c'est pas grave ! l'important c'est que ces programmes ne me donnent rien ! voici comment je charge mon shader :

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
30
31
32
GLbyte *load_program_string(const GLbyte *filename)
{
	static GLbyte program_string[16384];
	FILE *fp;
	GLuint len;
 
	fp = fopen(filename, "r");
	if(!fp)
		return NULL;
 
	len = fread(program_string, 1, 16384, fp);
	program_string[len] = '\0';
	fclose(fp);
 
	return program_string;
}
 
GLuint load_shader(GLuint type, const GLbyte *filename)
{
	GLuint shader_num;
	GLbyte *program_string;
 
	program_string = load_program_string(filename);
 
	glEnable(type);
	glGenProgramsARB(1, &shader_num);
	glBindProgramARB(type, shader_num);
	glProgramStringARB(type, GL_PROGRAM_FORMAT_ASCII_ARB, strlen(program_string), (const GLbyte *)program_string);
	glDisable(type);
 
	return shader_num;
}

a mon initialisation d'opengl, je fais ceci :

Code :

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

1
2
3
4
5
6
7
	glGenProgramsARB = (PFNGLGENPROGRAMSARBPROC)wglGetProcAddress("glGenProgramsARB");
	glBindProgramARB = (PFNGLBINDPROGRAMARBPROC)wglGetProcAddress("glBindProgramARB");
	glProgramStringARB = (PFNGLPROGRAMSTRINGARBPROC)wglGetProcAddress("glProgramStringARB");
	glActiveTextureARB = (PFNGLACTIVETEXTUREPROC)wglGetProcAddress("glActiveTextureARB");
	glMultiTexCoord2fARB = (PFNGLMULTITEXCOORD2FARBPROC)wglGetProcAddress("glMultiTexCoord2fARB");
 
	shaderid=load_shader(GL_FRAGMENT_PROGRAM_ARB, "ps.pso");

et lors de l'affichage de mes polygones, je fais ca :

Code :

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

1
2
3
4
5
6
7
8
9
	if(keys['P'])
	{
		glEnable(GL_FRAGMENT_PROGRAM_ARB);
		glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, shaderid);
	}
	else
	{
		glDisable(GL_FRAGMENT_PROGRAM_ARB);
	}

au final, lorsque j'appuie sur P pour activer mon shader, le joli cube que j'avais a l'ecran disparait et laisse un fond noir...

Ma configuration :
Athlon 64 3000+
2Go PC3200
Leadtek 6600GT

Voila, je ne sais pas si certain d'entre vous ont déja eu ce probleme, mais c'est tres génant, car je ne peux pas avancer !

Avez vous une idée ? merci d'avance !

Si quelqu'un a un bout de code a me proposer pour que je le teste... je travaille sous windows avec VC++ 6.0

Désolé si ma question à déja été posée, j'ai fait des recherche sur le forum mais je n'ai rien trouvé de correspondant.

[Laurent Gomila]

Tu as placé des tests pour voir si tout se passait bien ?
Du genre :

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
glProgramStringARB(...);
 
if (GL_INVALID_OPERATION == glGetError())
{
    // Find the error position
    GLint errPos;
    glGetIntergv(GL_PROGRAM_ERROR_POSITION_ARB, &errPos ); 
 
    // Print implementation-dependent program
    // errors and warnings string.
    Glubyte *errString;
    glGetString(GL_PROGRAM_ERROR_STRING_ARB, &errString); 
 
    fprintf(stderr, “error at position: %d\n%s\n”, errPos, errString);
}

[bafman]

ton shader en assembleur me semble bizzar... ca ne serait pas du DirectX que tu nous fais la ? jamais vu d'instruction ps_2_0 ou dcl dans un fragment program... tiens d'ailleur en openGL, quand on fait de l'ASM on parle de fragment program et pas de pixel shader, c'est plus proche de la realité en fait

[Guildem]

Tu as placé des tests pour voir si tout se passait bien ?
Du genre :

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
glProgramStringARB(...);
 
if (GL_INVALID_OPERATION == glGetError())
{
    // Find the error position
    GLint errPos;
    glGetIntergv(GL_PROGRAM_ERROR_POSITION_ARB, &errPos ); 
 
    // Print implementation-dependent program
    // errors and warnings string.
    Glubyte *errString;
    glGetString(GL_PROGRAM_ERROR_STRING_ARB, &errString); 
 
    fprintf(stderr, “error at position: %d\n%s\n”, errPos, errString);
}

Je vais essayer de voir ca !

[Guildem]

ton shader en assembleur me semble bizzar... ca ne serait pas du DirectX que tu nous fais la ? jamais vu d'instruction ps_2_0 ou dcl dans un fragment program... tiens d'ailleur en openGL, quand on fait de l'ASM on parle de fragment program et pas de pixel shader, c'est plus proche de la realité en fait

c'est ptetre bien possible ! je pensais que si les noms etaient différents les langages etaient les memes !

pourrais tu me donner un fp simple en assembleur stp ?
a moins que sur cg, je n'ai pas mis le bon profile je test ca et je vous dis !
merci !!

[Laurent Gomila]

Personnellement ce que je fais, c'est que j'utilise cgc (le compilateur Cg en ligne de commande) pour me sortir l'ASM correspondant à mon programme Cg. Comme ça, je suis sûr d'avoir un programme ASM valide par rapport au profil supporté par mon système.

Tu peux aussi le sortir directement à partir de ton application (fonction cgGetProgramString(Program, CG_COMPILED_PROGRAM)), et l'utiliser pour créer ton program ARB.

[Guildem]

Bien !

donc j'ai déja testé le code d'erreur...
bien evidement comme vous vous en doutez, erreur a la premiere ligne
j'ai recompilé mon fp avec le profile fp20 (le premier que j'ai vu dans la fin de la liste) et ca m'a mit un warning, et erreur...
j'ai recompilé avec les fp40 et la CA MARCHE !!!!!

pour le cas ou d'autres on un probleme similaire, voici le code du fp sorti par le compilateur cg, a partir du source du premier post :

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
!!ARBfp1.0
OPTION NV_fragment_program2;
# cgc version 1.4.0000, build date Jun  9 2005 12:09:02
# command line args: -profile fp40
# source file: D:\Dossier Laika\sources\tests\effects1\ps.cg
#vendor NVIDIA Corporation
#version 1.0.02
#profile fp40
#program main
#semantic main.texture : TEXUNIT0
#var float3 IN.color : $vin.COLOR0 : COL0 : 0 : 1
#var float3 IN.texcoord : $vin.TEXCOORD0 : TEX0 : 0 : 0
#var sampler2D texture : TEXUNIT0 : texunit 0 : 1 : 0
#var float3 main.color : $vout.COLOR : COL : -1 : 1
PARAM c[1] = { program.local[0] };
TEMP RC;
TEMP HC;
OUTPUT oCol = result.color;
MOVR  oCol.xyz, fragment.color.primary;
END
# 1 instructions, 0 R-regs, 0 H-regs

ce qui en enlevant les "parasites" de cg, donne ceci en assembleur :

Code :

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

1
2
3
4
5
6
7
8
!!ARBfp1.0
OPTION NV_fragment_program2;
PARAM c[1] = { program.local[0] };
TEMP RC;
TEMP HC;
OUTPUT oCol = result.color;
MOVR  oCol.xyz, fragment.color.primary;
END

Qui est un code malheureusement plus long que pour un pixel shader equivalent (voir le code assembleur du ps du premier post), mais au moins ca marche !
j'espere qu'il n'y a pas de différence en vitesse, entre opengl et directx...

merci pour la rapidité de vos réponses, et j'espere vous contacter pour quelque chose d'un peu moins enfantin la prochaine fois !

bonne continuation !

[bafman]

et avec un petit

Code :

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

1
2
3
4
5
 
!!ARBfp1.0
OPTION ARB_invariant;
MOV result.color, fragment.color;
END

ca devrait etre aussi bien et en plus portable sur ATI.

sinon niveau difference de performance... malheureusement elle existent... generalement les NVidia ce debrouillent bien en openGL, et les ATI en directX.
Bien entendu, ces differences de perf s'expliquent aussi en fonction de l'architecture du moteur (qui privilegie une des 2 API a un moment ou un autre...)

[Guildem]

et avec un petit

Code :

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

1
2
3
4
5
 
!!ARBfp1.0
OPTION ARB_invariant;
MOV result.color, fragment.color;
END

ca devrait etre aussi bien et en plus portable sur ATI.

sinon niveau difference de performance... malheureusement elle existent... generalement les NVidia ce debrouillent bien en openGL, et les ATI en directX.
Bien entendu, ces differences de perf s'expliquent aussi en fonction de l'architecture du moteur (qui privilegie une des 2 API a un moment ou un autre...)

J'ai testé ton code, et il me met une erreur sur l'option ARB_invariant... c'est dommage il avait l'air plus cour ;-)

pour les performances, le moteur sera a mon avis plus optimisé pour NV, mais bon, j'aimerai quand meme que ca marche un chouillat sur les ATI !!

Merci pour ces précisions

[bafman]

rhooo quel naze... y'a pas besoin d'invariant pour les fragment program, c'est pour les vertex program... donc tu peut le virer et ca devrais marcher...

[Guildem]

rhooo quel naze... y'a pas besoin d'invariant pour les fragment program, c'est pour les vertex program... donc tu peut le virer et ca devrais marcher...

En effet, ca marche mieux comme ca !
on mettra ca sur le compte de la fatigue

bon j'arrive a reproduire ce que je voulais faire, mais je le fais direct en assembleur, car cg me met trop de lignes, et il fait des trucs bizarres qui rajoutent des instructions inutiles.

Merci a tous

[bafman]

en fait le probleme de CG c'est qu'il a tendance a sortir du code qui ne tourne que sur NVidia

[Guildem]

et HLSL il est mieux ?

certains pensent que coder en assembleur c'est limité et dépassé, sauf si on est un guru... c'est vrai ?

[shenron666]

attention : HLSL = directx

Là il est question de shaders, pas de programme en terme général, les programmes des shaders sont ou bien en assembleur ou bien en HLSL pour directx ou en GLSL pour opengl, ce sont des programmes destinés à la carte graphique

de plus l'assembleur ce n'est pas limité ni dépassé ni uniquement pour les guru, par contre coder un programme entier en assembleur faut être fou, on ne code en assembleur que les parties de programmes qui sont appelées le plus souvent (genre des calculs de vecteurs dans un moteur 3D)

L'avantage de HLSL et de GLSL étant que ce sont des langages plus évolués, proches du C voire du C++, leur inconvénient étant quand à lui qu'ils sont plus lents car les compilateurs ne sont pas super optimisés

Donc au final non HLSL n'est pas mieux, c'est différent, mais c'est aussi l'avenir ... de directx