Forums Développement Multimédia

Aller au contenu

Une discution autour de l'AGAL & des Shaders

CODE Actionscript

170 réponses à ce sujet

#1 tlecoz

  • Honoris
  • PipPipPipPipPipPipPipPip
  • 3486 messages

Posté 01 September 2012 - 02:04 AM

Je déplace ici un bout de conversation qui a démarré dans un sujet du forum Minko afin de ne pas polluer le sujet initial.

EDIT ; si un modo sait comment faire remonter ce message en haut de la conversation qu'il le fasse maintenant ou se taise à jamais :D

[édité par un modo] Je ne savais pas que c'était impossible, alors, je l'ai fait… [/édit]

#2 Galacta

    Etudiant Ingénieur

  • Moderateur
  • PipPipPipPipPipPipPipPip
  • 689 messages

Posté 01 September 2012 - 16:12 PM

Alama, je pense que tu peux aisément faire du calcul par GPU en utilisant Alchemy et les lib de NVIDIA et ATI, il te suffit de coder de manière à faire la liaison entre l'AS3 et les lib, et tu obtiendras le SWC qui te permettra d'exécuter le code C dans Flash.

Merci pour la musique, je n'avais pas fait attention à la description :oops:
Word hard, play hard.

#3 alama.be

    Ceinture Noire

  • Members
  • PipPipPipPipPipPipPip
  • 224 messages

Posté 01 September 2012 - 16:36 PM

Salut Galacta, Mmm.. peut être tu as raison et que Alchemy permettrait d'adresser le GPU comme on peut le faire pour la mémoire.. je me rapelle à l'époque avoir échangé quelques Mails avec des gens de chez Mozilla Tamarin à propose de tout ça, Les accès machine au travers de l'AVM2 était quand même assez limités.. Notamment, en Alchemy, on ne savait pas utiliser n'importe quelle librairie .. Mais bon, si Minko arrive à communiquer avec le GPU, c'est que Alchemy peut le faire (en théorie) A creuser.. :)

J'attend vraiment avec impatience le depôt Alchemy "officiel" sur le lab.. :) A l'époque, j'avais bricolé une version compilateur pré installée pour ça.. mais bon, là, on va attendre le lab..

http://www.pureas3.o...ase-donwload-it

:roi:
Ne baisse jamais les bras, car c'est à ce moment là que le miracle risque de se produire..

Site web: http://www.pureas3.org
Twitter: https://twitter.com/PureAS3

Enjoy with Flash Player :-)

#4 Galacta

    Etudiant Ingénieur

  • Moderateur
  • PipPipPipPipPipPipPipPip
  • 689 messages

Posté 01 September 2012 - 16:52 PM

Avec le Flash Player je ne sais pas, avec Air c'est surement plus envisageable. Après je vois pas ce qui empêcherait les lib de compiler gcc le fait parfaitement, et d'accéder au GPU ( je parle toujours avec Air )
Word hard, play hard.

#5 alama.be

    Ceinture Noire

  • Members
  • PipPipPipPipPipPipPip
  • 224 messages

Posté 01 September 2012 - 17:29 PM

Je ne sais pas, je ne peux pas m'avancer sur ce sujet, je ne l'ai pas assez expérimenté, tout ce que je sais, c'est que ça (le code Alchemy) doit être traité par l'AVM et que l'AVM ne peut pas accéder à tout. Par exemple, je voulais voir si je pouvais programmer en C (Alchemy) un contrôle sur le son (carte son) et bien, ce n'était pas possible..(ni en Air). Les choses dans ce genre étaient réservées au core Player et malheureusement, le core player est scellé, fermé par Adobe. Le Stage3D est je pense aussi entièrement embarqué dans le core player, dans ce cas, pas de bricolage possible..( c'est en tous cas, les retours Tamarin que j'ai eu, mais ils sont peut être erronés..) Si Minko peut communiquer avec le GPU, c'est peut être parce que AS3 le permet, mais je doute que ce soit un code natif créé par le créateur de Minko (je Suppose Jean-Marc). Mais bon, je ne veux pas m'avancer, je peux être à la rue de ce coté là.. et on va attendre les remarques de JM, je suis curieux!! :-)

PS: A l'époque, lors des échanges avec la liste Tamarin, j'avais fait un schéma simpliste afin de valider le fonctionnement global du Player.. Personne, ni chez Tamarin, ni chez Adobe n'a contredit ce dessin.. donc, à voir..

Voici le dessin en question, je l'ai repris récemment pour un article:
http://www.pureas3.o...rtir-du-1082012

C'est con, mais j'ai besoin de toujours tout comprendre en détails, sinon, je ne suis pas satisfait :roll:

Si on peut éclairer ma lanterne, ça me ferait plaisir.. :) Mais avec des infos correctes!, je me rappelle, ici sur ce forum, il y a quelques temps, Un type qui m'a mal mené sur un article en me disant que je me plantais total de façon agressive "que l'AVM ne compilait pas à la volée, et que le code était pré compilé (pseudo code) et ensuite exécuté par le Player et blabla..".. Et bien, j'espère que cette personne à prit le temps de lire sur le WEB, car l'AVM compile bien le pseudo code (ABC) à la volée vers la plateforme adéquate (x86; x64, aRM, etc..)

Aller, j'étais en pleine invistigation de l'inlining .. je vais continuer.. :mrgreen:
Ne baisse jamais les bras, car c'est à ce moment là que le miracle risque de se produire..

Site web: http://www.pureas3.org
Twitter: https://twitter.com/PureAS3

Enjoy with Flash Player :-)

#6 tlecoz

  • Honoris
  • PipPipPipPipPipPipPipPip
  • 3486 messages

Posté 01 September 2012 - 18:05 PM

Citation

Programmer le GPU en AS3!!??

Hello !

Je ne suis pas un expert avec Minko, loin de là, mais je pense pouvoir t'éclairer un peu.
En fait, on ne peut pas programmer le GPU en AS3 , on programme le GPU en AGAL ; il est par contre possible de compiler le code AGAL en byteArray (représentant le shader) directement en AS3 grace à la classe AGALMiniAssembler fournis par adobe (ou via un compilateur maison dans le cas de Minko (je crois) ). Puisqu'on peut compiler en AS3 et que l'AGAL c'est du code donc du texte, on peut faire une passerelle entre les 2 en AS3 :)

Citation

Attend, on peut programmer quoi? est-ce que je peux par exemple utiliser le GPU pour faire des calculs? ou même le faire bosser sur un byteArray? ou c'est uniquement des instructions relative à l'affichage?
Théoriquement, on ne peut s'en servir que pour faire des effets graphique.
Le problème est l'on peut injecter des donnée dans le GPU mais on peut rien ressortir.
Il me parait envisageable cela dit de faire des calculs coté GPU et de récuperer les résultat sous forme de couleur dans un pixel. Mais il faut essayer, je n'ai aucune idée du temps que met le FP pour dessiner le contenu du Stage3D dans un bitmap (mais bon, si on considere qu'un carré de 100x100 permet déjà de stocker 10 000 valeurs , les zones a dessiner devraient etre petites et ca ne devrait pas prendre trop de temps). A essayer !

#7 alama.be

    Ceinture Noire

  • Members
  • PipPipPipPipPipPipPip
  • 224 messages

Posté 01 September 2012 - 18:43 PM

Merci Tlecoz pour cette petite avancée.. Donc, c'est bien parce que AS3 à fournit un moyen de le faire, mais en aucun cas, c'est un code écrit en C ou Assembleur _ASM (ABC) .. Ca rejoint donc ce que je pensais.

Si on ne peut rien sortir du GPU, comment récupérer le(s) pixel(s)? dans une texture? un bloc 3D ? Car cet astuce de détourner un moteur pour image avait déjà été faite en 2D avec PixelBender (sauf que ça utilisait le CPU et non GPU) :-) ce serait trop cool de pouvoir faire ça en agal et récupérer un résultat.

Mais, une question me vient à l'esprit.. le Physic alors? c'est pourtant le GPU (enfin, chez NVIDIA) qui devrait être utilisé et dans ce cas, je suppose qu'on pourra faire des aller/retour GPU. A moins que le physix pour FlashPlayer serait prit en charge apr le CPU.. bheuu..

J'ai justement regardé du code AGAL tout à l'heure, heuu.. je capte kedal! Mais bon, j'imagine que c'est juste une question de s'informer..

Le flash Player bouge dans tous les sens de ces temps ci.. y a trop trucs à tester et à comprendre.. lol, mais on y arrivera ! :)

Merci encore, le chemin s'éclaire petit à petit ;)
Ne baisse jamais les bras, car c'est à ce moment là que le miracle risque de se produire..

Site web: http://www.pureas3.org
Twitter: https://twitter.com/PureAS3

Enjoy with Flash Player :-)

#8 tlecoz

  • Honoris
  • PipPipPipPipPipPipPipPip
  • 3486 messages

Posté 01 September 2012 - 19:49 PM

Citation

Si on ne peut rien sortir du GPU, comment récupérer le(s) pixel(s)? dans une texture? un bloc 3D ? Car cet astuce de détourner un moteur pour image avait déjà été faite en 2D avec PixelBender (sauf que ça utilisait le CPU et non GPU) :-) ce serait trop cool de pouvoir faire ça en agal et récupérer un résultat.
Tel que je vois les choses (mais je peux carrément me planter), il faudrait utiliser une texture, appliquer cette texture sur un Plane, dessiner ce plane dans un bitmapData et enfin faire un getPixel sur une zone bien défini (la zone sur laquelle on a modifié la couleur des pixels)

Citation

Mais, une question me vient à l'esprit.. le Physic alors? c'est pourtant le GPU (enfin, chez NVIDIA) qui devrait être utilisé et dans ce cas, je suppose qu'on pourra faire des aller/retour GPU. A moins que le physix pour FlashPlayer serait prit en charge apr le CPU.. bheuu..
En fait ce que j'ai dit plus haut est trop simpliste. Un Shader défini toujours la couleur de rendu des pixels à l'écran. N'importe quel rendu à l'écran utilisant Stage3D passe par un Shader (dans Starling, les shader font 2 lignes mais ils sont là et ne peuvent pas ne pas être là), c'est pourquoi j'ai dit tout à l'heure que les shader servait à faire des effets graphiques.

Pour ce qui est de la physique ou ce genre de chose, il est tout à fait possible d'injecter toutes les variables nécessaires aux calculs dans le GPU, faire le calcul coté GPU et afficher le résultat.

Quand on faisait de la 3D avec flash10, il fallait envoyer un Vector.<Number> representant les positions XYZ de chacun des points du maillage dans la fonction graphics.drawTriangle afin de créer le rendu.

Avec Stage3D, le principe est le même à ceci prés qu'on peut formater les données librement. Au lieu d'avoir un tableau contenant uniquement les coordonnées XYZ, on pour avoir un tableau sous la forme X/Y/Z/R/G/B/A/normalX/normalY/normalZ et de fait, on pourrait avoir un tableau contenant des variables pour la physique genre X/Y/Z/gravity/friction/etc...
La seule chose importante à savoir concernant ce tableau, c'est qu'il décrit les points mais qu'il sera traité triangle par triangle et pas point par point (plus précisement, il sera traité point-de-triangle par point-de-triangle) ).
Il est également possible d'injecter des données dans le GPU depuis un ByteArray, mais pas de moyen de sortie directe autre que le rendu à l'écran.

Citation

J'ai justement regardé du code AGAL tout à l'heure, heuu.. je capte kedal! Mais bon, j'imagine que c'est juste une question de s'informer..

En fait c'est assez simple, mais c'est très abstrait car déconnecté du reste du code :)

Le tableau dont je parle plus haut est un "VertexData", les différentes infos contenus dans ce VertexData sont appelés des VertexAttributes.
Par exemple, si j'ai un tableau X/Y/Z/R/G/B/A ,juste avant d'utiliser le shader, il faut que j'informe le FlashPlayer qu'en fait ce tableau est décomposé en 2 VertexAttributes (XYZ et RGBA).
A partir de ce moment, dans mon code agal, le mot clé va0 correspondra à mes valeurs XYZ et va1 correspondra à mes valeurs RGBA.
Un VertexAttributes peut contenir jusqu'à 4 valeurs et on y accède comme cela : va0.x, va0.y, va0.z, va0.w .

On peut également injecter des constantes au Shader (28 pour le fragmentShader et 128 pour le vertexShader). Coté AS3, juste avant d'appliquer le Shader, il faut associer un ID à une constante (un Vector.<Number> de 1 a 4 valeurs) ; dés lors , on peut utiliser les constantes dans le code AGAL comme cela vc0.x (pour VertexConstant_0) ou fc0.x (pour FragmentConstant_0) en fonction de si il s'agit d'une constante de vertex ou de fragment.

Concernant la "grammaire" du code AGAL, cela peut se resumer à

ACTION OUTPUT, VAL0 , VAL1
 

en gros, si je veux écrire

var n:Number = VertexAttribute0.x * VertexConstant0.y;
 
cela donnerait

mul vt0.x, va0.x, vc0.y
 

