version 2 sujet à questions en vrac XD

pour la classe Color, que penses tu de mettre comme ça :

Code:

class Color
{
[...]
   union
   {
      unsigned long int c;

      struct
      {
         unsigned char r;
         unsigned char g;
         unsigned char b;
         unsigned char a;
      };
   };
[...]
};

En fait a la base j'avais mis un long int mais j'avais besoin que ce soit vraiment stocké en RGBA en mémoire que ce soit du big ou du little endian ce qui n'est pas le cas avec un long. C'est une opti spécifique pour l'opengl en fait comme ca les data de couleurs peuvent être envoyé tel quel.

Mettre une union serait pas consistent parceque dependant big/little endians. en little endian en faisant un color.r on aurait le a, bref tout serait inversé

finalement j'ai rien dit, j'ai confondu comme tu l'as mentionné BE et LE.

ce que tu as besoin en opengl c'est abgr (0xAABBGGRR) même si dans la classe l'ordre c'est rgba, c'est ça qui m'a mis dans l'erreur.

si ça avait été 0xRRGGBBAA, convertir en 0xAARRGGBB (dx) n'aurait couté que 2 instructions assembleur (contre 9 pour la méthode de la classe Color)

mais bon, j'ai pensé de travers, méa culpa

question suivante de madame chombier : dans la nouvelle version de l'interpolator, tu ne peux plus avoir de graph comme dans l'ancienne de ce que j'ai lu dans le code.

de 1) est ce que j'ai bien compris?

de 2) comment tu fais la même chose dans la nouvelle version?

et de 3) si on ne peut plus le faire, pourquoi cette limitation?

ps : j'ai peut être trouvé ma réponse, c'est par les modifiers, non?

En fait c'est juste que j'ai pas encore implémenté cet interpolator a base de graph dans la nouvelle version Mais ce sera une classe dérivé de Interpolator comme les autres (GraphInterpolator sans doute)

ha ok, je pouvais toujours chercher XD

je suis en train de faire l'architecture de la version gpu, et vu que ça risque d'être particulièrement static, je fais la liste de ce que j'ai besoin ^^

je viens donner des nouvelles concernant la version gpu. j'ai un résultat presque équivalent à basic demo.

ensuite je voudrai savoir si tu as un peu de doc pour la version 2, il y a quelques variables que j'ai du mal à comprendre la fonction.

Cool. Niveau perf ca donne quoi ? J'imagine que c'est plus ou moins équivalent avec si peu de particule comme la demo est fillrate limited. Je serais curieux de voir une démo.

Pour la version 2, désolé j'ai pas avancé ces derniers temps comme je suis sur d'autres trucs. Mais je m'y remet bientot. Pour la doc tout ce qu'il y a est sur le svn pour l'instant. Mais si tu as des points en particulier a eclaircir je peux sans doute le faire ici.

niveau perf j'ai 600fps pour 10k particules et 125fps pour 100k, ça laisse une bonne marge de progression.

le problème c'est qu'on va perdre pas mal en fonctionnalités à cause des limitations des compute shader model 4 à savoir :
- 1 seul et unique buffer typé en sorti, les seules données que je peux mettre à jour sont les particules en elles mêmes
- absence de variable atomique, sachant qu'une carte graphique a maximum 768 threads (en dx10), on aura du mal à savoir par exemple combien de particules sont encore vivantes etc...

peut être que ces problèmes disparaissent en cuda, mais l'overhead créé par la récupération des données cuda pour ensuite les passer à dx est trop important (j'essayerai de faire une estimation de la perte)

pour la doc de la version 2, il n'y a rien sur le svn.

donc par exemple à quoi sert le champ Group::nbBufferedParticle ?

pour voir une démo, je verrai à mettre le code sur le svn ou mettre une vidéo, selon la masse de modification que je ferai aujourd'hui.

voilà une vidéo de la version gpu : https://www.youtube.com/watch?v=CDRSwxUecdo

Wow... impressionnant !

pour l'instant il n'y a pas grand chose qui marche totalement, pas de flot, que le random emitter, le point zone, quelques modifiers (gravity et friction), l'interpolateur simple et l'initialiseur.

ça avance doucement parce qu'il y a plein de contrainte à cause de la prog gpu ><

Désolé pour le peu de présence ces derniers temps. C'est un bon début en tout cas. J'imagine bien que gérer son code GPGPU de facon flexible est pas évident du tout. Sinon niveau conception comment ca se passe, l'interface reste elle identique ou est elle modifiée ? De mon coté je vais bientot me remettre sur la facon 2 histoire d'implémenter les trucs qui restent a faire.

PS : Pour le nbBufferedParticle, c'est un compteur qui indique le nombre de particules a ajouter manuellement au groupe a cette frame. Ca concerne les particules ajouté avec les méthodes addParticles(...) et non celle créé par les emetteurs du groupe. Les infos sont stockés dans une queue qui est popé a chaque frame quand il y a des particules a ajouter.

le point noir de la programmation en direct compute c'est qu'on a à disposition un langage beaucoup moins expressif que le c :
- pas de pointeur
- pas de polymorphie
- pas de tableau dynamique
et j'en passe et des meilleurs

la seule possibilité pour donner à manger au gpu c'est une sorte de vector de structures.

donc toutes les structures doivent être de même taille et si possible de taille multiple du float4 (4 * 32bits) pour éviter les contraintes d'alignement.

voici un exemple de structure que je dois utiliser pour pas être embêté :

Code:

struct Interpolator
{
   // rien de prévu pour le random interpolator
   float4 data1; // type
   float4 data2;
   float4 data3;
[...]
};

grosso modo je dois prendre la taille max d'un interpolator et m'en servir pour tous les interpolators. (et encore comme j'ai indiqué, j'ai rien prévu pour le random)

pour l'interface je sais pas encore, mais tout ce que je sais c'est que tout ce qui nécessite une écriture va poser problème, étant donné que j'ai une seule ressource possible en écriture et elle est déjà utilisée pour la màj des particules.

ajout de la gestion des Modifiers Obstacle \o/

bon voilà, je dois rendre le projet lundi, j'en profiterai pour le mettre à disposition de tout le monde

Cool, tiens nous au courant des résultats du projets !
Sinon oui je vais te créer un repertoire sur le svn ce week end pour que tu puisse l'uploader.

toujours pas de répertoire?

Voila le SVN :
https://sparkengine.svn.sourceforge.net/svnroot/sparkengine/spark_GPU_DX11

Désolé du petit contre temps

no problem, merci, je vais surement uploader dans la journée

voilà c'est uploadé, je vous en prie, testez.

si vous voulez des exe, dites le.

(vs2008 uniquement, sdk dx de février 2010, hardware dx10 minimal, donc vista mini)

stardeath wrote:

(vs2008 uniquement, sdk dx de février 2010, hardware dx10 minimal, donc vista mini)

Ah c'est pas directX 11 minimum ? Je pensais que tout était implémenté en compute shaders.
Enfin je met a jour mon SDK DX et je teste ca.

en fait c'est une initialisation dx11 avec les capacités de dx10, donc un hardware dx10 mini; ça fait parti des fonctionnalités de dx11 de pouvoir créer un device avec une compatibilité inférieure.

et avec le nouveau sdk de dx11, on peut avoir des compute shaders pour dx10, avec un niveau de fonctionnalités 4.0 (5.0 en dx11).

Je vais essayer de tester, mais c'est pas gagné vu que je suis sur XP avec dx9...

Darktib wrote:

Je vais essayer de tester, mais c'est pas gagné vu que je suis sur XP avec dx9...

je doute que ça marche ><