20 réponses à ce sujet

[draad]

Bonjour a tous,

J'aimerais me pencher sur la création de shaders et, surtout la compréhension de ce qu'est exactement un shader. Car même si je sais plus ou moins ce que cela fait, je pense que ce n'est qu'un aperçu de toutes les capacités d'un shader.

J'aimerais commencer par la creation de Shader 2D, auriez vous une piste pour moi afin de commencer facilement ? Un tuto comme ceux qu'on peut trouver sur Mediabox serait parfait !

Merci !

[tlecoz]

Hello !

Un shader est un programme qui permet de dire à la carte graphique comment dessiner chaque triangle.
Chaque shader se décompose en 2 parties exécuté l'une aprés l'autre :
1) le vertexShader qui permet de modifier la position des points en fonction d'une constante (une matrix par exemple)
2) le fragmentShader qui permet de modifier les pixels d'un triangle (son contenu en qq sorte)

Au début , je n'arrivais pas bien à déterminer à quel niveau je me trouvais vraiment... A l'échelle d'un triangle ? A l'échelle d'un vertex de mon triangle ?, ou à l'échelle d'un pixel ?

En fait,on agit sur les trois en même temps
On agit à l'échelle d'un triangle, car ce que fais un Shader , c'est dire à la carte graphique comment dessiner un / des triangles.
Au niveau du vertexShader, on agit à l'échelle d'un vertex ; c'est comme si le vertexShader était lu 3 fois (une fois par points) , mais le code du vertexShader concerne un seul point à la fois.
Au niveau du fragmentShader, on travaille à l'échelle du pixel ; que ce soit pour afficher une image ou un dégradé, le fragmentShader s'occupe de remplir le triangle et de travailler avec une sorte de colorTransform pour chaque pixel. On travaille à l'échelle du pixel, mais les pixels sont définis par la position de chaque vertex du triangle.

le fragmentShader s'execute toujours après le vertexShader, ce n'est pas possible de faire autrement.

Cela sous entend qu'il est très facile de modifier la couleur des points d'un objet en fonction de leur distance (par exemple), mais que c'est une autre histoire si on veut modifier la position d'un vertex en fonction de sa couleur (par exemple).

Bon courage !

[draad]

Merci pour ces explications !

Est ce qu'il existe une différence entre les Shader pour des applications 2D et les applications 3D ? Ou ne considérons nous que le rendu final de l'image (soit de la 2D sur l'écran) ?

Merci

[tlecoz]

Il n'y a pas de différence entre un shader2D et un shader3D

Citation

Ou ne considérons nous que le rendu final de l'image (soit de la 2D sur l'écran) ?