(vt0 -> VertexTemporary0 ; que l'on soit dans un VertexShader ou un FragmentShader, on ne peut utiliser que 8 variables temporaires, l'idée est donc de s'en servir plusieurs fois dans le même code quand on en a besoin de plus)

#9 tlecoz

  • Honoris
  • PipPipPipPipPipPipPipPip
  • 3486 messages

Posté 01 September 2012 - 20:03 PM

Dans Minko, apriori, tu n'as pas à te soucier de ça (enfin si mais pas sous cette forme)

#10 alama.be

    Ceinture Noire

  • Members
  • PipPipPipPipPipPipPip
  • 224 messages

Posté 01 September 2012 - 20:04 PM

Waouw! merci d'avoir prit le temps d'être si explicite.. l'AGAL s'éclaire tout à coup.. on dirait un peu de l'assembleur :) donc, purement séquentiel.

Pour l'idée de l'utiliser pour faire des DSP et donc, de devoir faire des getpixel de mon résultat exprimé en shader à l'écran, mmm on peut tester au cas où, mais je parie que faire ça en AS3 normal (optimisé) ou Alchemy et quand nécessaire en workers sera + rapide..

En fait, je sais que les cartes graphiques actuelles embarque une unité arithmétique, j'ai rêvé 5 mins que peut être, on pourrait les exploiter en Flash.. lol Mais bon, pas de façon direct et rapide.. :S

Je relirais une seconde fois ton post demain.. car là, je suis aux prises avec la nouvelle feature [inline] et ça me prend la tête.. je poste chez Adobe un peu partout pour avoir des explications, je poste les erreurs données par le compilo mais jusque là, personne n'a pu m'expliquer.. je pense que j vais ouvrir un post dédié à ça ici.. :)

Merci encore et au plaisir de te lire..
Ne baisse jamais les bras, car c'est à ce moment là que le miracle risque de se produire..

Site web: http://www.pureas3.org
Twitter: https://twitter.com/PureAS3

Enjoy with Flash Player :-)

#11 tlecoz

  • Honoris
  • PipPipPipPipPipPipPipPip
  • 3486 messages

Posté 01 September 2012 - 20:24 PM

Citation

mais je parie que faire ça en AS3 normal (optimisé) ou Alchemy et quand nécessaire en workers sera + rapide..

C'est à tester, je ne sais pas. Mais comme dit plus haut, la zone à dessiner étant très restreinte (moins de 100x100 dans la plupart des cas), je doute que ça prenne plus d'une milliseconde à faire (mais peut être que si).
Je ne connais pas les contraintes liées à Alchemy ou au worker, je ne me rend pas compte ; pour ce qui est de l'AGAL, la plus grosse contrainte (pour moi) vient du fait que le VertexShader s'execute avant le FragmentShader. Le vertexShader represente le triangle d'un point de vue géométrique, le fragmentShader represente les pixels contenus dans le triangle ; autrement dit il n'est pas possible de modifier la position d'un point en fonction de sa couleur de manière directe (car lorsqu'on est dans le vertexShader on a pas accés aux couleurs, et quand on est dans le fragment, on ne peut plus modifier la position des points).


EDIT : C'est quoi au fait un DSP ?

#12 alama.be

    Ceinture Noire

  • Members
  • PipPipPipPipPipPipPip
  • 224 messages

Posté 01 September 2012 - 21:36 PM

Merci Tlecoz, je t'avoue ne pas avoir tout suivi sur ton dernier com (modifier un point..) le fragment est une partie qui compose le shader.. c'est ça?, c'est pourquoi on ne peut plus accéder aux modifs géo (point) de là..

Mais promis, demain, je relis tout ça à tête reposée :)

un DSP, c'est un Processeur de traitement numérique de signal, "Digital Signal Processor".

Voir http://www.dspdimension.com/ pour + de compréhension.

A l'origine, un DSP est une puce précablée ( gravée ) uniquement dans un but précis (reverb, filtre, etc..) par la suite, les DSP ont été des puces programmables "OTP" (On time Programming) on pouvait donc les fabriquer à partir d'un programme (C ou Assembleur).
Donc, pouvoir faire des DSP différents à partir de la même puce. Le principe est que 1 bit se présentait sous forme d'un micro fusible, une fois brûlé (par programmation à l'aide d'un matériel adéquat) il ne pouvait plus être reprogrammer.. Puis sont arrivé les puce reprogrammables comme le sont les EEPROMs (nos petites mémoires flash actuelles).

Et forcément, en informatique, le nom de DSP est resté, mais il s'agit en fait d'un script spécialisé, c'est souvent assez mathématique.. on Utilise même MathLab pour développer les algorithmes.

Perso, je suis passionné d'Audio et de technique Audio. Voilà pourquoi je m’intéresse à la vitesse en Flash.. :-) car les DSP sont souvent très lourds! surtout pour les FFT (série de fourrier).. sans renter dans les détails de l'audio, Fourrier à démontré que toutes forme d'onde, même complexe comme un son peut être décomposé en une série d'onde sinusoïdale la fondamentale et ses harmoniques.. et c'est très utile pour faire des trucs qu'on aurait pu penser impossible .. :)

J'espère que ça a répondu assez à ta question :-)

EDIT: Par exemple, je n'ai jamais trouvé de scanner BPM en AS3 sur le web, tout au plus, on trouve des trucs pas terrible.. j'en ai développé 1 avec un algo vraiment perso et je l'ai mit en vente sur mon site :-) Bon, y a pas foule qui s'intéressera à ça.. mais bon.. voilà quoi ..
Ne baisse jamais les bras, car c'est à ce moment là que le miracle risque de se produire..

Site web: http://www.pureas3.org
Twitter: https://twitter.com/PureAS3

Enjoy with Flash Player :-)

#13 Goabonga

  • Moderateur
  • PipPipPipPipPipPipPipPip
  • 2724 messages

Posté 01 September 2012 - 22:05 PM

d'ou le nom

Voir le messagealama.be, le 01 September 2012 - 20:04 PM, dit :

Waouw! merci d'avoir prit le temps d'être si explicite.. l'AGAL s'éclaire tout à coup.. on dirait un peu de l'assembleur

AGAL == Adobe Graphics Assembly Language

Par contre il y'a pas une diference entre :

"Digital Signal Processor" et "Digital Signal Processing" ?

#14 tlecoz

  • Honoris
  • PipPipPipPipPipPipPipPip
  • 3486 messages

Posté 02 September 2012 - 00:37 AM

Citation

Merci Tlecoz, je t'avoue ne pas avoir tout suivi sur ton dernier com
Pareil ! :D

Citation

Mais promis, demain, je relis tout ça à tête reposée :)
Pareil :D

Citation

(modifier un point..) le fragment est une partie qui compose le shader.. c'est ça?, c'est pourquoi on ne peut plus accéder aux modifs géo (point) de là..
Un shader est composé de deux parties :
- le VertexShader qui gère le positionnement de tes points en 3D. Par exemple, si tu veux appliquer un mouvement de camera, faire un morphing entre 2 forme disposant du même nombre de points, etc... c'est dans le vertexShader que ça se passe.
- le fragmentShader qui gère le rendu (traduit en terme de valeur RGBA) de chaque pixel contenu dans le triangle qui vient d'être traité par le vertexShader. Si tu veux appliquer un effet de lumière, une ombre, du flou, etc... ou même simplement afficher une texture, c'est dans le fragmentShader que ça se passe.


histoire d'être plus clair, je vais essayer de te donner l'équivalent AS3 de ce qui passe quand tu execute un Shader


var nbTriangle:int = 10 000;

function Shader(){
         var i:int,j:int;
       
          //vertexShader ------------------------------
          //Triangle et meshTriangle n'existent pas,
          //c'est des pseudo objets pour expliquer
          var triangle:Triangle
          var v3D:Vector3D;
          for(i=0;i<nbTriangle;i++){
                        triangle = meshTriangles[i];
                        for(j=0;j<3;j++){
                                  v3D = triangle.points[j];
                                  //
                                  // UN VERTEX SHADER CONCERNE CE QUI
                                  // SE TROUVE DANS CETTE SECONDE BOUCLE
                                  //ET EST EXECUTE 3 FOIS (1 FOIS / POINT)
                        }
          }
         //--------------------------------------------------
}
 

Je ne vois pas bien comment représenter le code AS3 qui correspondrait au fragmentShader... Il faudrait ajouter une troisieme boucle, mais je ne vois pas bien comment l'imbriquer car le traitement se fait bien point-du-triangle par point-du-triangle , mais je ne vois pas comment le code fait pour s'éxecuter avant que les 3 points soit traité (permettant de representer une surface, donc un nombre de pixel à remplir).

C'est un peu flou pour moi aussi :)

#15 alama.be

    Ceinture Noire

  • Members
  • PipPipPipPipPipPipPip
  • 224 messages

Posté 02 September 2012 - 11:08 AM

Voir le messageGoabonga, le 01 September 2012 - 22:05 PM, dit :

Par contre il y'a pas une diference entre :
"Digital Signal Processor" et "Digital Signal Processing" ?

Salut Goabonga,

Non pas de différence, enfin si, car à l'origine, la conception d'un DSP à toujours débuté par un script, un algorithme mathématique. Il suffit de jeter un oeil (sans lire) mais en scrollant cette page pour le voir..
http://en.wikipedia....urier_transform

Le souci, c'est que les CPU d'avant étaient bien trop lents pour pouvoir exécuter de tels scripts en temps réel, alors, on en faisait des Digital Signal Processor.

il faut distinguer 2 type de DSP les temps réel qui sont capable de traiter un signal et de le restituer le signal instantanément (ou preque) et les autres qui peuvent traiter un signal dans un temps indéfini et dont le résultat est récupérable par la suite.

Par exemple, en 3D si un Renderer pouvait s'appeler un DSP, on aurait les "real time" comme ici Flash player et les moteur de jeux. et les autres comme Maxwell, V-ray, Brazil, etc..

Donc, Digital Signal "Processor" est une puce éléctronique, du Hardware, c'est un CPU spécialisé qui a été conçu que pour cette tâche. De nos jours, les CPU PC ont atteint une telle puissance qu'il est de + en + possible de faire tourner du "Real Time Digital Signal Processing".

Donc, Processing veut juste dire "traitement", et Processor est l'objet capable de faire le traitement.. qu'il soit 100% logiciel ou Hardware, La logique voudrait qu'on doive renommer DSP en DSS (Script) Mais bon .. au moins, DSP on connait.

Les DSP peuvent servir à plein de choses, Audio, Video, Image, etc

Voilà des exemples de script qui traite justement des FFT (les FFT étant sans doute la partie la plus complexe des DSP)
http://www.idlcoyote...ft_secrets.html

Je pense qu'on pourrait introduire la notion de DSP dans la 3D .. car quelque part, un Ray Tracer est sensé calculer et simuler la lumière d'une scène. Hors en réalité la lumière est une onde électromagnétique au même titre qu'une onde Radio. Elle pourrait très bien être abordée comme telle et abandonner la notion de "photon" D'ailleurs, vous allez rire, mais je pense de + en + que le photon n'existe pas.. :)

EDIT: J'ajouterai qu'avec les DSP on a le même souci que vous en 3D avec les moteurs de rendu, un rendu précalculer (maxwell) sera toujours + précis et complet qu'un rendu temps réel.. la cause en est la puissance actuelle des CPU. c'est idem pour les DSP. C'est pourquoi le matériel Audio continue à utiliser des vrais DSP en dur (Pionner, Yamaha, etc..)

Je pense même que ce ne serait pas faux de déclarer qu'un GPU est "quelque part" une sorte de DSP :-)
le décodage H264 est confié à un DSP et à présent, il est intégré au GPU.
Ne baisse jamais les bras, car c'est à ce moment là que le miracle risque de se produire..

Site web: http://www.pureas3.org
Twitter: https://twitter.com/PureAS3

Enjoy with Flash Player :-)

#16 alama.be

    Ceinture Noire

  • Members
  • PipPipPipPipPipPipPip
  • 224 messages

Posté 02 September 2012 - 11:51 AM

@ tlecoz

Merci, j'ai compris! le vertex est intimement lié au mesh initial de la modélisation, qui est toujours décomposé en triangles (plus petite instance composant un mesh) et le fragment va contenir le code relatif au rendu (texture (couleur, jpg, etc), lum, bump, etc..) qui lui aussi aura été décomposé pour chaque triangle (issu d'une map objet + ses shaders) ..

Pour l'imbrication, il est probable que les fragments sont stockés dans des vector et chaque vector lié à chaque vertex, de toute façon, si j'ai bien compris, c'est le traitement des fragments qui fera le rendu final qui lui même sera influencé par les vertex (qui influencera le rendu en terme de position géométrique du triangle).

Donc, dans notre idée de se servir de ça pour faire un calcul, mon calcul sera un shader, qui deviendra des Fragments.. il faut après rendu que j'aille faire un getPixels de mon objet de rendu, mais là, c'est "ecran" donc, retour en 2D, peut être, simplement faire un screen capture avec bitmapData .. ça sous entend que mon objet 3D initial devra plutôt être un 2D alors.. genre un plane.. ou si c'est un cube, je ne peux traiter que la face (face camera) et 100% perpendiculaire à la cam.

Mais bon, quand j'aurais le temps, j'investiguerai un peu la 3D native avec Stage 3D. j'ai toujours pensé qu'il était important de bien comprendre les mécanismes natifs avant d’utiliser un outil comme unity où on sait faire des jeux, même sans comprendre la 3D .. :)

En DSP, on bosse souvent avec des Number (32 bit) donc, un seul pixel RGBA peut être un number.. un DSP va traiter la plupart du temps un Buffer de 4096 Samples Stereo, soit 4096 * 2 pixels, donc, 8192 pixels RGBA.. c'est rien du tout ça! et ce, toute les 40 ms en moyenne .. 40ms = 1/0.040 = 25 FPS .. c'est 100% jouable en Stage 3D qui peut atteindre 60 FPS .. :) A voir la latence générée par ce traitement (temps de rendu + temps de reprise des résultat en 2D)

A creuser moi j'dis!

