Discussion :

[ultimanu]

Bonjour,

j'espère que vous pourrez m'aiguiller sur le problème suivant, je cherche à réaliser des opérations sur une texture passée à mon pixel shader.
Je cherche par à sommer tous les valeurs R des texels de la texture et à écrire le résultats en sortie.

J'ai donc en entrée 1024x1024 valeurs et en sortie 1 valeur.
J'ai tenté d'utiliser le même principe dont on avait parlé sur les pixels adjacents dans un post précédent, mais étant donnée la taille des textures et les limites que je rencontre avec les instructions du type :

texture2 = tex2D(gTexture1Sampler, In.TextureUV + float2(1.0f,0.0f));

je n'arrive pas à obtenir le résultat que je recherche.
En parcourant de la documentation sur le net, je vois qu'il est possible a priori de faire ce que je recherche avec plusieurs passes...
Il y a d'ailleurs cet exemple avec les produits matriciels comme illustrer dans la pièce jointe. Cet exemple repose sur le principe suivant :

Pass1
Output = ax1 * b1y + ax2 * b2y +… + axb * bby
…..

Passes: = n/Blockssize

Now there is a tradeoff between passes and program size/fetches

j'ai trouvé ces informations à l'adresse
http://www.seas.upenn.edu/~cis665/Ma...nsontheGPU.ppt

mais je n'arrive pas à les utiliser.

1. Pourriez vous me renseigner sur les passes :
a. est-il possible d'utiliser le résultat d'une passes dans une autres passe ?
b. si oui, comment faire ?

2. Comment gérer les passes au niveau du pixel shader ?

3. Evidemment si quelqu'un a un exemple de code source proche de ce que je souhaite réaliser et qu'il souhaite le partager, je lui serai très reconnaissant.

Merci d'avance.

[ultimanu]

j'ai oublié de préciser dans mon premier post :

je travaille avec DirectX 9.0c, une carte graphique qui supporte les shader 3.0 et je code avec HLSL et C++...

[ultimanu]

..bien je vois que ce sujetne rencontre pas beaucoup de succès.

dommage car je suis bien embêté.

quelqu'un a-t-il au moins une idée de comment faire pour cumuler un résultat dans un float lors de l'utilisation de plusieur passses dans un pixel shader ?

[smashy]

Pour faire un rendu multi-passe, il te faut des rendus successifs dans des textures de plus en plus petites. Tu utilises la texture en sortie (mot cle = render target) d une passe dans l entree d une passe suivante. Dans ton shader, tu peux faire quelque chose comme :

sampler2D t1;

float4 col =

tex2D( t1 , tex_coord + delta_texcoord * float2( 1.0, 0.0) ) +
tex2D( t1 , tex_coord + delta_texcoord * float2(-1.0, 0.0) ) +
tex2D( t1 , tex_coord + delta_texcoord * float2( 0.0, 1.0) ) +
tex2D( t1 , tex_coord + delta_texcoord * float2( 0.0,-1.0) );


ce qui te permet d accumuler les texels adjacants dans une texture. Par exemple si ta texture en entree fait 1024x1024 alors

texcoord.x = texcoord.y = 1.0 / 1024.0

note : se pose la question des texels en limite de texture que tu peux resoudre en changeant le WRAP mode de la texture pour border et en placant la couleur BORDER = 0 (desole j ai pas de pseudo-code DX a disposition).

tu dois donc crees des textures qui puissent etre utilisees comme render target (il existe un flag pour ca je crois)

createTexture( .... RENDERABLE ... ); /* ou quelque chose du genre */

et apres tu fais des

getRenderTarget()

+

setRenderTarget()

+

texture->getSurface() /* ou quelque chose ressemblant */

Attention : de memoire, les get/setRenderTarget incrementent les compteurs de referencement (AddRef), il te faut donc prevoir des SubRef adequates.



Idee a creuser et a tester (j ai jamais essaye):

-utiliser les possibilites de generation automatique des LOD de textures.

-Le niveau de taille 1x1 (le plus petit) contient normalement une moyenne de tous les texels de la textures:


moyenne * taille_x * taille_y = somme des couleurs

[smashy]

erreur :

c est

delta_texcoord.x = delta_texcoord.y = 1.0 / 1024.0

[ultimanu]

d'accord, j'ai crois comprendre le principe.
je vais essayrer de bosser la dessus.

merci.

[ultimanu]

finallement là on n'utilise pas vraiment le principe des passes dans le shader, en fait on fait plusieurs appels au shader depuis le cpu, c'est bien ça ?

[smashy]

note :

il y a encore une petite erreur dans mon pseudo-code

float4 col =

tex2D( t1 , tex_coord + delta_texcoord * float2( 1.0, 0.0) ) +
tex2D( t1 , tex_coord + delta_texcoord * float2( 0.0, 0.0) ) +
tex2D( t1 , tex_coord + delta_texcoord * float2( 0.0, 1.0) ) +
tex2D( t1 , tex_coord + delta_texcoord * float2( 1.0, 1.0) );

D'autre part, pour faire marcher ce code, il faut reduire a chaque fois les dimensions de la texture par 2 (entre chaque passes), mais tu peux tres bien faire plus si tu fais plus de lectures dans le meme shader.


quelque chose comme ca

float4 sum = 0;

for (int i = 0 ; i < XXX ; ++i){

for (int j = 0 ; i < YYY ; ++j){

sum += tex2D( t1 , tex_coord + delta_texcoord * float2(i,j) );

}
}

[smashy]

finallement là on n'utilise pas vraiment le principe des passes dans le shader, en fait on fait plusieurs appels au shader depuis le cpu, c'est bien ça ?

Ici, effectivement, le CPU fait plusieurs appel au shader (qui ne contient qu une passe).


Je ne connais presque pas le HLSL, mais je ne crois pas (c est tout sauf une certitude) que tu puissent changer de rendertarget au milieu d un ensemble de passe ... (a voir)

... d un autre cote quand tu utilises les passes multiples dans un HLSL, en interne, l API directx fera tres certainement ce qu on se propose de faire a la main

[ultimanu]

A nouveau bonjour,

j'ai testé la technique que tu m'as donné Smashy et elle fonctionne super bien, alors merci !

le seul problème que je rencontre encore c'est qu'elle fonctionne très bien pour des textures de taille inférieure à 512x512.

en effet dès que je passe à 512x512 ou une taille supèrieure, je constate une erreur assez importante dans le calcul de la somme... alors que j'utilise toujours le même mode de fonctionnement.

J'ai fait des tests, pour toutes les tailles jusqu'à 256x256 je ne recontre aucun problème les calculs tombent toujours juste.

Aurais-tu une idée d'où vient ce problème ?

[ultimanu]

je viens de refaire quelques test et pour une taille de 1024x1024 ça fonctionne sans erreur...

allez comprendre..

ça viendrai de ma carte tout bêtement ?