En fait, c'est l'inverse, on considére plutôt que tout est en 3D (du moins, c'est comme ca que je vois les choses)

[tlecoz]

EDIT : En fait , il n'y a pas vraiment d'histoire de 2D/3D , tout dépend de ce que fais ton shader. Si je disais que c'est "plutot tout en 3D" c'est par ce que chaque vertex est composé d'une propriété X/Y/Z/W. Mais si tu applique ton shader sur un plane vu de face (par exemple) et que tu applique une transformation sur les coordonnée X/Y (par exemple) sans toucher au Z, cela fonctionne sans problème

[lilive]

Bonsoir,

Quand on parle de shader et de flash aujourd'hui, il me semble aussi qu'on pense en premier à ce dont parle tlecoz, à savoir les shaders utilisables et indispensables pour programmer son rendu graphique via la carte graphique (Stage3D, flash.display3D)
On écrit ces shaders en langage AGAL ( http://www.adobe.com...at-is-agal.html )
Si c'est cela qui t'intéresse, la série d'articles dont fait partie ce dernier lien est très instructive.

Mais je précise que le terme "shader" me semble s'appliquer à d'autres domaines, et ne pas concerner uniquement les shaders utilisés dans le pipeline de rendu par la carte graphique. Cf wikipedia où il est aussi question de rendu logiciel: http://fr.wikipedia.org/wiki/Shader
Concernant flash, on pouvait déjà utiliser des shaders pour coder des manipulations d'images 2D avant l'arrivée de Stage3D.
Je parle de http://help.adobe.co...lay/Shader.html
On peut définir ce genre de shader grâce à pixel bender ( http://www.adobe.com...ixelbender.html ), avec un langage de programmation spécifique (Pixel Bender kernel language), puis utiliser ces shader en actionscript.
Maintenant il existe aussi Pixel Bender 3D, et je ne sais même pas à quoi ça sert

[tlecoz]

Citation

Maintenant il existe aussi Pixel Bender 3D, et je ne sais même pas à quoi ça sert

PixelBender3D est une "sur-couche" de l'AGAL. C'est de l'AGAL un peu plus haut niveau, mais on ne peut pas faire en PB3D ce qu'on ne peut pas faire en AGAL

[Jean-Marc Le Roux]

AGAL n'est pas un langage pour programmer des shaders.
AGAL est un langage permettant de représenter les shaders pour Stage3D en s'abstrayant de l'API (OpenGL ou DirectX) utilisée par la Flash platform.

Quelle est la différence ? La différence est la même qu'entre le bytecode AS3 (ABC) et le code AS3.
Le premier est un langage bas niveau conçu pour la VM Flash.
Le second est un langage fait pour que les humains programment la VM Flash.

Dans des APIs comme OpenGL ou DirectX justement, il y'a par exemple l'ARB développé par nVidia qui est semblable à l'AGAL dans le sens où c'est de l'assembleur. Bien évidemment, personne ne se sert jamais d'ARB mais on utilise plutôt des langages hauts niveaux : GLSL, HLSL, CG...

D'une part AGAL est très limité, d'autre part même les langages plus haut niveau cités précédemment souffrent de gros problèmes de conception. Il est par exemple extrêmement compliqué de partager efficacement du code entre plusieurs shaders.

Pour faire mieux que l'AGAL et parer aux défauts sus-mentionnés, nous avons travaillé sur une techno qui permet de programmer le GPU avec de l'ActionScript 3. Nous avons donc développé un compilateur JIT qui compile les shaders dynamiquement au runtime. C'est ce qu'utilise Minko pour toute la partie rendu.

Concrètement, ça veut dire que n'importe quel développeur peut aujourd'hui faire de la prog. GPU en AS3.
De l'AS3 accéléré matériellement :

Des exemples:

http://blogs.aerys.i...ss-cel-shading/
http://blogs.aerys.i...shader-samples/
http://blogs.aerys.i...rame-rendering/
http://blogs.aerys.i...ragment-shader/
http://blogs.aerys.i...essing-effects/
http://blogs.aerys.i...inko-shaderlab/
http://blogs.aerys.i...gpu-with-flash/
http://blogs.aerys.i...rallax-mapping/

On a aussi fait le ShaderLab, un environnement complet de création de shaders :



Si tu as des questions :

http://forums.mediab...lash-11-3d-api/

Modifié par Jean-Marc Le Roux, 29 June 2012 - 22:30 PM.

[lilive]

Jean-Marc Le Roux, le 29 June 2012 - 21:39 PM, dit :

D'une part AGAL est très limité

Faut croire que moi aussi... j'ai rien compris à ton explication!

[Jean-Marc Le Roux]

lilive, le 29 June 2012 - 22:19 PM, dit :

Faut croire que moi aussi... j'ai rien compris à ton explication!

Là, comme ça, je vois pas bien comment je pourrais t'aider si tu n'es pas plus précis

Citation

Concrètement, ça veut dire que n'importe quel développeur peut aujourd'hui faire de la prog. GPU en AS3.

Je peux difficilement faire plus simple

Modifié par Jean-Marc Le Roux, 29 June 2012 - 22:32 PM.

[lilive]

C'est cette partie que je ne comprends pas:

Jean-Marc Le Roux, le 29 June 2012 - 21:39 PM, dit :

AGAL n'est pas un langage pour programmer des shaders.
AGAL est un langage permettant de représenter les shaders pour Stage3D en s'abstrayant de l'API (OpenGL ou DirectX) utilisée par la Flash platform.

Quelle est la différence ? La différence est la même qu'entre le bytecode AS3 (ABC) et le code AS3.
Le premier est un langage bas niveau conçu pour la VM Flash.
Le second est un langage fait pour que les humains programment la VM Flash.

Je pensais qu'AGAL permettait d'écrire un programme en utilisant le jeu d'instruction (ou une partie) du processeur de la carte graphique. Comme de la programmation en assembleur pour le CPU. Et comme j'ai compris qu'un shader (dans le contexte Flash/Stage3D) est un bout de programme, j'en ai déduit qu'AGAL est un langage qui permet de programmer des shaders. Merci de m'éclairer si je me trompe, ça m'évitera de raconter des bétises en répondant à des questions comme celles de draad...

[Jean-Marc Le Roux]

Citation

Je pensais qu'AGAL permettait d'écrire un programme en utilisant le jeu d'instruction (ou une partie) du processeur de la carte graphique. Comme de la programmation en assembleur pour le CPU. Et comme j'ai compris qu'un shader (dans le contexte Flash/Stage3D) est un bout de programme, j'en ai déduit qu'AGAL est un langage qui permet de programmer des shaders.

C'est une question de point de vue. On peut dire que l'assembleur x86 permet de développer des programmes qui s'exécutent sur un processeur x86. Pour autant, personne ne le fait (plus). Même les développeurs célèbres pour leurs optimisations en assembleur (Carmack ?) pour aller plus vite que le code haut niveau font désormais confiance aux compilateurs qui font un bien meilleur travail.

Donc oui, tu "peux" écrire des shaders en AGAL tout comme tu peux coder en assembleur x86. De la même manière, le bytecode ABC (bytecode AS3 produit à partir d'ActionScript 3) est un langage de programmation. Est-ce que tu écris tes applications Flash en ABC ou en AS3? C'est une question de productivité et de qualité du code. Si on te demande aujourd'hui "comment créer des applications Flash", tu conseilleras l'AS3 et non pas le bytecode ABC. C'est la même logique pour la programmation GPU : pourquoi conseiller AGAL alors que le langage n'a pas été conçu pour ça et que des alternatives bien plus productives existent ?

Certains diront "oui mais c'est mieux de savoir ce qu'il y'a en dessous". Certes. Mais il y'a une différence entre "savoir" et "utiliser". Je sais que la VM Flash execute du bytecode ABC et je sais à quoi il ressemble. Mais je ne l'utilise pas pour coder des applications.

Il ne faut donc pas voir l'AGAL comme un langage de programmation à utiliser si tu es développeur, mais plutôt comme un langage qui permet de représenter des shaders tels qu'ils peuvent être compris/convertis par la VM Flash. Ainsi, si la question est "comment créer des shaders", la réponse n'est pas "AGAL". La réponse c'est plutôt d'utiliser HxSL (Haxe), FLSL (Flare3D) ou justement ActionScript 3.0 (Minko).

L'AS3 devient grâce à Minko un langage de shaders très puissant. Le luxe des shaders ActionScript 3 c'est qu'en plus d'être plus simples à écrire/maintenir/debuguer (puisque c'est juste du code AS3), ils ont aussi beaucoup de fonctionnalités que n'ont pas les autres langages de shaders, même haut niveau, dont certaines n'existent même pas dans des outils comme l'UDK, Unity ou le Source Engine :

- compilation au runtime
- optimisation du code à la volée (mémoisation, compression des constantes, suppression des opérations inutiles...)
- distribution automatique du code entre le CPU et le GPU
- utilisation des if/else, for, while...
- utilisation des classes/méthodes
- programmation paramétrique (possibilité de recompiler le même shader sous différentes version en fonction des propriétés de la scène; ex: avec ou sans animations, avec ou sans lumières, etc...)
- gestion des paramètres de rendu (blending, render target, operations de stencil...)
- gestion simplifié du rendu multi-passes

Tu écris du code AS3 et il s' "exécute" sur le GPU. C'est magique.

Modifié par Jean-Marc Le Roux, 30 June 2012 - 01:45 AM.

[lilive]

Maintenant je comprends ta réponse.
Ceci dit:

Jean-Marc Le Roux, le 30 June 2012 - 01:32 AM, dit :

Il ne faut donc pas voir l'AGAL comme un langage de programmation à utiliser si tu es développeur, mais plutôt comme un langage qui permet de représenter des shaders tels qu'ils peuvent être compris/convertis par la VM Flash. Ainsi, si la question est "comment créer des shaders", la réponse n'est pas "AGAL". La réponse c'est plutôt d'utiliser HxSL (Haxe), FLSL (Flare3D) ou justement ActionScript 3.0 (Minko).

Tout dépend de quel développeur tu veux être. La possibilité d'utiliser le GPU avec flash est toute récente, c'est un nouveau territoire à découvrir pour les développeurs. Certains voudront apprendre à se servir d'outils tout faits, comme Minko que tu mets régulièrement en avant même dans les questions concernant Stage3D/AGAL et pas Minko, d'autres auront envie d'aller creuser et comprendre l'AGAL. Chacun ses choix. Moi par exemple je me suis penché sur un moteur d'affichage 2D basique via le GPU, avec l'envie d'optimiser le plus possible. Si ça se trouve passer par Minko aurait au final été mieux optimisé, j'en sais rien, c'est pas la question, ce qui compte c'est que j'ai voulu apprendre AGAL, et que tout partage de connaissance explicite, documenté et désintéressé sur le sujet, dans l'esprit de ce forum, m'intéresse.

[draad]

Ha c'est intérréssant !

Donc si j'ai bien compris, il y a plusieures solutions pour faire des shader pour Flash ?

Directement avec les outils intégrés au language AS3 (Shader), ce qui sous entends d'apprendre l'AGAL, ou alors avec des outils tels que Minko, qui a ce que je peux voir ressemble pas mal a des interfaces nodales telles qu'on peut les trouver dans differents soft de modelisation 3D.

lilive, serait-il possible de voir un peu ce que tu as reussi a faire avec AGAL et ton moteur 2D pour avoir un outil de comparaison avec les exemples de Jean-Marc Le Roux?
La discution devient assez pointue, et j'ai peur de ne pouvoir saisir l'ensemble des differences avant d'avoir moi même mis les mains dans le cambouis

Cependant, a partir de quel moment faut-il préférer l'utilisation d'un shader a un traitement direct de l'image par passe ? Imaginons un exemple simple, je souhaite traiter des images pour les passer en noir et blanc en temps réel. Y'a-t-il des moment où il faut préférer le traitement bitmap au traitement par shader ?

Aussi, faut-il préférer certaines solutions a d'autre pour des jeux créés pour les plateformes mobiles (Android/Ios).

[tlecoz]

Hello !

Citation

lilive, serait-il possible de voir un peu ce que tu as reussi a faire avec AGAL et ton moteur 2D

http://forums.mediab...ost__p__1080368

Citation

pour avoir un outil de comparaison avec les exemples de Jean-Marc Le Roux?

pas sur que ce soit comparable, le moteur de lilive a été fait en quelques jours, celui de jean-marc en plus d'un an (et il faisait déjà des moteur3D pour flash il y a 4 ans... ^^ )

Citation

Donc si j'ai bien compris, il y a plusieures solutions pour faire des shader pour Flash ?

Directement avec les outils intégrés au language AS3 (Shader), ce qui sous entends d'apprendre l'AGAL, ou alors avec des outils tels que Minko, qui a ce que je peux voir ressemble pas mal a des interfaces nodales telles qu'on peut les trouver dans differents soft de modelisation 3D.

Oui et non
Dans tout les cas, au final, c'est de l'AGAL.
Mais puisqu'on peut écrire de l'AGAL directement depuis le code AS3, rien n'empêche de créer une librairie AS3 qui va écrire l'AGAL à notre place et le compiler (via la classe AGALMiniAssembler fourni par Adobe) sous forme d'un Program3D utilisable par le GPU.

A vrai dire, c'est presque nécessaire de passer par une classe AS3 pour générer l'AGAL car cela permet d'obtenir un code lisible (ce qui n'est pas le cas quand tu code direct en AGAL) donc maintenable. Le fait d'ajouter des commentaires dans le code AGAL est nécessaire, mais ça ne suffit pas car le code reste difficile à lire et c'est facile de s'y perdre.

Le ShaderLab de Jean-Marc, d'après ce que j'ai pu voir, est plus une interface graphique permettant de coder de l'AGAL visuellement qu'autre chose, dans le sens ou les différentes nodes correspondent aux différentes fonction dispo en AGAL ; plus d'autres nodes construit à partir des premières pour créer des effets préfabriqué (des fonctions quoi).

D'après ce que j'ai compris, la classe qui gère les Shaders dans Minko se différencie d'une simple librairie contenant des "texte-à-trous" (comme lorsqu'on écrit du html avec du php) car elle permet d'un part d'optimiser autant que possible la gestion des variables au sein du code AGAL mais surtout parce que, complété par Minko, elle peut gérer des cas de figures vraiment complexe que je n'ai pas l'ombre d'une idée de comment il fait

Par contre il n'est pas possible d'utiliser la gestion des Shader de Minko sans utiliser Minko : ça va ensemble et c'est d'ailleurs ce qui permet à l'un et l'autre d'être si puissant

Citation

Imaginons un exemple simple, je souhaite traiter des images pour les passer en noir et blanc en temps réel. Y'a-t-il des moment où il faut préférer le traitement bitmap au traitement par shader ?

Apriori, le Shader sera toujours (beaucoup) plus rapide.
Du moins, ça me paraîtrait logique qu'un traitement graphique soit fait plus rapidement sur la carte graphique

[Jean-Marc Le Roux]

Citation

Directement avec les outils intégrés au language AS3 (Shader), ce qui sous entends d'apprendre l'AGAL, ou alors avec des outils tels que Minko, qui a ce que je peux voir ressemble pas mal a des interfaces nodales telles qu'on peut les trouver dans differents soft de modelisation 3D.

Ca c'est une interface graphique. C'est pour faciliter le travail, éviter de coder et avoir un environnement de travail plus visuel.
C'est plus efficace dans certains cas.

Mais dans le code, Minko permet surtout de programmer les shaders en AS3 directement.
Donc tu peux programmer le GPU avec de l'AS3, pas besoin d'apprendre un autre langage.
Le code AS3 que tu écris est exécuté sur le GPU au lieu du CPU, c'est aussi simple que ça.

Citation

A vrai dire, c'est presque nécessaire de passer par une classe AS3 pour générer l'AGAL car cela permet d'obtenir un code lisible (ce qui n'est pas le cas quand tu code direct en AGAL) donc maintenable. Le fait d'ajouter des commentaires dans le code AGAL est nécessaire, mais ça ne suffit pas car le code reste difficile à lire et c'est facile de s'y perdre.

C'est surtout que le code AGAL écrit pas un humain n'est généralement pas du tout optimisé et c'est bien normal.
Il y'a aussi le fait qu'AGAL est trop bas niveau pour gérer beaucoup de choses essentielles.

Citation

des cas de figures vraiment complexe que je n'ai pas l'ombre d'une idée de comment il fait

Il ne faut surtout pas croire que Minko permet de gérer des cas ultra complexes qu'AGAL ne gère pas (même si in fine c'est le cas).
C'est plutôt qu'AGAL ne gère déjà pas les cas de base.

Exemple : j'écris un shader qui gère 3 lumières directionnelles et 2 points lights. Si j'ajoute une point light, je dois changer mon shader... Vous imaginez le travail que ça demande de modifier tous vos shaders dés que le graphiste ajoute une lumière ? Les shaders AGAL sont fixés et ne prennent en compte qu'un ensemble précis de fonctionnalités. Imaginez des programmes sans "if/else" et sans "for". Tout de suite, il faut écrire des dizaines de programmes pour gérer même les cas les plus simples.

En plus de pouvoir écrire les shaders en AS3, Minko offre toute une API de data binding qui permet d'utiliser les données de la scène dans tes shaders. Ca permet d'écrire un shader une fois, mais de lui faire gérer tous les cas. Exemple avec le BasicShader qui peut fonctionner avec une couleur unie, une texture ou une couleur par défaut (noir) :

var diffuseColor : SFloat = null;


// est-ce qu'il y'a une texture nommée 'diffuseMap' ?
if (meshBindings.propertyExists('diffuseMap'))
{
  // si oui alors on l'utilise
  var diffuseMap : SFloat = meshBindings.getTextureParameter(
         'diffuseMap',
         meshBindings.getConstant('diffuseFiltering', SamplerFiltering.LINEAR),
         meshBindings.getConstant('diffuseMipMapping', SamplerMipMapping.LINEAR),
         meshBindings.getConstant('diffuseWrapping', SamplerWrapping.REPEAT)
  );
  diffuseColor = sampleTexture(diffuseMap,interpolate(vertexUV.xy));

}
// sinon, y'a-t-il une couleur nommée 'diffuseColor' ?
else if (meshBindings.propertyExists('diffuseColor'))
{
   // si oui alors on l'utilise
   diffuseColor = meshBindings.getParameter('diffuseColor', 4);
}
// sinon, on utilise du noir
else
{
   diffuseColor = float4(0., 0., 0., 1.);
}
 

Ce petit bout de shader est à mon avis très simple à comprendre même si on ne connait pas l'API. C'est déjà un intérêt majeur de l'AS3.
Et pourtant, ce code est bien un (bout de) shader est sera executé sur le GPU !

Ensuite, ce qui est encore plus important c'est qu'au runtime, ce shader ne donnera pas 1 programme AGAL mais éventuellement 3:
- un programme qui utilise la texture 'diffuseMap' si elle est définie
- un programme qui utilise la couleur 'diffuseColor' sinon et si elle est défnie
- un programme qui utilise du noir

Exemple d'objets qui vont utiliser un tel shader :

var fx : Effect  = new Effect(new BasicShader());

var texturedCube : Mesh = new Mesh(
  CubeGeometry.cubeGeometry,
  {diffuseMap : TextureLoader.load(new URLRequest('texture.jpg'))},
  fx
);

var coloredCube : Mesh = new Mesh(
  CubeGeometry.cubeGeometry,
  {diffuseColor : 0xffffffff},
  fx
);


var blackCube : Mesh = new Mesh(
  CubeGeometry.cubeGeometry,
  null,
  fx
);

 

Chacun de ces 3 cubes utilisera au final 1 programme AGAL différent.
Pourtant je n'ai codé qu'un shader : chacun de ces 3 programmes AGAL sera compilé au runtime, uploadé sur le GPU et utilisé lorsque c'est nécessaire. Et si le programme n'est plus utilisé, il sera même enlevé de la mémoire automatiquement.
Et là c'est un cas très simple : je veux juste pouvoir utiliser mon effet avec une texture, une couleur ou une couleur par défaut. En AGAL, il faut déjà écrire, débuguer et maintenir 3 programmes. Alors qu'en AS3, ça prend 5 lignes...

Imaginons maintenant que certains cubes utilises du blending alpha et d'autres un blending "normal" (pas de transparence).
Le code AGAL et le même mais les paramètres à utiliser sont différents lors du rendu. Au lieu d'avoir une passe, on a deux passes:
- une avec blending alpha
- une avec un blending normal

Dans Minko, l'API détecte toute seule ce genre de disjonction de cas. Dans chaque shader, on peut initialiser les paramètres de la passe comme suit :

settings.blending = meshBindings.getConstant('blending');
 

L'API fera autant de passes que de valeurs utilisées pour 'blending'. Mais il le fera de manière optimisée : il fera une passe avec tous les objets transparents puis une passe avec tous les objets opaques. Cela permet d'avoir de meilleures performances.

Avec deux cas très simples (texture vs couleur, transparent vs opaque) et dont vous vous servez tous les jours, les shaders AS3 et l'API de data binding se montrent déjà beaucoup plus efficaces que de l'AGAL et vous épargnent sûrement des 100aines de lignes de code. Alors imaginez pour les cas plus compliqués : les animation par skinning et/ou morphing, l'animation des normales/tangentes, les lumières, le lightmapping, le multi-passes, le post-processing, etc...

Et le mieux, c'est que c'est une API. Vous pouvez ajouter toutes les propriétés que vous voulez.
Vous pouvez même coder des fonctions et les réutiliser. Ca s'appelle des "shader parts".
Exemple : grâce à l'AnimationShaderPart, vous pouvez en une ligne de code ajouter des animations par skinning/morphing sur n'importe quel shader ! Idem grâce au LightingShaderPart, vous gérez toutes les lumières de la scène en 1 ligne dans vos shaders perso.

Citation

Par contre il n'est pas possible d'utiliser la gestion des Shader de Minko sans utiliser Minko : ça va ensemble et c'est d'ailleurs ce qui permet à l'un et l'autre d'être si puissant

Tout à fait. D'ailleurs, les shaders AS3 devait au départ faire partie du SDK pro (fermé et payant).
Mais AGAL n'est tellement pas pratique et les autres langages de shaders comme le GLSL si peu flexibles que nous avons décidé de les mettre dans le SDK open source pour faciliter le travail de toute le monde

Concrètement, le UDK, Unity ou encore le Source Engine utilises des systèmes bien plus compliqués et bien moins pratiques pour au final ne faire qu'approcher cette flexibilité.

Citation

c'est pas la question, ce qui compte c'est que j'ai voulu apprendre AGAL, et que tout partage de connaissance explicite, documenté et désintéressé sur le sujet, dans l'esprit de ce forum, m'intéresse.

Personne a dit le contraire
Et justement je fais de même en expliquant pourquoi AGAL ne devrait pas être utilisé.

Modifié par Jean-Marc Le Roux, 02 July 2012 - 22:15 PM.

[alama.be]

Salut JM, désolé de revenir encore un peu à la charge..

J'ai lu à peu près tout de ce postt.. Au final, Minko avec son JIT facilite l'écriture du code, rend le code final (swf) plus abouti et optimisé, etc.. Mais en aucun cas, il ne pourra faire + que de l'AGAL ? c'est bien ça? Je veux dire, ton système ne bypass pas le core player je suppose? donc, pas question pour Minko de pouvoir utiliser d'instructions GPU qu' Adobe n'à pas prévu!? (pas de MULADD, pas de Math sur des (concat float registers) pas de math enteger (4 bytes integers form 1 float), pas de Logic (Boole) etc..) ? Je demande, parce que AGAL semble incomplet.. sans doute pour une question de retro compatiblité, car les GPU modernes, et surtout les GPGPU ont bien plein de petites ALU (SIMD) (basés FPU) et des instructions autres que ce que AGAL propose.. j'ai été lire pas mal de truc chez Nvidia et ATI à ce sujet hier.. (je voulais savoir.. même si je n'ai pas trouvé tout ce que je voulais, j'ai appris des trucs.. lol )

J'avais besoin de mieux comprendre les registres, comment ils fonctionnent, comment le GPU travaille, ce qu'on peut finalement faire et ne pas faire.. en matière de fragment program principalement. Et vu qu'on ne trouve pas vraiment ces infos, il faut cumuler les tests et en tirer des conclusions.. le but de mes recherches actuelles portaient sur le work flow exact d'un GPU. (comment il lit les registres, à quel moment et sur base de quoi..) j'ai déjà compris certaines choses, mais j'ai encore des doutes à tester..

Celui ci explique pas trop mal le flow ..
https://graphics.sta...S448s-10-03.pdf

ATI flow
http://gpgpu.org/wp/...rchitecture.pdf

Et ici, j'ai trouvé plein de slides qui expliquent pas mal de chose..
http://fr.slideshare.../working-of-gpu

[Jean-Marc Le Roux]

Citation

Mais en aucun cas, il ne pourra faire + que de l'AGAL ? c'est bien ça? Je veux dire, ton système ne bypass pas le core player je suppose? donc, pas question pour Minko de pouvoir utiliser d'instructions GPU qu' Adobe n'à pas prévu!? (pas de MULADD, pas de Math sur des (concat float registers) pas de math enteger (4 bytes integers form 1 float), pas de Logic (Boole) etc..) ? Je demande, parce que AGAL semble incomplet.. sans doute pour une question de retro compatiblité, car les GPU modernes, et surtout les GPGPU ont bien plein de petites ALU (SIMD) (basés FPU) et des instructions autres que ce que AGAL propose.. j'ai été lire pas mal de truc chez Nvidia et ATI à ce sujet hier.. (je voulais savoir.. même si je n'ai pas trouvé tout ce que je voulais, j'ai appris des trucs.. lol )

En fait la question est vraiment très complexe. Il faut différencier le langage, ce qu'il peut faire et ce pourquoi il a été conçu (la tâche qu'il accomplit). Mais pour répondre simplement, non, il est impossible d'avoir d'autres instructions que celles proposées par AGAL, de la même manière qu'il est impossible d'utiliser des instructions autres que celles gérées par le bytecode ABC côté CPU...