Edit: Ou alors, un objet 3D comme un cube, voir meme complexe, ou chaque face contient le résulat d'un calcul (rendu d'une face, voir même d'un seul triangle) et je recompose mon résultat en orientant ma camera (axe de la normal du triangle) pas à pas afin de capturer mes résultats.. :) (faudra bannir les Smooth dans mon cas, ( j'espère que le GPU ne smooth pas d'office ou que c'est désactivable)
Ne baisse jamais les bras, car c'est à ce moment là que le miracle risque de se produire..

Site web: http://www.pureas3.org
Twitter: https://twitter.com/PureAS3

Enjoy with Flash Player :-)

#17 alama.be

    Ceinture Noire

  • Members
  • PipPipPipPipPipPipPip
  • 224 messages

Posté 02 September 2012 - 12:34 PM

Voir le messagetlecoz, le 01 September 2012 - 20:24 PM, dit :

C'est à tester, je ne sais pas. Mais comme dit plus haut, la zone à dessiner étant très restreinte (moins de 100x100 dans la plupart des cas), je doute que ça prenne plus d'une milliseconde à faire (mais peut être que si).
Je ne connais pas les contraintes liées à Alchemy ou au worker, je ne me rend pas compte ; pour ce qui est de l'AGAL, la plus grosse contrainte (pour moi) vient du fait que le VertexShader s'execute avant le FragmentShader. Le vertexShader represente le triangle d'un point de vue géométrique, le fragmentShader represente les pixels contenus dans le triangle ; autrement dit il n'est pas possible de modifier la position d'un point en fonction de sa couleur de manière directe (car lorsqu'on est dans le vertexShader on a pas accés aux couleurs, et quand on est dans le fragment, on ne peut plus modifier la position des points).


J'ai relu! :-)

Ben en fait, je crois que c'est pas un souci.. c'est plus simple que ça, je construit mes math en AGAL que j'applique comme shader à un objet (plane ou quoi) ou même un seul triangle, je n'ai pas à m'occuper des vertex, je dois juste faire un rendu 100% dans l'axe de la normal et après rendu, capturer le résultat pixels.. bon, là, je ne sais pas encore qu'elle serait la meilleure méthode, mais je pense un simple bitmapData. comment sait'on que le rendu est "done?" il y a un event ou un signal a exploiter? parce que c'est important d'aller vite! Rendu > capturepixel. Sinon, je devrais introduire une latence du genre EnterFrame et ça, c'pas bon.. enfin.. ca fera 16ms de latence forcée .. mais why not.. c'est pas si énorme, on estime que en dessous de 10 ms, l'oreille humaine ne peut pas la percevoir.. mais dans la réalité, même 20ms, peut de gens l'entendent..

EDIT: Par hasard, quelqu'un sait si Stage3D n'irait pas + vite que 60 FPS? car comme ça n'a rien avoir la DisplayList, on ne sait jamais..
Ne baisse jamais les bras, car c'est à ce moment là que le miracle risque de se produire..

Site web: http://www.pureas3.org
Twitter: https://twitter.com/PureAS3

Enjoy with Flash Player :-)

#18 Galacta

    Etudiant Ingénieur

  • Moderateur
  • PipPipPipPipPipPipPipPip
  • 689 messages

Posté 02 September 2012 - 13:46 PM

Il y a pas mal de lib déjà développées pour calculer les FFT sur GPU. ( ex : http://developer.nvidia.com/cuda/cufft )
Word hard, play hard.

#19 Goabonga

  • Moderateur
  • PipPipPipPipPipPipPipPip
  • 2724 messages

Posté 02 September 2012 - 13:47 PM

Tu peux récupérer le stage3D sous forme de bitmapData avec :

stage.stage3Ds[i].context3D.drawToBitmapData(image)
 


#20 alama.be

    Ceinture Noire

  • Members
  • PipPipPipPipPipPipPip
  • 224 messages

Posté 02 September 2012 - 14:27 PM

Merci à vous deux! :-)

@Galacta, c'est super Cuda, mais comment tu veux pouvoir utiliser ça en flash? Surtout que j'ignorais que CUDA embarquait déjà 2 algos bien connus.. même plus besoin de faire cette partie là! :-) Moi qui pensais qu'il ne pouvait faire que de physix .. lol

Citation

FFT algorithms based on Cooley-Tukey and Bluestein

Ouai, en Air alors, ca c'est certain! car même si AVM n'en permet pas l'accès, on peut détourner via des sockets ( comme via Fluorine Aperture que j'ai déjà utilisé et ça fonctionne! ) http://aperture.fluorinefx.com/

Mais ne risque pas t'on de limiter l'appli aux PC ayant NVIDIA? et si Aperture, uniquement Win + NVIDIA .. mais bon, pour le fun, faut essayer quand même !


Cudda est un vrai DSP :mrgreen:

Mais peut être que via AGAL ou AS3, on peut quand même lui filer un code .. On ne peut probablement pas récupérer les infos brutes, mais bon, on peut envisager pour la suite se rabattre sur l'idée du getPixels (méthode proposée si haut par Goabonga).. :)

En tous cas, bonne info !

Je vais laisser ceci en suspend, car j'ai encore d’autres trucs à faire avant.. Mais il est clair qu'il faut explorer ce truc.. :)
Ne baisse jamais les bras, car c'est à ce moment là que le miracle risque de se produire..

Site web: http://www.pureas3.org
Twitter: https://twitter.com/PureAS3

Enjoy with Flash Player :-)

#21 tlecoz

  • Honoris
  • PipPipPipPipPipPipPipPip
  • 3486 messages

Posté 02 September 2012 - 14:30 PM

Citation

EDIT: Par hasard, quelqu'un sait si Stage3D n'irait pas + vite que 60 FPS?
Il me semble qu'il n'est pas possible d'aller plus vite que 60 fps depuis le FP11 (qu'on utilise Stage3D ou pas)

Citation

ça sous entend que mon objet 3D initial devra plutôt être un 2D alors.. genre un plane..
Il existe une fonction dans le GPU 'renderToTexture' qui permet de rendre le contenu de la scène, non pas à l'écran mais dans une texture stocké dans le GPU ; il est donc possible de dessiner tout nos objet 3D complex dans une texture que l'on appliquera sur un plane (qui fera office d'écran) ; C'est d'ailleurs comme cela qu'on gère les effets de postprocessing.

Citation

comment sait'on que le rendu est "done?"
Euh... j'ai pas essayé mais apriori c'est comme BitmapData.draw , c'est "done" à la ligne suivante :)

EDIT : Merci pour tes explications sur les DSP, j'ai bien compris maintenant ! :)

#22 Galacta

    Etudiant Ingénieur

  • Moderateur
  • PipPipPipPipPipPipPipPip
  • 689 messages

Posté 02 September 2012 - 15:40 PM

Voir le messagetlecoz, le 02 September 2012 - 14:30 PM, dit :


Euh... j'ai pas essayé mais apriori c'est comme BitmapData.draw , c'est "done" à la ligne suivante :)

Ca ne m'étonnerait pas, les actions exécutées sont synchrones imo.


Pour Cuda, ou son équivalent ATI, je ne vois qu'Alchemy et peut être NativeProcess ? Je n'ai pas essayé je suppose juste.
Word hard, play hard.

#23 alama.be

    Ceinture Noire

  • Members
  • PipPipPipPipPipPipPip
  • 224 messages

Posté 02 September 2012 - 16:42 PM

Ha ben c'est déjà une belle avancée tout ça! merci bcp ! :-) Bien le coup de la texture stockée dans le GPU.. juste dommage qu'on ne puisse pas récupérer la texture sans devoir l'afficher, mais bon, on ne va se plaindre, c'est déjà pas mal de possibilités..

Désolé de ne ne faire que la théorie pour la moment, mais dès que possible, j'expérimente tout ça en vrai :-)

PS: si c'est done à la ligne suivante, alors, c'est bon! le player est un Stack et si le render est inclus dans ce stack, ça m'arrange.. Parfois, ça a des bons cotés ce système bloquant.. :) (même si je doute quand même que l'affichage soit réellement "done" à coups sûr à la ligne suivante, c'est possible.. tout dépend comment Stage3D gère ça avec la carte graphique..)
Ne baisse jamais les bras, car c'est à ce moment là que le miracle risque de se produire..

Site web: http://www.pureas3.org
Twitter: https://twitter.com/PureAS3

Enjoy with Flash Player :-)

#24 Jean-Marc Le Roux

    Ceinture Noire

  • Minko
  • PipPipPipPipPipPipPip
  • 210 messages

Posté 03 September 2012 - 11:33 AM

AGALMiniAssembler et les shaders AS3 de minko n'ont rien à voir.

AGALMiniAssembler est une classe qui permet de transformer de l'assembleur sous forme de String à de l'assembleur sous forme de bytes dans un ByteArray. AGALMiniAssembler n'est pas un compilateur (pas au sens moderne du terme), ne gère pas la mémoire, ne propose aucune optimisation et ne fait que de la traduction statique String -> ByteArray.

Les shaders en AS3 de minko proposent une API complète - incluant un compilateur JIT - qui permet de transformer du code AS3 tout à fait normal en bytecode AGAL lors de l'exécution. A ce titre, il permet de faire beaucoup de choses indispensables qu'AGALMiniAssembler ne fera jamais:

- c'est du vrai code AS3 : un shader => une classe, vous pouvez hériter d'autres shaders pour faciliter le travail, faire des fonctions, etc... Un exemple du shader le plus simple pour afficher des formes 3D en rouge:


public class RedShader extends Shader
{
  override protected function getVertexPosition() : SFloat
  {
        return localToScreen(vertexXYZ); // project from local 3D to screenspace 2D
  }

  override protected function getPixelColor() : SFloat
  {
        return float4(1, 0, 0, 1); // return red
  }
}
 

D'autres exemples très simples sont disponibles sur github:

- un shader qui affiche la profondeur de chaque pixel
- un shader qui affiche la normale de chaque pixel
- un shader qui affiche la position de chaque pixel
- un shader qui affiche les coordonnées de texture de chaque pixel

- l'allocation mémoire : le compilateur alloue la mémoire automatique. On n'a pas à se soucier des constantes, des temporaires, des textures, des buffers, etc... Tout est géré automatiquement, et bien mieux que notre petit cerveau humain ne pourrait le faire. Il va aussi "compresser" les constantes en fonction de plein de paramètres. Par exemple, si la constante 0 est utilisé 3 fois, elle ne sera allouée qu'une fois. Ca parait simple à faire, mais lorsqu'on code plus que 3 lignes c'est presque impossible de se rappeler de quelle valeur va où...

Dans l'exemple du RedShader ci-desuss par exemple, l'allocateur mémoire ne va pas allouer le float4 (1, 0, 0, 1), il va allouer un float2 (1, 0) et utiliser le masque xyyx. Il économise donc déjà 2 constantes sur un exemple ultra simple. Ce genre d'opérations - qui paraissent naïves - sont pourtant extrêmement compliquées à faire pour un développeur, surtout lorsque le programme évolue et qu'il n'est pas possible de connaître à l'avance les valeurs exactes qui sont passées bien évidemment...

- l'optimisation du code : AGAL est limité à 200 instructions. Il est donc important d'éviter toute opération inutile. Le compilateur va - par exemple - s'assurer qu'aucun calcul n'est fait 2 fois, que le code mort est éliminé et que certaines opérations sont regroupées.

Le compilateur va par exemple détecter que certains calculs sont invariants par rapport au contexte d'évaluation du shader. Ex:

add(3, 7)

C'est un exemple naïf, mais il se présente plus souvent qu'on ne le crois. Il est de toute façon très dur de voir ce qui est constant et ce qui ne l'est pas. Le compilateur fait ce travail pour vous. S'il le peut, il exécutera le calcul une fois et remplacera l'opération par le résultat (quelque chose que le compilateur Flash actuel ne fait même pas, au passage...).

Si l'opération ne peut pas être effectuée statiquement (si elle dépend de constantes), alors le compilateur va la déférer au CPU et donc épargner éventuellement des dizaines d'opérations inutiles sur le GPU, économisant ainsi beaucoup de cycles et d'instructions AGAL qui sont en nombre limité (200).

Il y'a encore d'autres optimisations trop compliquées à expliquer ici :)

- la compilation JIT : le compilateur peut recompiler des shaders automatiquement lorsque c'est nécessaire. Chaque shader peut ainsi gérer des milliers de cas de figure différents, là où un programme AGAL n'en gère qu'un. Exemple : gérer plusieurs lumières, plusieurs influences par bones, etc... C'est entièrement transparent : on écrit un shader, on met des if, des for, etc... et quand les conditions de ces if/for changent, alors le programme est recompilé pour créer le bytecode AGAL qui correspond.

Un shader AS3 peut donc donner des centaines de milliers de programmes AGAL différents et répondre donc à tous vos besoins lorsque vous développer votre application.

Vous pouvez même faire des shaders qui ont des résultats différents en hardware, software, iPhone, android, etc... Juste avec un "if", le compilo s'occupe ensuite de faire tout ce qu'il faut quand il faut.

- l'API de data binding : elle permet de passer des valeurs entre le code métier/la scène et les shaders.


// get the "diffuseColor" mesh parameter, of size 4 with default value = 0x000000ff (black)
diffuseColor = meshBindings.getParameter('diffuseColor', 4, 0x000000ff);
 

Le code ci-dessus montre comment on récupère des données depuis le (matériau du) mesh. L'API de data binding permet d'utiliser des matériaux très simplement :


var mat : BasicMaterial = new BasicMaterial();

mat.diffuseColor = 0xff0000ff; // red
cubeMesh = mat;
 

Mais elle permet aussi des choses beaucoup plus subtiles : des matériaux dynamiques, des propriétés partagées, etc...

L'API de data binding permet aussi - et c'est un gros intérêt de la compilation JIT - de changer ce que fait une shader en fonction des informations disponibles dans la scène/sur le mesh. L'exemple ci-dessous est une boucle dont le nombre d'itération dépend (en gros) du nombre de lumières dans la scène :


for (var lightId : uint = 0; lightId < sceneBindings.getConstant('numLights'); ++lightId)
{
  // do lighting stuff for the 'lightId' light
}
 

Le code ci-dessus donnera un programme AGAL différent en fonction de la valeur de la constante 'numLights'. On ne connait pas cette valeur car elle dépend (à priori) du nombre de lumières dans la scène (logique). Il faut donc ré-évaluer ce shader dés qu'une lumière sera ajoutée/enlevée.

Grâce à l'utilisation de l'API de data binding, c'est fait automatiquement. Dés que la valeur 'numLights' qui est sur les bindings de la scène change, alors l'API va ré-évaluer, re-compiler et ré-uploader le shader et l'utiliser à la frame suivante.

Comment faire pareil en AGAL ? Il faut écrire tous les shaders possible ! Avec 4 types de lumières (point, directional, spot, ambient) et jusqu'à 15 lumières par shader, ça fait plus de 3000 shaders différents possibles... Alors qu'en AS3 shaders, on en écrit 1 et une boucle for.

- les "shader parts" : comme c'est du code AS3 tout ce qu'il y'a de plus normal, on peut faire des fonctions utiles et les regrouper dans des classes en fonction de leur but. C'est ce qu'on appelle des "shader parts", des sortes de helper qui permettent de facilement ré-utiliser/partager du code.

Ex: ajouter de l'éclairage dynamique + des animations par skinning et/out morphing sur notre shader "rouge":



public class RedShader extends Shader
{
  private var _animation : AnimationShaderPart;
  private var _phong : PhongShaderPart;

  public function RedShader()
  {
        _animation = new AnimationShaderPart(this);
        _phong = new PhongShaderPart(this);
  }

  override protected function getVertexPosition() : SFloat
  {
        return localToScreen(_animation.getAnimatedVertexPosition()); // project from local 3D to screenspace 2D
  }

  override protected function getPixelColor() : SFloat
  {
        return _phong.applyPhongLighting(float4(1, 0, 0, 1));
  }
}
 

Avec donc seulement deux appels de méthodes, ce petit shader gère maintenant les animations par skinning/morphing avec un nombre infini de bones/influences et l'éclairage de Phong avec un nombre (bientôt) infini de lumières, le normal mapping, le parallax mapping, les ombres projetées.

Est-ce que c'est magique ? Certainement pas ! Ces shader parts sont juste des classes avec du code AS3, qui utilise exactement la même API que celle que n'importe quel développeur AS3 a à sa portée. Ce sont juste des fonctions utiles déjà codées que vous pouvez ré-utiliser. Et donc n'importe qui peut en faire de même pour ajouter des nouvelles fonctionnalités.

Par exemple, le PhongShader utilise le PhongShaderPart et le DiffuseShaderPart pour 1) obtenir une couleur diffuse 2) lui appliquer l'éclairage. Le RealisticShader fait exactement pareil, mais il se sert en plus de l'EnvironmentMappingShaderPart pour ajouter des réflexions.

Pas de magie... juste du code AS3 tout ce qu'il y'a de plus normal, des classes qui en instancient d'autres et qui appellent des méthodes. Tu as besoin d'éclairage de Phong ? Une ligne de PhongShaderPart et voilà... Tu veux faire ton propre syst-me d'éclairage ? Tu as tout le code disponible et tu peux le partager/réutiliser.

Citation

Je ne connais pas les contraintes liées à Alchemy ou au worker, je ne me rend pas compte ; pour ce qui est de l'AGAL, la plus grosse contrainte (pour moi) vient du fait que le VertexShader s'execute avant le FragmentShader. Le vertexShader represente le triangle d'un point de vue géométrique, le fragmentShader represente les pixels contenus dans le triangle ; autrement dit il n'est pas possible de modifier la position d'un point en fonction de sa couleur de manière directe (car lorsqu'on est dans le vertexShader on a pas accés aux couleurs, et quand on est dans le fragment, on ne peut plus modifier la position des points).

Tu peux stocker une couleur RGB(A) dans chaque vertex. Le problème c'est que généralement, par ce que c'est déjà horrible d'écrire de l'AGAL, les moteurs 3D limitent la définition d'un "vertex" et ne gère que la position, la normale et les coordonnées de texture par exemple.

Dans Minko, tu as une API complète qui permet de créer toutes les composantes de vertex que tu veux et de les récupérer dans les shaders. Il y'a le PointExample (sources) qui fait exactement ça : il définit des attributs custom pour chaque vertex et s'en sert pour animer (simplement) des particules sur le GPU. Un développeur l'a par exemple réutilisé pour faire le plancton dans sa démo de sous marin.

Citation

Euh... j'ai pas essayé mais apriori c'est comme BitmapData.draw , c'est "done" à la ligne suivante

Exact. On s'en sert par exemple pour faire des interactions à la souris en utilisant une "picking map". Une des problématiques c'est justement de pouvoir interroger le pipeline de rendu pour savoir quand la picking map est prête est peut-être récupérée. Dans Minko, il y'a un signal Shader.begin et Shader.end pour savoir quand le shader commence et quand il finit. Avec un callback sur Shader.end, on peut forcer le rendu dans une BitmapData et s'en servir par la suite sur le CPU.

Citation

mais je parie que faire ça en AS3 normal (optimisé) ou Alchemy et quand nécessaire en workers sera + rapide.

Si c'est du traitement d'image/de signal, aucune chance. Sur un GPU, il y'a des centaines de pipelines en parallèle. Donc l'équivalent - en gros - de centaines de CPU qui sont - en plus - spécialisés pour faire ce genre de calculs.

Citation

Alama, je pense que tu peux aisément faire du calcul par GPU en utilisant Alchemy et les lib de NVIDIA et ATI

Non. Alchemy ne permet pas de faire ce que la VM Flash ne gère pas. Alchemy permet juste de faire en C++ ce que l'on peut faire en Flash. Ca fait même moins de chose, mais certainement pas plus :(

Modifié par Jean-Marc Le Roux, 03 September 2012 - 11:49 AM.


#25 tlecoz

  • Honoris
  • PipPipPipPipPipPipPipPip
  • 3486 messages

Posté 03 September 2012 - 12:10 PM

Hello Jean-Marc !

Citation

AGALMiniAssembler et les shaders AS3 de minko n'ont rien à voir.
Désolé si la comparaison t'a choqué, ce n'était pas le but...

Je ne comprend pas cette phrase

Citation

Dans Minko, il y'a un signal Shader.begin et Shader.end pour savoir quand le shader commence et quand il finit
Le Shader n'est pas toujours fini après l'appel de drawTriangles ?
Naivement j'aurai géré le mousePicking mesh-par-mesh, quel est l'intérêt de le faire shader-par-shader ?


PS : tu devrais copier-coller ta réponse à la suite de ton post sur Minko :)

#26 Jean-Marc Le Roux

    Ceinture Noire

  • Minko
  • PipPipPipPipPipPipPip
  • 210 messages

Posté 03 September 2012 - 12:50 PM

Voir le messagetlecoz, le 03 September 2012 - 12:10 PM, dit :

Désolé si la comparaison t'a choqué, ce n'était pas le but...

Je sais :) C'est juste que je suis frustré de la comparaison.
Mais certains commencent à s'en servir pour faire des trucs foufou.
Par exemple un gamedev chinois m'a montré un moteur de particules accéléré matériellement tout en AS3... j'étais bluffé !

Citation

Le Shader n'est pas toujours fini après l'appel de drawTriangles ?

Shader.end n'est pas exécuté quand le shader a fini de s'exécuter sur le GPU. Il est exécuté quand cette passe de rendu - et tous les draw calls associés - ont été envoyé au GPU. Ensuite, l'appel à Context3D.drawBitmapData() est synchrone et force la synchro. du GPU pour te donner le backbuffer dans une BitmapData.

Le but de ces signaux c'est donc de savoir quand une passe de rendu commence et une autre finie. C'est un peu plus compliqué que ça en réalité, mais c'est un bon résumé.

Pour mieux saisir, tu peux regarder le code de RenderingController.render(), qui effectue la boucle de rendu. Ce qui est magique c'est que malgré la compilation des shaders entièrement dynamique, toute la boucle de rendu est très statique et se contente juste d'itérer sur une lisse de passes et d'exécuter les draw calls associés. C'est pour ça qu'on obtient des perfs inégalable : au final, Minko arrive à faire quasiment la même boucle de rendu que ce qu'on ferait avec Stage3D seul, et le framework n'apporte quasiment aucune surcharge de performances.

Et c'est en grande partie grâce au compilateur JIT de shaders qui, à la volée, compile de programmes statiques optimisés.

Citation

Naivement j'aurai géré le mousePicking mesh-par-mesh, quel est l'intérêt de le faire shader-par-shader ?

On ne le gère pas "mesh par mesh" car ça n'est pas possible. Certains meshes sont "pickables", d'autres sont des occluders. Donc ça ne sert pas à grand chose de dessiner juste un mesh à la fois.

On ne le fait pas non plus "shader par shader". Le principe c'est qu'il y'a qu'un shader de picking. Concrètement, comme ce shader en AS3 gère les animations (crucial si on veut que les interactions à la souris soient cohérentes), il donnera lieu à plusieurs programmes AGAL. Par exemple :
- un programme AGAL qui ne gère aucune animation
- un programme AGAL qui gère le morphing
- un programme AGAL qui gère le skinning avec 1 influences
- un programme AGAL qui gère le skinning avec 2 influences
- un programme AGAL qui gère le skinning avec 3 influences
- etc... (judqu'à 8 influences à priori)

Donc à vue de nez, ce simple shader AS3 donnera lieu a donc jusqu'à 10 shaders AGAL à l'exécution. Et donc autant de passes (1 programme AGAL => 1 passe). Ce qu'il se passe c'est que, comme expliqué plus haut, on n'écrit qu'un seul shader AS3 mais que ce dernier sera recompilé (pour donner un des programmes AGAL listé ci-dessus) lorsque c'est nécessaire. Chaque Shader donne donc lieu à plusieurs passes, qui sont appelée dans Minko des ShaderInstance. Chaque ShaderInstance est un fork d'un Shader original, à savoir le programme AGAL compilé qui correspond aux contexte d'exécution (ici juste le nombre d'influences pour le skinning à priori).

Chacune de ces ShaderInstance est donc une passe de rendu. On peut utiliser ShaderInstance.begin et ShaderInstance.end pour savoir quand chaque passe commence/finit. On peut utiliser Shader.begin et Shader.end pour savoir quand la première passe du Shader en question commence (begin) ou quand la dernière passe termine (end) d'être envoyée au GPU.

Dans le cas du picking, le procédé est simple :
1) clear en 0 puis passe de picking map
2) récupération de la picking map dans une bitmap et clear du backbuffer avec la couleur d'origine
3) récupération du pixel sous la souris
4) dispatch des signaux correspondants
5) dessin normal de la scène

En marquand ça séquentiellement, ça parait super simple. Mais dans un scène avec plein de passes de rendu, d'effets et de matériaux différents, c'est beaucoup plus complexe! Donc les signaux begin/end servent à rendre possible l'interception de certaines étapes de rendu.

Enfin, le compilateur de shaders est aussi un élément clef, car il permet de juste injecter un seul shader dans l'effet de rendu de chaque Mesh sans se préoccuper de combien de programmes AGAL seront effectivement utilisés sur le GPU.

#27 tlecoz

  • Honoris
  • PipPipPipPipPipPipPipPip
  • 3486 messages

Posté 03 September 2012 - 14:24 PM

Merci pour cette réponse très complète !
Je pense avoir compris le principe :)




Est il possible de créer un nouveau Shader dans Minko, lui injecter le code agal ainsi que la liste des constantes/vertexAttributes (et leur id) et faire en sorte qu'il s'intègre avec le reste du framework ?

Je sais que l'intérêt semble limité dit comme ça, j'ai bien compris que coder ses Shader avec Minko permettait de ne pas avoir à se soucier des constantes/temporaires/variables partagées/etc..., que le code était optimisé etc...

Mais admettons que je tombe sur un Shader sur Wonderfl dont le code m'échappe complètement ; y a t il un moyen de "copier coller" le code qui concerne le shader dans Minko ?

Ou d'une manière générale, admettons qu'un nouvel outil sorte permettant de coder des Shaders plus facilement qu'il n'est possible de le faire dans Minko ; serais je capable d'utiliser cet outil en binome avec Minko ou est ce que c'est tout ou rien ?

#28 alama.be

    Ceinture Noire

  • Members
  • PipPipPipPipPipPipPip
  • 224 messages

Posté 03 September 2012 - 15:17 PM

Merci BCP Jean-Marc d'avoir prit le temps de nous écrire tout ça! :-)

Je t'avoue ne capter que la surface, mais c'est déjà bien! :-)

Cool le signal "END" pour rendering.

Dernière question (pour ne pas perdre 10 ans peut être pour rien) , Galacta m'a fait constater que NVIDIA CUDA possédait des routines FFT intrinsèques, Est-il envisageable de les utiliser d'une façon ou d'une autre?

Merci, à bientôt ;-)

PS: je vois que partout, on part de classes abstraites, (override), il y a une bonne raison à ne pas avoir utilisé des interfaces, ou c'est purement une question d'habitude de codage?