Après j'aurais tendance à dire que si tu as besoin de plus, c'est que tu ne devrais pas utiliser Flash. Quel est le but exactement ?

Citation

J'avais besoin de mieux comprendre les registres, comment ils fonctionnent, comment le GPU travaille, ce qu'on peut finalement faire et ne pas faire.. en matière de fragment program principalement. Et vu qu'on ne trouve pas vraiment ces infos, il faut cumuler les tests et en tirer des conclusions.. le but de mes recherches actuelles portaient sur le work flow exact d'un GPU. (comment il lit les registres, à quel moment et sur base de quoi..) j'ai déjà compris certaines choses, mais j'ai encore des doutes à tester..

Quels sont tes besoins exactement ?

Normalement, AGAL n'est pas trop fantaisiste à ce sujet. Il y'a certaines erreurs assez violentes qui ne sont pas gérées par l'AGALMiniAssembler qui malheureusement se contente de traduire plus qu'autre chose. Ces erreurs/incohérences sont à priori - entre autres choses - lissées par le compilateur de Minko justement, qui permet de se concentrer sur ce qu'on veut faire et de comment fonctionne un shader plutôt que comment faire manger de l'AGAL au FP.

Modifié par Jean-Marc Le Roux, 17 September 2012 - 16:10 PM.