Je répond tout seul lol, sans doute pour ne pas être obligé d'implémenter toutes les méthodes des classes.. c'est bien ça?
Ne baisse jamais les bras, car c'est à ce moment là que le miracle risque de se produire..

Site web: http://www.pureas3.org
Twitter: https://twitter.com/PureAS3

Enjoy with Flash Player :-)

#29 Jean-Marc Le Roux

    Ceinture Noire

  • Minko
  • PipPipPipPipPipPipPip
  • 210 messages

Posté 03 September 2012 - 15:27 PM

Citation

Est il possible de créer un nouveau Shader dans Minko, lui injecter le code agal ainsi que la liste des constantes/vertexAttributes (et leur id) et faire en sorte qu'il s'intègre avec le reste du framework ?

Techniquement, c'est possible. On a déjà pensé à le rajouter.
C'est plus un problème idéologique que technique (voir plus bas).

Citation

Mais admettons que je tombe sur un Shader sur Wonderfl dont le code m'échappe complètement ; y a t il un moyen de "copier coller" le code qui concerne le shader dans Minko ?

Généralement, tout les shaders AGAL se portent très très rapidement en AS3. Puisque c'est plus simple à écrire et qu'il n'y a pas tous les bugs d'allocations mémoires et consort. L'inverse n'est pas vrai évidemment. Les programmes AGAL compilé par Minko sont - du fait des optimisations - plus courts mais aussi plus compliqué à lire. En même temps c'est normal : personne n'est censé lire du bytecode :)

Donc je ne pense pas que ce soit le meilleur use case.

Par contre, on avait à un moment la possibilité d'utiliser des shaders en AGAL directement. Ca n'est pas très dur à rajouter dans l'API. C'est juste que jusqu'ici, je pense que s'il y'a très peu de shaders créés par la communauté, c'est justement par ce que tout le monde parle trop d'AGAL sans en comprendre les limites, et s'intéresse trop peu à ce qui se fait autour (les shaders AS3 n'en sont qu'un exemple).

Je pense que chaque personne qui a fait de l'agal a passé plus de temps à allouer la mémoire qu'à vraiment implémenter des choses intéressantes. C'est pour ça que je me "bats" pour que les gens arrêtent de faire de l'AGAL et apprennent à programmer un GPU plutôt qu'à allouer la mémoire de tête. Du coup, ça serait un contre sens de proposer ça. D'un point de vu idéologique, on essaie de pousser les gens à faire des bons choix. Ca apparaît au début comme une contrainte, mais les développeurs comprennent généralement très vite qu'en fait ça leur apporte beaucoup.

Citation

Galacta m'a fait constaté que NVIDIA CUDA possédait des routine FFT intrinsèques, Est-il envisageable de les utiliser d'une façon ou d'une autre?

Stage3D implique d'utiliser le modèle Shader 2.0, donc pas de CUDA.

Je ne sais pas si une FFT est implémentable avec le peu d'opérations permises. Mais si ça t'intéresse, nous avons implémenté les fonctions qui nous manquaient comme acos, asinatan avec des approximations qui se sont révélées utilisables dans la pratique. C'est pas aussi compliqué qu'une FFT, mais ça montre qu'on peut rajouter des fonctions mathématiques.

C'est un des bienfaits des shaders en AS3 : on implémente une fonction AS3 toute bête et elle peut-être réutilisée quand on veut sans se soucier des allocations, du mapping mémoire, des effets de bord, des doublons, etc...

#30 alama.be

    Ceinture Noire

  • Members
  • PipPipPipPipPipPipPip
  • 224 messages

Posté 03 September 2012 - 15:42 PM

Merci JM :) je pense que déjà si j'arrive à utiliser le GPU pour lui faire rendre une image résultat (pixel) d'une FFT écrite en AS3, ça sera déjà bien plus rapide que ce qui existe à l'heure actuelle sur Flash Player.. Après, pour le fun, si je veux utiliser CUDA, Je passerai en AIr qui peut lancer un exe fait en .net ou C ou autre.. Mais le but 1er de rester en web player.. :)

Le seul truc qui me fait peur, c'est que dans 99% des cas, les maths appliquées sont dans un boucle de parcours d'un ByteArray.. et là, je ne sais aps du tout comment ça peut fonctionner en 3D .. au pire, on peut toujours le convertir en Vector ou en LinkedList .. mais avec la perte de temps qui va avec.. Bon, je vais arrêter de te faire écrire, je vais d’abord prendre du temps, pour essayer de tester et comprendre tout ça..

Donc, à dans 6 mois.. :mrgreen:
Ne baisse jamais les bras, car c'est à ce moment là que le miracle risque de se produire..

Site web: http://www.pureas3.org
Twitter: https://twitter.com/PureAS3

Enjoy with Flash Player :-)

#31 tlecoz

  • Honoris
  • PipPipPipPipPipPipPipPip
  • 3486 messages

Posté 03 September 2012 - 15:56 PM

Merci de prendre chaque fois du temps pour me répondre :)

Citation

Je pense que chaque personne qui a fait de l'agal a passé plus de temps à allouer la mémoire qu'à vraiment implémenter des choses intéressantes. C'est pour ça que je me "bats" pour que les gens arrêtent de faire de l'AGAL et apprennent à programmer un GPU plutôt qu'à allouer la mémoire de tête.

Complètement d'accord !

Citation

Du coup, ça serait un contre sens de proposer ça. D'un point de vu idéologique, on essaie de pousser les gens à faire des bons choix

C'est un contresens si on considère que le code AGAL a été pondu à la main, ça n'en est pas un s'il a été généré par un outil externe.

Citation

Techniquement, c'est possible. On a déjà pensé à le rajouter.

Chouette ! Je comprend que tu ne le fasses pas pour l'instant (pas pertinent), mais je suis ravi de savoir que c'est possible !

Je ne vais pas trop m'étendre sur le sujet parce que ce n'est pas totalement fini (et donc loin d'être fini de tester), mais je développe en ce moment un outil qui convertit une classe AS3 en code AGAL + liste de constante/attribut (si définis au sein de la classe).
Je ne m'y prend pas du tout comme toi car je n'ai pas créé un framework qui représente les fonctions dispo en AGAL (genre la fonction 'add') , je "scanne" le code ligne par ligne et le converti en AGAL ce qui me permet de coder plus naturellement.
Je peux écrire, par exemple,

var n:Number = 2 * 3 +1;
 
par ailleurs, dans le cas de ce calcul, la valeurs attribuer à 'n' sera 7 (c'est a dire le résultat du calcul) et pas le calcul permettant d'obtenir 7 (cette manière de faire n'est valable que si les valeurs utilisé dans le calcul sont toutes numérique)
Au final, mes classes de Shader ressemblent à une classe AS3 extends Object (avec 3-4 mots clé tout de même) ; le code agal généré est optimisé (du moins il le sera), la liste de constante est optimisé autant que possible, le partage de constante est possible, utiliser une constante par point de triangle est possible, ...

L'idée étant de simplifier au maximum l'écriture d'un shader, de rendre ce processus le plus naturel possible pour aller au dela :)
L'idée de base en fait est de pouvoir copier coller des fonctions mathematiques d'un projet as3 dans une classe de Shader et que ça marche direct sans rien changer.

Bref quand ce sera fait, fini, testé, approuvé , ce serait cool de pouvoir l' utiliser avec Minko :D

#32 Jean-Marc Le Roux

    Ceinture Noire

  • Minko
  • PipPipPipPipPipPipPip
  • 210 messages

Posté 03 September 2012 - 16:24 PM

Citation

C'est un contresens si on considère que le code AGAL a été pondu à la main, ça n'en est pas un s'il a été généré par un outil externe.

Oui. Par exemple glsl2agal. C'est pour ça qu'on s'est déjà mis d'accord pour supporter cette feature. Mais c'est pas encore dans la roadmap. C'est pas très long, donc on verra en fonction des besoins.

Citation

Bref quand ce sera fait, fini, testé, approuvé , ce serait cool de pouvoir l' utiliser avec Minko

L'intérêt des shaders AS3, c'est que c'est de l'AS3 dans la VM flash et que c'est donc du JIT.
En transformant du code AS3 en code AGAL statiquement, tu vas peut-être résoudre les problèmes d'écriture du code assembleur AGAL.
Mais tu vas te retrouver avec beaucoup d'autres problèmes qui sont encore plus gros, et qui sont liés justement à une approche statique des shaders qui est, je pense, erronée.

Et donc tu te retrouveras vite extrêmement limité, car tes shaders seront peut-être plus facile à écrire, mais ils seront statiques et ne pourront gérer même pas 1/1000 des problématiques qui interviennent réellement lorsque tu fais un projet 3D, aussi simple soit-t-il.

Comment vas tu gérer les formats de vertex custom ?
Comment vas tu gérer le fait qu'on aie parfois besoin des tangentes, parfois des normales, parfois de deux ?
Comment vas tu gérer le fait que certaines objets sont animés, d'autres pas ?
Comment vas tu gérer le fait que certains objets sont skinnés, d'autres morphés, certains les deux ?
Comment vas tu gérer le fait que le nombre d'influences par vertex varie ?
Comment vas tu gérer le fait de pouvoir linker des symboles d'un shader à un autre pour réutiliser du code ?
Comment vas tu gérer le fait de pouvoir tester si valeur existent au runtime, pour par exemple activer/désactiver les ombres ou l'éclairage ?

Ca se sont les questions auxquelles ils faudra des solutions génériques et robustes ne serait-ce que pour afficher un personnage animé avec juste une lumière. Un cas d'usage pourtant on ne peut plus simple je pense qu'on est tous d'accord là dessus.

En gros, tu auras un truc qui fait AS3 -> AGAL, mais qui sera moins bien que le truc qui fait GLSL -> AGAL (par ce que GLSL est plus utilisé et que ce compilo est déjà optimisé) et surtout qui n'apportera aucune réponses aux problèmes susmentionnés. C'est sans doute pour ça qu'Adobe a arrêté le développement de PixelBender3D : ça n'apportait rien, et glsl2agal apporte au moins la possibilité d'utiliser GLSL. Tu vas donc juste apporter un énième langage de shaders qui en plus d'avoir les défauts de l'AS3 (qui n'est pas fait pour ça) aura aussi les défauts de GLSL (qui lui, au moins, est fait pour ça).

Pas très intéressant comme deal au final :s

J'ai l'impression que tu penses que faire un compilo statique sera mieux. Mais c'est tout l'inverse.
Même pour l'argument des performances, on ne compile que très rarement des shaders et lorsque ça arrive, ça ne prend que quelques millisecondes (on perd une frame au pire) et c'est entre autre par ce que c'est dynamique avec un AST implicite qui ne nécessite pas de lexing/parsing. Donc le compilateur dynamique de Minko sera - je pense- beaucoup plus rapide qu'un compilateur en AS3 qui lexe/parse de l'AS3.

Bref, la programmation GPU n'est pas une question de complexité du langage.
C'est une question de workflow/pipeline, et c'est ça le gros avantage d'un compilateur JIT et des shaders AS3. Pas le langage lui même qui ne présente que peu d'intérêt pour le GPU.

Citation

par ailleurs, dans le cas de ce calcul, la valeurs attribuer à 'n' sera 7 (c'est a dire le résultat du calcul) et pas le calcul permettant d'obtenir 7

C'est déjà ce que fait le compilateur de Minko :)

Il fait même bien plus poussé que ça, car il analyse l'arbre de calcul pour trouver tout ce qui est statique ou tout ce qui ne dépend pas du GPU et le déferrer au CPU automatiquement. Il fait donc une sorte de load balancing CPU VS GPU automatique en fonction des calculs qui sont faits dans le programme et des constantes utilisées.

Et il faut tout ça JIT. Donc ça évolue en fonction des besoins de l'application. Quelque chose d'impossible avec un compilateur statique, par définition.

Je t'encourage à utiliser les flags de debug DebugLevel.SHADER_DOTTY (graphes à visualiser avec graphviz) et DebugLevel.SHADER_AGAL pour constater à quel point le programme de sortie est bien plus optimisé que celui qui aurait été écrit à la main. Généralement, j'ai du mal à comprendre les graphes sortis par DebugLevel.SHADER_DOTTY tellement ils ont été optimisés par le compilateur.

Citation

L'idée étant de simplifier au maximum l'écriture d'un shader, de rendre ce processus le plus naturel possible pour aller au dela
L'idée de base en fait est de pouvoir copier coller des fonctions mathematiques d'un projet as3 dans une classe de Shader et que ça marche direct sans rien changer.

Je pense que ça n'est pas possible - et c'est tant mieux - car l'approche SIMD d'un GPU impose une logique différente lors de la programmation. Il y'a donc des optimisations très intéressantes qu'on loupe si on se contente d'arithmétique dans R plutôt que R2, R3, ou R4 comme on peut le faire en SIMD.

Tu peux lire ce sujet ou je donne quelques exemples.

Au final le seul plus que tu auras, c'est de pouvoir utiliser + au lieu de add() et de ne pas avoir de type fourre tout comme SFloat chez nous. Un avantage bien minime quand on considère la liste énorme de problématiques qui resteront sans réponses et impossibles à traiter en raison de la nature même de l'approche par compilation statique. GLSL et HLSL souffrent d'ailleurs des mêmes problèmes, et pour les résoudre les game engines usent parfois de workflow gigantesques et ultra compliqué pour les résoudre (tu peux regarder ce que fait le Source Engine en précompilant des centaines de shaders en forkant les if/for avec toutes les possibilités...).

Au passage, la surcharge d'opérateurs est une des features les plus demandées pour la prochaine version d'AS, donc je pense que cet intérêt là, déjà minime, disparaîtra très vite.

Je pense donc que si tu veux vraiment faire avancer l'affaire codé shaders, c'est pas ce genre de développements qu'il faut. Et que ça t'apprendra peut-être comment générer du bytecode AGAL, mais ça ne t'apprendra absolument rien sur le développment GPU. Vraiment, j'insite : ça n'est pas qu'un problème de langage/syntaxe, c'est un problème d'environnement d'exécution et de workflow author time VS runtime.

Si tu veux t'amuser à écrire un compilo pour écrire un compilo, AGAL est peut-être pas non plus la meilleure target par ce que la ref. d'Adobe est buggée de partout :(

Une bonne idée pour compilé de l'AS3, ça serait un frontend AS3 pour LLVM. Si tu fais ça - entre autre pour de l'AGAL en backend - si ça t'amuse - alors ça, là, oui y'aura beaucoup de choses à faire avec. Mais pas pour des shaders, par ce que LLVM => compilation statique :)

Modifié par Jean-Marc Le Roux, 03 September 2012 - 16:31 PM.


#33 tlecoz

  • Honoris
  • PipPipPipPipPipPipPipPip
  • 3486 messages

Posté 03 September 2012 - 17:03 PM

:)

Citation

Comment vas tu gérer les formats de vertex custom ?
Très simple, je ne gère pas les deux au même endroit :)
D'un coté on créé le VertexDataBuffer en AS3 comme d'habitude, et coté Shader on le récupere comme ça

vertices = VertexAttributes.VextexAttribute_0;
uvts     = VertexAttributes.VextexAttribute_1;
matrix   = VertexConstants.VertexConstant_0;
brushInfos = VertexConstants.VertexConstant_4;
 

Citation

Comment vas tu gérer le fait qu'on aie parfois besoin des tangentes, parfois des normales, parfois de deux ?
Si j'ai besoin de l'un , de l'autre , ou des deux j'aurais des calculs dans mon code qui les utiliseront donc le code correpondant sera généré (je suis à peu près sur de ne pas avoir compris la question car la réponse me semble trop basique)

Citation

Comment vas tu gérer le fait que certaines objets sont animés, d'autres pas ?
Je dois m'y prendre mal car pour moi ce genre de question dépendent essentiellement des constantes que l'on passe au Shader et des calculs qu'on fait dessus.

Une animation se traduit par une constante dont la valeur change à chaque frame. De fait, si je "set" une constante à chaque frame, il y aura une animation sinon non... (comme plus haut, je n'ai sans doute pas compris la question :) )

Mais d'une manière générale, je vais créer une classe permettant d'exploiter plus facilement les données renvoyés par le shader, et permettant si besoin de créer de nouveaux vertexAttributes contenant certaines infos dont j'ai besoin pour faire certains calculs (pour utiliser la structure vc[va0.x] par exemple).

Citation

Comment vas tu gérer le fait que certains objets sont skinnés, d'autres morphés, certains les deux ?
Comment vas tu gérer le fait que le nombre d'influences par vertex varie ?
Comment vas tu gérer le fait de pouvoir linker des symboles d'un shader à un autre pour réutiliser du code ?
Comment vas tu gérer le fait de pouvoir tester si valeur existent au runtime, pour par exemple activer/désactiver les ombres ou l'éclairage ?

Tout ces trucs, je n'ai aucune intention de le faire, soyons clair ! :D
C'est pour ça que je suis ravi que Minko puisse prendre le relais.
Je n'ai jamais essayé de faire mieux que Minko, à aucun moment, mais j'essaye de faire en sorte que l'écriture d'un Shader soit le plus simple possible et si Minko peut prendre le relais ensuite et gérer tout ces cas compliqué, tant mieux, sinon tant pis :)

Toi tu me parles immédiatement de tout les cas de figuire qu'on peut trouver en 3D, de mon coté je pense que les Shaders peuvent servir dans d'autres contextes qui ne nécessitent pas forcément toutes ces prises de têtes (dans le cas des jeux en 2D par exemples, ou des experiences interactive experimentales).

Citation

Au final le seul plus que tu auras, c'est de pouvoir utiliser + au lieu de add()
:)

Si tu ne vois aucun avantage à pouvoir coder la fonction Math.atan2 juste en copiant collant ce code trouvé sur le net et obtenir un résultat immédiat , bah.....

function atan2(dy:Number,dx:Number):Number{
var t0:Number, t1:Number, t2:Number, t3:Number, t4:Number,t5:Number,t6:Number,t7:Number;
   t3 = Math.abs(dx);
   t1 = Math.abs(dy);
   t0 = Math.max(t3, t1);
   t1 = Math.min(t3, t1);
   t3 = 1 / t0;
   t3 = t1 * t3;
   t4 = t3 * t3;
   t0 =    - 0.013480470;
 
   t0 = t0 * t4 + (0.057477314);
   t0 = t0 * t4 - (0.121239071);
   t0 = t0 * t4 + (0.195635925);
   t0 = t0 * t4 - (0.332994597);
   t0 = t0 * t4 + (0.999995630);
   t3 = t0 * t3;
   var t5:Number = (Math.abs(dy) > Math.abs(dx)) ? (1.570796327)        - t3: t3;
   var t6:Number = (dx < 0) ?  (3.141592654) - t5 : t5;
   var t7:Number = (dy < 0) ? -t5 : t5;
   return t7;
}
 

En tombant devant ce genre de code, on a rarement envie de le porter en mode "calcul-par-calcul".
En tout cas pas moi, et c'est d'ailleurs en essayant de porter cette fonction en AGAL, en faisant des erreurs d'inattention que je me suis dit "bordel, ça ne va quand même pas devenir mon quotidien !" et que j'ai entrepris de créer cet outil.

Mais bon, je ne vais pas me lancer dans un débat vu que mon outil n'est pas fini, c'est un peu prématuré.
Ce sera aux autre de me dire s'il trouvent ça utile ou pas...quand il sera fini :)


EDIT :

Citation

Je pense que ça n'est pas possible - et c'est tant mieux - car l'approche SIMD d'un GPU impose une logique différente lors de la programmation. Il y'a donc des optimisations très intéressantes qu'on loupe si on se contente d'arithmétique dans R plutôt que R2, R3, ou R4 comme on peut le faire en SIMD.
C'est également dans ma roadMap. L'étape finale de mon outil consistera à analyser le code AGAL généré pour vérifier qu'on est pas en train de faire à la main une fonction présente en AGAL, ou qu'on a pas des "mov" inutile.

#34 alama.be

    Ceinture Noire

  • Members
  • PipPipPipPipPipPipPip
  • 224 messages

Posté 03 September 2012 - 19:32 PM

Au risque de passer pour un idiot, je lâche mon com quand même.. :)

Je cherche un compiler JIT pour compiler à la volée du langage JM et Tlecoz pour une plateforme XFrench.. looool

Dans le cas de functions comme Arc Tangente, et autre Math, j'aurais également pensé qu'un code précompilé aurait été mieux.. Mais il faut croire que ce n'est pas nécessairement vrai.. le player à la base était interprété (core player pré-compilé) et pourtant, tout va de + en + vers le JIT de l'AVM.. J'ai du mal à la comprendre, car pour moi, il n'existe qu'une seule meilleure optimisation de la séquence des instructions.. (et surtout un jit prend du temps machine) Mais ça restructure sans doute en live en fonctions des variables mises en jeu etc.. Ou alors que le Processeur visé est tellement complexe, que le JIT va adapter en temps réel les instructions générées en fonction de l'état dudit processor (registres, pipelines, etc..) bheuu

Dans le cas d'une scène 3D interactive, je comprend qu'un JIT soit incontournable, car une scène est tellement riche et surtout peu bouger dans n'importe quel sens ( à chaque frame) qu'il serait inconcevable de prévoir toutes les possibilités en pré-compilé..

Si c'pas de ça dont vous parliez, veuillez m'excuser :) mais bon, j'essaye de suivre.. lol
Ne baisse jamais les bras, car c'est à ce moment là que le miracle risque de se produire..

Site web: http://www.pureas3.org
Twitter: https://twitter.com/PureAS3

Enjoy with Flash Player :-)

#35 Jean-Marc Le Roux

    Ceinture Noire

  • Minko
  • PipPipPipPipPipPipPip
  • 210 messages

Posté 03 September 2012 - 22:01 PM

Le JIT a deux grands intérêts : l'optimisation à la volée et la compilation à la volée. La première n'existe en fait pas sans la seconde évidemment. Dans le cas de l'optimisation à la volée, le cas où ça se présente avec un compilateur de shaders est le cas suivant :

J'ai n instructions (200 en AGAL) et m lumières.

Avec une approche statique, soit on met une lumière par passe, et ça n'est pas performant, soit je fais des batch de b lumières par passe, et j'admets donc que la dernière passe devra avoir b % 5 lumières qui seront exécutées mais avec des valeurs à 0 car elles n'existent pas vraiment dans la scène. Le même exemple se pose pour les animations : on va gérer 8 influences (le max à cause du nombres de vertex attributes), mais certaines seront à 0 si elles n'existent pas vraiment. C'est très inefficace.

Avec une approche dynamique, je sais au runtime combien j'ai de lumières et donc je peux adapter le shader en temps réel pour mettre autant de lumière que "possible" par passe (chaque lumière consomme un nombre différent d'instructions, c'est un problème beaucoup plus compliqué qu'il n'y parait). La dernière passe aura juste moins de lumières que les autres : 0 pertes.

Donc oui, la compilation JIT apporte ici un gain en perf sans aucun doute par ce que le code s'adapte à l'environnement d'exécution. Concernant la précisions des approximations mathématiques par exemple, on peut en avoir plus si on est sur desktop par exemple. C'est encore grâce au JIT.

Une prochaine update de Minko intégrera d'ailleurs la possibilité d'avoir une infinité de lumières avec les meilleures performances justement grâce à la compilation JIT.

Citation

Tout ces trucs, je n'ai aucune intention de le faire, soyons clair !

Tu vas donc faire un compilateur de shaders qui ne peut gérer des choses aussi simple que quelques lumières et des animations ? Ca me parait beaucoup de travail juste pour éviter d'écrire add() et pouvoir écrire + tu ne crois pas ? :)
Tu trouves peut-être ça "avancé", mais dis toi que n'importe quelle carte graphique gère ça (avec le FFP ou des shaders) depuis 15 ans... Donc c'est le niveau 0 du programme graphique ou presque. Vraiment.

Si malgré tes efforts en AGAL tu n'arrives pas à ce genre de choses c'est - à mon avis - qu'AGAL - encore une fois - n'est pas fait pour ça et te bride en terme de productivité.

Citation

En tombant devant ce genre de code, on a rarement envie de le porter en mode "calcul-par-calcul".

Ce code n'a aucun intérêt sur un GPU. A priori, il fait déjà 4 fois trop d'instructions par ce qu'il ne travaille sur un float alors que sur un GPU il pourrait travailler sur 4 en même temps. Donc il faudra de toute façon modifier le code pour qu'il soit intéressant. Sinon en 2 atan2 tu aura pété la limite d'instructions. Donc je ne vois pas trop l'intérêt d'avoir atan2 si je ne peux pas vraiment l'utiliser dans un shader qui fait autre chose qu'atan2 :)

Pour le porter en as3 shader, il faut remplacer * par multiply(), + par add() et float par SFloat. Temps de l'opération : 15 secondes ? Résultat : compatible SIMD, utilisable dans n'importe quel shader, mémoire optimisé, nombre d'itérations dynamique en fonction des besoins (plateformes ?), j'en passe et des meilleurs :)

Citation

Je dois m'y prendre mal car pour moi ce genre de question dépendent essentiellement des constantes que l'on passe au Shader et des calculs qu'on fait dessus.

Tu vois c'est ce qui m'ennuie le plus au final : tu fais de l'AGAL pour apprendre, mais la seule chose que tu apprends c'est un langage assembleur mal foutu. Comme c'est mal foutu est pas adapté, tu n'as pas pu faire de la vraie prog. GPU. Si tu avais pu expérimenter avec mieux, comme du GLSL ou du HLSL (ou des shaders AS3...), tu aurais vite compris que le langage n'est pas du tout le problème et qu'apprendre AGAL n'apporte absolument rien.

AGAL n'est pas de la programmation GPU. Ca n'a rien à voir.

Les vraies problématiques de la prog. GPU sont autre part. Et comme AGAL est trop primitif et trop laborieux, tu n'as pas la possibilité de voir en quoi ça consiste vraiment. En l'occurrence, la solution que tu proposes est la solution que j'évoque au dessus, à savoir mettre des influences à 0 dans les vertex pour ne pas avoir d'animations quand il n'y a pas de skinning. Donc tu proposes de perdre des dizaines d'instructions et des milliards de cycles GPU pour faire... rien... juste par ce que tu ne peux pas détecter correctement le cas avec et le cas sans animations.

Citation

Dans le cas d'une scène 3D interactive, je comprend qu'un JIT soit incontournable, car une scène est tellement riche et surtout peu bouger dans n'importe quel sens ( à chaque frame) qu'il serait inconcevable de prévoir toutes les possibilités en pré-compilé..

Alors je pense que tu seras surpris d'apprendre qu'à notre connaissance, Minko est la première techno 3D a embarquer un tel compilateur. Et je ne parle pas de Flash. Je parle en général. UDK, Unity et Source Engine compris. Toutes les autres - mêmes les plus compliquées - passent par des workflow précompilés très très lourds où ont des dépendances très lourdes sur des fonctionnalités très récentes. Je pense que tu as compris exactement les problématiques donc mes pavés ont servi :)