[alama.be]

Salut JM, merci pour la réponse.

Alors, en fait, si, je veux rester en Flash.. il est clair que je devrais faire mes trucs en C ou C++ ou même C# ou même VB .. Mais justement, j'aime pousser Flash dans ses derniers retranchements ou en tous cas faire des trucs étonnants.. Je suis passionné d'Audio, donc, je fais pas mal de trucs dans ce secteur.

Le but est bien de faire tout ça en Flash et que ce soit WEB diffusable (même pas en Air). Ca me permet également de demander des features à Adobe, de participer de loin à son élaboration en proposant des idées, etc.. sur leur blog spécialisé.

Là, pour le coup, la semaine passée, je me suis intéressé à Stag3D et à AGAL suite à notre discussion sur le post Minko 2.0 . Je n'avais jamais exploré cet aspect de Flash, mais là, ça va, c'est déjà bien démystifié :-)

Donc, ce que je regarde, ce sont les possibilités de détourner stage3D, afin d'utiliser le GPU pour lui faire traiter des signaux audio. Soit, des buffers de par exemple 4096 Floats allant de -1 à +1.

Ma première idée (la + simple ) a été de travailler en texture.. mais très vite, j'y ai vu les limitations.. (texture obligée exposant de 2) et aussi le fait qu'il est impossible de charger les floats dans le GPU afin de les appliquer à la texture.. en effet, seuls les fragments sont traités par le code AGAL, donc, avec 4 vertexs, je ne peux accéder qu'a 4 valeurs Float préchargées en VA .. Les constants, n'en parlons, on dirait que seuls 4 Floats sont accessibles par program AGAL.