Donc quand on me dit que Minko n'est qu'un énième moteur 3D pour Flash et qu'Away c'est au moins aussi bien...

Modifié par Jean-Marc Le Roux, 03 September 2012 - 22:40 PM.


#36 tlecoz

  • Honoris
  • PipPipPipPipPipPipPipPip
  • 3486 messages

Posté 03 September 2012 - 23:55 PM

Hello !

C'est toujours un plaisir de te lire... :D


Citation

Tu trouves peut-être ça "avancé", mais dis toi que n'importe quelle carte graphique gère ça (avec le FFP ou des shaders) depuis 15 ans... Donc c'est le niveau 0 du programme graphique ou presque. Vraiment.

Je ne trouves pas cela terriblement avancé , il me semble qu'OpenFramework propose une alternative similaire ; je n'ai pas l'impression de proposer un truc complètement fou et démesuré, j'ai l'impression de proposer exactement l'outil dont j'ai besoin pour travailler.
Tu dis que c'est le niveau 0 du programme graphique. Peut être !
En attendant le manière officielle d'utiliser de l'accélération matérielle dans flash, ce n'est pas Minko c'est l'AGAL et il me semble que c'est un peu plus bas niveau que la solution que je propose (et que ça rebute d'ailleurs pas mal de monde d'ou le très faible nombre de démo utilisant Stage3D depuis que ça existe, c'est a dire casiment 1 an)


Citation

Tu vas donc faire un compilateur de shaders qui ne peut gérer des choses aussi simple que quelques lumières et des animations ? Ca me parait beaucoup de travail juste pour éviter d'écrire add() et pouvoir écrire + tu ne crois pas ?

C'est ton point de vue, ce n'est pas le mien :)
J'ai l'impression de me répéter, mais tout le monde n'a pas la prétention de sortir un jeu de fou en 3D avec des éclairages dans tout les sens ! Un jour, peut être, je saurais le faire, mais ce n'est pas sur ma todo-list de l'année 2012-2013 , je ne prévois d'être capable d'entrevoir comment résoudre tout les problèmes dont tu me parles avant 2-3 ans (si je m'accroche, ce qui n'est pas certain). La plupart des devs AS3 avec lesquels je parle n'ont pas du tout la prétention de savoir faire le 1/4 de ce qu'il est possible de faire avec Minko (et moi non plus d'ailleurs).

Le fait est que la plupart des devs AS3 n'ont pas un délais de 3-6 mois pour pondre un jeu AAA ; la plupart des flasheurs font des minisite ou des bannières, voire un minijeu vite fait (qui ressemble plus à une experience interactive qu'autre chose la plupart du temps). Dans le cadre d'un minisite ou d'une bannière, pense tu réellement que l' outil dont je parle soit complètement inutile ? Dans le cadre d'un jeu en 2D (désolé de me répéter), est ce absurde de faire ce que je fais ?!

Je ne crois pas ! Mais il est fort possible que je me trompe, j'admet volontier que je manque d'experience.


Citation

Ce code n'a aucun intérêt sur un GPU
C'est drôle, je l'ai trouvé sur le site de Nvidia pour simuler cette fonction sur le GPU
(EDIT : j'ai un doute à ce sujet et je ne retrouve plus la page, faisons donc comme si je n'avais rien dit :D )
(EDIT2 : non non, je confirme, je l'ai bien trouvé sur le site de nVidia : http://http.develope...m/Cg/atan2.html )

Citation

il fait déjà 4 fois trop d'instructions par ce qu'il ne travaille sur un float alors que sur un GPU il pourrait travailler sur 4 en même temps.
Convertis en AGAL, il travaille sur 4 float je te rassure :)
(EDIT : A vrai dire, il me semble qu'il travaille sur 3 floats mais j'ai la flemme de vérifier...Les variables temporaires sont "recyclé" entre chaque ligne (voire entre chaque calcul en fonction de ce que l'on fait) , peu importe la forme que prend le code as3, le nombre de variable temporaire qu'on utilise "physiquement" dans le code AS3... Au contraire, plus le code AS3 est riche (en nombre de ligne) plus il est facilement optimisable car décomposé)


Citation

Sinon en 2 atan2 tu aura pété la limite d'instructions.
Convertis en agal, cette fonction prend moins de 50 lignes (non optimisée) et cet argument ne te dérangeait pas quand tu présentais ta transformation de fourrier made in GPU dans ta conférence (combien de lignes d'agal pour cette fonction déjà ?).
Par ailleurs, l'un de mes objectifs est de convertir l'intégralité des fonctions de la classe Math en AGAL afin de pouvoir les utiliser naturellement comme je le fais tout les jours dans mes codes AS3, de fait cette fonction est pertinente.


Citation

Donc je ne vois pas trop l'intérêt d'avoir atan2 si je ne peux pas vraiment l'utiliser dans un shader qui fait autre chose qu'atan2
Et si je suis dans le cas d'un moteur de particule (environs 100 000) et que je souhaite que chaque particule pivote en direction de la souris, comment je fais sans cette fonction ?
Ah oui ! ce cas de figure n'arrive jamais dans le cadre d'un jeu AAA donc on s'en fout, mais si on ne s'en fout pas ?


Citation

Pour le porter en as3 shader, il faut remplacer * par multiply(), + par add() et float par SFloat. Temps de l'opération : 15 secondes ?
Ok 15 sc par ligne... Combien de ligne par page de code ? combien de pages de code par jour ? combien par mois ? par an ?

Et en terme de lisibilité / partage de l'information tu ne trouves pas qu'il y a un léger gain entre du code normal et le code de Minko :

absolute(subtract(luminance(sampleTexture(texture, divide(subtract(fragmentCoord, float2(0, OFFSETS[r])), outputSize))).x, luminance(currentPixel).x))
 
?

Moi je trouves pas ça super lisible, plus que l'AGAL certes, de là à dire que remplacer tes noms de fonctions par des opérateurs standard est "un plus minime" et qu'avec Minko on peut coder (des shaders) "en vrai AS3" ...


Citation

Au passage, la surcharge d'opérateurs est une des features les plus demandées pour la prochaine version d'AS, donc je pense que cet intérêt là, déjà minime, disparaîtra très vite.
On verra, je ne compte plus les features que j'attend (et que d'autres attendent) depuis flashMX2004.
'Un "tiens" vaut mieux que deux "tu l'auras" '.


Citation

ça t'apprendra peut-être comment générer du bytecode AGAL, mais ça ne t'apprendra absolument rien sur le développment GPU
La dessus, je suis on ne peut plus d'accord, ça fait un mois (bientot et demi) que je suis dessus, et j'ai l'impression d'apprendre....rien :D
C'est long, c'est chiant et j'apprend rien (pour le résumer en une ligne :D )

Mais je compte sur l'après, le moment ou coder un shader sera une formalité et ou je pourrais m'attaquer à plus compliqué (pour l'instant, comme tu l'as très bien dit, l'AGAL est avant tout une perte de temps (dans le sens ou le temps qu'on passe à gerer les variables, on ne le passe pas à coder le shader en lui même) , j'essaye donc de résoudre ce problème une fois pour toutes avant de passer à autre chose, logique)

#37 alama.be

    Ceinture Noire

  • Members
  • PipPipPipPipPipPipPip
  • 224 messages

Posté 04 September 2012 - 09:30 AM

Je pense que vous avez raison tous les deux, mais votre but n'est visiblement pas le même.. Pour ma part, le mieux est de me lancer dans des tests pour pouvoir donner mon avis.. Pour NVIDIA et ses Maths, c'est apparemment une libraire CG, une API qui doit être compilée (ou pseudo compilée) vers une autre langage (Direct X ou OpenGL) ..

Citation

cgc is the standalone Cg compiler which translates Cg or GLSL programs into OpenGL or DirectX shader assembly code, or OpenGL or DirectX shading language code.

Donc, après ça, il faut encore un compilateur (je suppose JIT) qui va écrire le code machine.. Là, je ne sais pas si le GPU intègre un JIT ou si c'est le driver OGL ou DirectX qui le fait.. ou même plutôt le driver de la carte graphique..

Bref, tout ça pour dire que si j'ai bien compris, Tlecoz veut faire un outil qui peut compiler une routine comme une des CG en Agal.. c'bien ça? mm..

Le top pour ça, c'est CUDA visiblement, Mais ça, Flash player n'y est pas encore..

Vous savez quoi, je pense qu'il faut partir de la base pour bien comprendre les subtilités.. il faut trouver un DataSheet complet d'un GPU nvidia ou ATI et étudier tout.. l'architecture et le set d'instructions.. ça permettra de mieux comprendre ceci ou cela.. :)


D'après Adobe, l'AGAL est un code directement assimilable par le GPU.. Donc, j'ai du mal à faire la distinction entre ce que dit Jean-Marc et ce que dit Tlecoz..

Vous n'avez pas un petit exemple concret? un code qui montrerait pourquoi AGAL, c'pas top ou le contraire?

Genre, je veux simplement récupérer la racine carrée de 144 ? Evidement, ma demande ne concerne pas un vrai problème 3D.. peut être que mon exemple ne s'applique pas.. J'essaye de comprendre.. :)

EDIT:
Repartons de ZERO..

Je fouille le net à la recherche d'info.. ça fait 18 ans que je n'ai plus suivi l'aspect électronique des choses.. du coup, je ferai bien de me mettre à jour.. lol

J'ai trouvé deux articles intéressants (démystification)

Dans celui ci, c'est la fin qui est intéressante.. je sens que je vais écrire à nouveau sur la liste Tamarin.. à la pêche aux infos.. :)
http://www.nvidia.fr...mputing-fr.html

Ha ouai! quand même... :S paralléliser ses blocs d'instruction n'est pas une mince affaire.. Courage Tlecoz.. :)
http://www.yosefk.co...vidia-gpus.html

Quand on sait que dans 90% des cas, un code de Math doit obligatoirement être séquentiel.. J'ai survolé l'article, mais il mérite qu'on prenne 1 à 2h pour bien le comprendre.. :)

On sort de la 3D là, mais bon, c’était but de ce post.. "comment faire des Maths normales et utiliser le GPU pour accélérer une appli 2D normale en Flash Player standart" ..
Ne baisse jamais les bras, car c'est à ce moment là que le miracle risque de se produire..

Site web: http://www.pureas3.org
Twitter: https://twitter.com/PureAS3

Enjoy with Flash Player :-)

#38 alama.be

    Ceinture Noire

  • Members
  • PipPipPipPipPipPipPip
  • 224 messages

Posté 04 September 2012 - 11:22 AM

Bon, Tlecoz, tu fais vraiment un compilo AS32AGAL?? ou j'ai rien compris?

Revenons à nos moutons..

On va commencer simple.. Cherchons simplement à obtenir le resultat de la racine carrée de 144 (11) dans un pixels de rendu. (32 bits)

Il faut, créer sa scene 3d (stage3d, cam, et un petit plane de rien du tout.. ou même un triangle), ensuite, construire un shader qui est est en réalité cette racine carrée.. (et faut lui filer la data à traiter)..

pour le faire, plusieurs solutions.. de la + difficile (AGAL direct)
http://help.adobe.co...4ec56-8000.html

A la plus simple: AS3 2 AGAL
http://hub.aerys.in/...ompilation-logs

Sauf que là, je dois encore apprendre a utilsier Minko...

ou alors, en partant de GLSL 2 AGAL
http://www.cmodule.org/glsl2agal/

Ou pire encore, en partant de la Lib Nvidia GC > GLSL > AGAL ..

L'appliquer à mon plane et directement recup le result avec

stage.stage3Ds[i].context3D.drawToBitmapData(bitmapDataObject)
 

suivit d'un getPixels ..

Je suis dans le bon! ?? :)

Sur le principe, çà paraît simple, mais .....

C'est bizarre, mais je ne le sens pas ce truc.. Comment je vais être sur que mon pixel soit 100% juste à l'écran? ça dépendre de la light.. Si on n met pas de light, ça sera tout noir, non? Ca fait chier qu'on ne puisse pas récup le resultat d'une texture sans l'afficher .. Pfff mais bon, pour FP 19.5 (en 2024) p'tet ça ira .. lol

dans cette instru:

sqt 0x09 square root | destination = sqrt(source1), component-wise

source1 = 144..
C'est quoi "component-wise" ?

Ici, je ne vois pas de gestion de lum, donc, par defaut, le rendu est 1:1 .. c'bon ça!
http://www.adobe.com...umberedheader_0

Dites moi si je délire ou j'me plante.. :)
Ne baisse jamais les bras, car c'est à ce moment là que le miracle risque de se produire..

Site web: http://www.pureas3.org
Twitter: https://twitter.com/PureAS3

Enjoy with Flash Player :-)

#39 tlecoz

  • Honoris
  • PipPipPipPipPipPipPipPip
  • 3486 messages

Posté 04 September 2012 - 12:58 PM

Hello !

Citation

Vous n'avez pas un petit exemple concret? un code qui montrerait pourquoi AGAL, c'pas top ou le contraire?

Je n'ai pas d'exemple tout fait sous la main, mais il me parait assez facile d'expliquer pourquoi ce n'est pas le top :)
Le fait d'avoir des nom de variable imposé (va0,vc0,fc0,ft0,vt0, etc...) fait le code de 2 shaders qui n'ont rien à voir se ressemblera : tu ne peux pas vraiment prendre de point de repère dans ton code. Au moment de l'écriture du code AGAL, ce n'est pas trop un problème car on sait ou on va, on sait ce qu'on a fait, ce qu'on veut faire. Mais dés que ça commence à bugger ou à se comporter d'une autre manière que prévu, on est vite perdu (d'autant plus que les message d'erreurs lié à l'AGAL sont vraiment obscure et n'aident pas trop)


Citation

Pour NVIDIA et ses Maths, c'est apparemment une libraire CG, une API qui doit être compilée (ou pseudo compilée) vers une autre langage (Direct X ou OpenGL) ..
Je te crois sur parole, et m'excuse de l'avoir présenté autrement...
Je suis tombé dessus en cherchant "gpu atan2" c'est pourquoi j'ai pensé que c'était un bout de code permettant de simuler cette fonction sur le GPU, mais au final ça fait ce que je veux (ça décrit bien comment traiter le calcul en utilisant que les calculs/type de variable dispo coté GPU). Désolé si suis un peu flou quand je parle, c'est encore nouveau pour moi.

Citation

paralléliser ses blocs d'instruction n'est pas une mince affaire..
Je manque cruellement de vocabulaire... Paralléliser tu dis ? :D
Tu sais il est probable que la manière dont je m'y sois pris ne soit pas la manière standard de faire les choses, pour la simple raison que , comme pour tout mes autres projets, je ne fais aucun plan. Chaque jour j'ai une todo-list assez imposante que je prépare la veille, mais à aucun moment je n'ai listé tout les cas de figure... Je les ai ajouté l'un après l'autre, à force de trouver des bugs en faisant des tests.

Citation

Bref, tout ça pour dire que si j'ai bien compris, Tlecoz veut faire un outil qui peut compiler une routine comme une des CG en Agal.. c'bien ça?
C'est ça, à ceci près que je n'aime pas trop parler de "compilateur" car pour moi c'est plus "un parseur de classe AS3 qui génère de l'AGAL" , La différence ? Je ne sais pas trop, mais faire un compilateur ça a l'air impossible, alors que faire un parser.... n'importe qui peut le faire :)

Citation

C'est quoi "component-wise" ?
Cela veut dire que tu peux faire plusieurs calculs en une fois.
Par exemple, tu peux faire

Citation

sqr vt0.x, va0.x;

mais tu pourrais écrire aussi


sqr vt0.xyz, va0.xyz
 

En agal, ce qu'on appelle 'component' ce sont les variable 'x','y','z','w' des attributs/constantes d'un shaders

#40 alama.be

    Ceinture Noire

  • Members
  • PipPipPipPipPipPipPip
  • 224 messages

Posté 04 September 2012 - 13:41 PM

Citation

Je n'ai pas d'exemple tout fait sous la main, mais il me parait assez facile d'expliquer pourquoi ce n'est pas le top :)
Le fait d'avoir des nom de variable imposé (va0,vc0,fc0,ft0,vt0, etc...)

Tu viens de répondre à une question que je posais.. je viens de charger l'exemple by Adobe, j'ai déjà arrêté l'anim, là, je ch à transformer l'AGAL pour voir comment ça marche.. je ne captais justement rien à Va0, Vc0, etc.. lol

Citation

Je manque cruellement de vocabulaire... Paralléliser tu dis ? :D
Ben oui (SIMD) apparement, les GPU sont principalement des tonnes de coeurs qui bossent en parallèles, la vitesse est obtenue en multipliant les thread séparés (j'imagine que c'est sympa pour tous les triangles élémentaires d'une scene 3D) mais pour faire des math Traditionnelles, (pas prevu a la base pour ca, il ont ajouté CUDA pour ça.. mais No flash Player.. sauf.. faut que je vois avec les gens de Tamarin) l'imbrication des Instructions semble galère.. ou alors, un fait tout en seul thread, mais là, j'imagine qu'on va perdre la puissance du GPU.. autant rester en CPU..

Merci pour le reste de l'explication.. (je ne suis aps sorti de l'auberge..)

Mais par contre, je te suis sur ton idée de faire AS32AGAL .. peut importe comment tu va y arriver.. :)
Ne baisse jamais les bras, car c'est à ce moment là que le miracle risque de se produire..

Site web: http://www.pureas3.org
Twitter: https://twitter.com/PureAS3

Enjoy with Flash Player :-)

#41 tlecoz

  • Honoris
  • PipPipPipPipPipPipPipPip
  • 3486 messages

Posté 04 September 2012 - 13:43 PM

Citation

AS32AGAL
Le nom que j'ai choisi est AS2AGAL , tu y étais presque :)

#42 Goabonga

  • Moderateur
  • PipPipPipPipPipPipPipPip
  • 2724 messages

Posté 04 September 2012 - 13:47 PM

va0 a va7 -> Vertex attribute registers
vc0 à vc127 et fc0 à fc27 -> Constant registers
vt0 à vt7 et ft0 à ft7 -> Temporary registers
op et oc -> Output registers
v0 à v7 -> Varying registers
fs0 à fs7 -> Texture samplers


EDIT:
-> C'est vraiment inbitable ... courage les gars...
-> JM t'as pondu un super joujou :)

#43 alama.be

    Ceinture Noire

  • Members
  • PipPipPipPipPipPipPip
  • 224 messages

Posté 04 September 2012 - 17:57 PM

Ben en fait, c'est ça.. j'aimerais essayer la base native, ne fus ce que pour comprendre un peu.. après, il est clair que si ça va pas, je vais tenter avec un outil comme Minko ou autre.. Mais bon, ici, c'est vraiment pour un cas particulier, sinon, pour vraiment faire de la 3D, il est clair qu'il faut utiliser un outil .. perso, j'ai pas l'intention de créer un moteur.. lol

Sinon, je peux toujours attendre AS2AGAL :mrgreen:

Non, mais quand je pense qu'à lécole (y a 18 ans) on a apprit à programmer des µC en hexa.. puis, par la suite, en assembleur, je devrait bien y arriver.. enfin, j'espère..

Citation

C'est ça, à ceci près que je n'aime pas trop parler de "compilateur" car pour moi c'est plus "un parseur de classe AS3 qui génère de l'AGAL" , La différence ? Je ne sais pas trop, mais faire un compilateur ça a l'air impossible, alors que faire un parser.... n'importe qui peut le faire :)

Oui, aller, on va dire un "interpréteur" ou "convertisseur" , mais bon, un compilateur, c'est quand même en gros un parser, suivit d'une interprétation/conversion.. basé sur une table de set d'instructions.. dans sa version la + simple.. après, y a la partie intelligente qui structure au mieux ou les + récents, comme les JIT.. :)
Ne baisse jamais les bras, car c'est à ce moment là que le miracle risque de se produire..

Site web: http://www.pureas3.org
Twitter: https://twitter.com/PureAS3

Enjoy with Flash Player :-)

#44 alama.be

    Ceinture Noire

  • Members
  • PipPipPipPipPipPipPip
  • 224 messages

Posté 05 September 2012 - 08:24 AM

Bonjour les amis, depuis hier, je chipote toujours avec hello triangle.. j'ai de gros doutes..[ j'en ai bcp moins déjà.]

quand je construis mes vertices, je leur attribue une valeur RGB ! il n'y pas d'alpha?? non, mais c'est parce que j'ai besoin de pixels 32,et non des 24.. :S [je pense résolu]

Ensuite, on est obligé de créer un vertexShader? enfin, je veux dire, il est impossible de rendre un vertex seul? (genre, 1 vertex = 1 pixel) [resolu, oui obligé!]

et encore, les coordonnées, on part du point 0,0,0 au centre de l'image (cam) je ne vois pas encore comment placer plusieurs vertex afin qu'il soint réellement espacé de 1px au rendu.. il y a moyen, mais je dois encore avancer et comprendre. [résolu]

N'oublions pas que je ne cherche pas à faire de la 3D, mais bien à détourner stage3D pour faire d'aurtes choses :)

Là, je me demande comment je peux.. (imaginons, j'ai 10 valeurs Float (32), je veux simplement les faire apparaître cote à cote (la valeur exprimée à l'écran en RGBA) et que ces valeurs soient de 1px carré (ou un fragment) .. soit je pars sur 10 vertex, soit.. je sais pas.. :) [resolu, je pars sur un autre principe.. si ça va pas, je reviendrai vers l'idée de 1px = 1vertex ..]

c'est le fragmentShader qui fera le draw de mes 10 pixels carrés? [oui!]

Sinon, y a encore la notion d'index aussi.. mais j'ai pas encore capté, je vais encore lire.. :) [resolu]

Edit
pour le moment, j'ai créé un carré blanc (mon audio buffer de 4096 float).. :)

Là, un carré 2D de 64X64px

// un buffer audio = 4096 float, donc 64X64 px 32
context3D.configureBackBuffer(64, 64, 0, true);
var vertices:Vector.<Number> = Vector.<Number>
([
-1, -1, 1, 1, 1,
-1, 1, 1, 1, 1,
1, 1, 1, 1, 1,
1, -1, 1, 1, 1
]) ;
vertexbuffer = context3D.createVertexBuffer(4, 5);
vertexbuffer.uploadFromVector(vertices, 0, 4);
var indices:Vector.<uint> = Vector.<uint>([0, 1, 2, 2, 3, 0]);
indexbuffer = context3D.createIndexBuffer(6);
indexbuffer.uploadFromVector(indices, 0, 6);
 

Bon, j'avance, lentement, mais surement.. :) (dans l’immédiat, j'aimerais attribuer une couleur 32 et pas 24)

Bon en route vers les Vsh et les Fsh.. :eusa_doh: Si ca va pas, je peux peut être faire un bitMap de mon audio buffer et faire une bitMaping plutôt qu'un phong.. et modif chaque px de ma texture en agal.. on verra..
Ne baisse jamais les bras, car c'est à ce moment là que le miracle risque de se produire..

Site web: http://www.pureas3.org
Twitter: https://twitter.com/PureAS3

Enjoy with Flash Player :-)

#45 tlecoz

  • Honoris
  • PipPipPipPipPipPipPipPip
  • 3486 messages

Posté 05 September 2012 - 14:54 PM

Hello !

Il n'est pas vraiment possible de dessiner pixel par pixel dans le fragmentShader dans le sens ou la zone peinte dans le fragmentShader sera toujours triangulaire (le triangle étant défini par le vertexShader).

Tu peux par contre dessiner des triangles de 2px de coté, et les positionner l'un à coté de l'autre à 1 px d'interval, tu vois ce que je veux dire ?

Pour faire ça, il faut feinter un peu :)
Au lieu de définir des points définissant des triangles dans ton VertexData, tu vas y stocker (3 fois de suite), les coordonnées du centre du triangle, attribuer un id pour chacun des points et "reconstruire" le triangle dans le vertexShader.

Avec un peu de code, ce sera ptet plus compréhensible

//admettons que la texture soit défini par les dimension textureW et texureH
//un triangle, dont l'angle droit est calé en haut à gauche, de 2px de coté aura donc comme repere UV

var topLeft:Vector.<Number> = Vector.<Number>([0,0,0,0])
var topRight:Vector.<Number> = Vector.<Number>([2 / textureW,0,0,0])
var bottomLeft:Vector.<Number> = Vector.<Number>([0,2/textureH,0,0])

//passe chacun de ces Vector.<Number> comme VertexConstant du shader aux index 10,11,12 (par exemple)
//
//Au niveau du VertexData, on va définir la position d'un point (qui correspondra au coin haut gauche de notre triangle) ; il faut définir le centre de ce point 3 fois de suite car les shaders fonctionnent avec des triangles donc des série de 3 points.
En plus des coordonnées XY du point, on va passer pour chaque point l'index de la constante représentant les reperes UV de chaque point

var posx:int = 5 / textureW;
var posy:int = 15 / textureH:
//(5 et 15 sont chiffres choisis arbitrairement)

var constante_UV_0:int = 10; //10 -> l'id de la constante topLeft
var constante_UV_1:int = 11; //11 -> l'id de la constante topRight
var constante_UV_2:int = 12; //12 -> l'id de la constante bottomLeft
var vertices:Vector.<Number> = Vector.<Number>([posx,posy,constante_UV_0,posx,posy,constante_UV_1,posx,posy,constante_UV_2]);


//au niveau de la préparation du context, ça donne un truc comme ça

context.setVertexBufferAt(0, vertexBuffer, 0, Context3DVertexBufferFormat.FLOAT_2); //XY
context.setVertexBufferAt(1, vertexBuffer, 2, Context3DVertexBufferFormat.FLOAT_1); //INDEX_UV


ensuite, dans ton vertexShader, tu vas pouvoir faire ça

//pour récupérer les UV du triangle relatif à chaque point
mov vt0, vc[va1.x];
//on applique ensuite les coordonnée de notre point
add vt0.xy, vt0.xy, va0.xy;
//et on passe le résultat au fragmentShader
mov v0, vt0

dans le FragmentShader, la variable v0 correspond maintenant au repère de texture d'un triangle de 2px positionné à x=5 et y=15 , il suffit de le peindre de la couleur que tu veux :)


Bon courage !


EDIT : La méthode défini plus haut n'est pas la plus simple. En fait , maintenant que j'ai bien expliqué le principe, je me rend compte que ce n'est pas du tout nécessaire de faire comme ça dans ton cas, le plus simple serait de remplir ton vertexData avec les UV qui vont bien déjà calculé.
Désolé si je t'ai embrouillé avec le partage de constantes, mais la plupart des anims que j'ai fait sont basé sur ce principe et j'ai un peu tendance à vouloir l'utiliser partout :)



1 utilisateur(s) li(sen)t ce sujet

0 membre(s), 1 invité(s), 0 utilisateur(s) anonyme(s)