Bref, j'ai pu quand même faire ceci:
http://www.pureas3.o...lab/DSP-on-GPU/

La prochaine étape va être d'essayer à présent avec l'approche Vertexs, construire 4096 vertexs (+ 1 ou 2 pour fermer le dernier fragment) et voir si, de cette façon, je peux accéder à mes 4096 floats.

Mais le problème ne s'arrête pas là.. car actuellement, Flash ne permet aps un retour direct du GPU, mais la seule sortie possible est "image" render, et je suis obligé de sortir mes valeurs en RGBA, soit 4 octets max entiés non signé. Hors, mes Floats sont au format IEEE754, 1 bit de signe, 8 d'exposant et enfin 23 pour la valeur de base..

Bref, t'as compris pourquoi ce n'est pas si simple.. Mais bon, c'est Adobe et AGAL le responsable..

Soit, voilà pour l'explication .. J'essaye pour le fun, mais je pense qu'il va falloir attendre l'AVM4 qui permettra un réel accès direct au GPU, donc, via du code ABC .. donc, même si AS4 ne prévoit pas tout, on pourra toujours bidouiller en ABC ou Alchemy..

[Jean-Marc Le Roux]

Citation

Donc, ce que je regarde, ce sont les possibilités de détourner stage3D, afin d'utiliser le GPU pour lui faire traiter des signaux audio. Soit, des buffers de par exemple 4096 Floats allant de -1 à +1.

Tu as vu ce que j'ai fait avec le shaderlab ?



La première partie de la vidéo c'est justement un truc qui sample du son et modifie la géométrie en conséquences.
Vu que c'est fait avec le shaderlab ça utilise même pas une ligne de code ^^

Citation

Soit, voilà pour l'explication .. J'essaye pour le fun, mais je pense qu'il va falloir attendre l'AVM4 qui permettra un réel accès direct au GPU, donc, via du code ABC .. donc, même si AS4 ne prévoit pas tout, on pourra toujours bidouiller en ABC ou Alchemy..

Oui enfin si tu es prêt à attendre 1 ou 2 ans... Et même à ce moment, ça ne passera à priori pas par du code ABC et il y'aura toujours des contraintes sur les formats d'entrée/sortie (même si un CUDA core c'est forcément mieux qu'un vertex/shader core vu que c'est pas fait pour ça...). Quand tu vois les environnements de dev pour faire du CUDA, vu ce que nous sort en ce moment Adobe avec Flash Builder/Pro y'a de quoi flipper...

Citation

Mais bon, c'est Adobe et AGAL le responsable..

C'est plutôt les restrictions d'OpenGL ES 2 qui est un vieux standard tellement tout pourri qu'ils vont passer à Open GL 4 pour la prochaine version d'ES. C'est dire s'ils ont du retard ! C'est la faute aux Khronos Group qui va trop lentement surtout donc

[alama.be]

Oui, j'avais vu cette video Mais bon, là, c'est des vertexs déplacés avec les datas issues d'une FFT computeSpectrum .. (ou du vertexs texture fetch, je sais pas). Là, j'essaye de mofifier les données audio et les ressortir.. c'est différent comme démarche

J'adore la terre et les nuage qui tournent.. tu connectes ça avec des données (captures jpg satellite) météo temps réel et ça le ferait

Tu as raison, Adobe fait peur parfois.. il leur est difficile de suivre la techno.. Mais bon, j'essaye de m'y accrocher encore un peu, je garde de l'espoir..

Mais vu que c'est pas canvas et JS qui va m'aider.. autant rester sur Flash ..

Sinon, il a l'air sympa ton shader lab :-) ça mérite qu'on s'y attarde.. mais ce sera quand je ferais de la vraie 3d, là, ce n'est pas encore le cas