version 2 sujet à questions en vrac XD

Juff wrote:

Hi, I wanted to talk a bit about the future interface of multithreaded system. How would be something like that ? :

SPK::System* system; // Lets say that s the system to update

SPK::SynchronizedSystemPair* syncSystems = new SynchronizedSystemPair(system);

// On the update thread :
syncSystems->update(deltaTime);
// or equivalent
system->update(deltaTime);

// On the render thread
syncSystems->render();

// To synchronize (in any of the threads supposing neither update or render is performing on threads)
syncSystems->synchronize();

Where the SynchronizedSystemPair is an object that holds 2 systems.
The second system (the render system) is totally encapsulated within the systemPair object and constructed from the system passed in parameters with the minimum stuff for rendering. Calls to update and render calls respectivelly the update and render methods of the correct system while synchronize copies needed data for rendering from the update system to the render system.

je comprends pas trop ce que ça va changer par rapport à maintenant.

si tu pouvais expliquer un peu ^^

Bah en fait c'est plus un truc en plus qu'un changement. Pour l'instant ce n'est pas vraiment possible de multithreader les systèmes de particules (update et rendu dans 2 frames séparés). Parceque si un thread réalise le rendu a partir de certaines data pendant qu'un autre update les même data, il va y avoir un problème d'intégrité des données.

L'idée c'est d'avoir un objet en plus qui permet de lier 2 systèmes, 1 pour l'update et 1 pour le rendu, le tout de facon thread safe. Il y a une passe de synchro a faire régulièrement pour updater les data du système de rendu avec les data du système d'update mais en dehors de ca on peux updater et rendre les systèmes en meme temps. Après il sera tout a fait possible de continuer a utiliser les systèmes de particules de facon classique avec update et rendu en série dans le meme thread. C'est juste un truc en plus permettant de multithreader la gestion des particules de facon simple et performante.

D'ailleurs je poserai bientot la version 2 sur svn. La philosophie reste la même mais il va y avoir pas mal de truc de changé. Normalement ce sera plus performant, plus facile a utiliser et mieux designé. Après faudra qu'on s'occupe du module directX pour le sortir dans une release.

je suis pas très en phase avec ça, mais il suffirait pas de mettre un verrou lors du rendu, genre :

Code:

rendu
{
   pose d'un verrou sur les données

   bind des buffers en toute sécurité grâce au verrou

   (en directx la libération du verrou se ferait tout de suite, en opengl je sais pas)

   dessin des particules

   libération du verrou
}

enfin, c'est ce que fait havok dans son moteur physique, après je me plante peut être totalement.

Ca ca va rendre le truc thread safe mais ne va pas permettre l'update et le rendu de facon concurrente. L'utilisation de verrous/mutex va empecher le rendu mettons dans le thread 2 pendant que l'update s'effectue dans le thread 1. Mais pendans ce temps le thread 2 va attendre que le thread 1 ai terminé l'update avant de faire son rendu. Donc aucun gain en utilisant des threads (meme pire que mieux).

Après moi je ne veux pas rendre la librairie thread safe par contre l'utilisateur a tout a fait la possibilité de poser ses verrous et de faire ce qu'il veut (genre réaliser l'update des particules dans un thread séparé du thread principal. L'update du reste (game logic...) s'effectuant dans le thread principal. A la fin de l'update du thread principale, le thread attend que l'update des particules soit effectuée et lance alors le rendu de toute la scene.

La le rajout que je veux faire c'est vraiment désolidariser l update du rendu. Après il faut que je fasse des tests.

pas des masses convaincu pour la concurrence, la synchro étant sous verrou de toute manière, ni le rendu ni l'update ne pourront être fait pendant la synchro. je ne sais pas ><

enfin je vois clairement pas, j'attendrai la réalisation pour voir XD

Bah en fait le fait d'avoir 2 threads, une pour l'update et une pour le rendu qui bosse de facon concurrente est un design qui se fait. Le communiquation se fait par un command buffer qui est updaté par le thread d'update et flushé par le thread de rendu. Maintenant c'est vrai que pour des data dynamiques comme les particules, la synchro impose quand meme pas mal d'overhead comme il faut copier les buffers.

Après reflexion, la solution pour gérer les particules avec ce genre de design serait plutot de réaliser l'update dans le thread de rendu comme en général les particules ne vont pas être utilisée dans la logique du jeu. Le thread d'update etant alors simplément chargée d'envoyer des commandes au thread de rendu (genre "crée un système de particules de ce type a cette position").

Il faudrai que je test et bench les différentes possibilités de multithreadé ces particules voir ce que ca donne. Mais après c'est pas la priorité et je réfléchissait au sujet parcequ'il a été évoqué dans le forum et ouvrais le débat parceque je ne m'y connais pas énormément en rendu multithreadé, donc c'est cool d'avoir donné ton avis.

en fait j'ai la vision qui est bridée par le fait que pour moi les particules ne servent QUE pour le rendu, j'oublie un peu le fait que ça pourrait servir pour autre chose.

donc quand on en a besoin, un verrou sur l'update et ça suffit, mais non, y a pas que le rendu dans la vie.

ensuite le command buffer, j'ai un avis partagé dessus :
- d'un coté on lance une commande et on récupère la main de suite après, pas de temps d'attente
- d'un autre on a plutôt intérêt que les données soient disponibles au moment de l'exécution réelle de la commande

enfin ça a quand même l'énorme avantage de se paralléliser "facilement".

j'ai en tout cas hâte de voir ce que ça va donner.


de mon coté j'ai un projet à réaliser à la fac et qui est de porter spark en compute shader, je posterai les sources si ça intéresse

stardeath wrote:

- d'un autre on a plutôt intérêt que les données soient disponibles au moment de l'exécution réelle de la commande

Bah justement les données sont pas sensé être partagé entre les thread. Les données de la géométrie étant du coté rendu (même sur le gpu). le thread d'update ayant juste ce qu'il lui faut (bounding box pour le culling et les collisions...). Après ouais c'est pour les données dynamiques que c'est plus problématique.

stardeath wrote:

de mon coté j'ai un projet à réaliser à la fac et qui est de porter spark en compute shader, je posterai les sources si ça intéresse

C'est très interessant ca. C'est rentre plus dans domaine de la recherche que de l'industrie pour l'instant. En plus si tu parviens a porter la lib en full gpu, le portage sur d'autre techno plus portables comme cuda ou opencl sera bien facilité.

Pour ma part, je comptais amélioré spark pour utiliser les geometry shaders si possible histoire de déporter au maximum de la charge sur le gpu. L'update quand a elle resterai coté cpu pour plus de flexibilité.

effectivement les geometry shaders affranchiraient le cpu de la création des lignes, quads, etc, étant donné qu'il a été introduit dans le pipeline pour ça.

j'avais pensé commencé les renderers dx10 juste après les 9, mais j'avais appris à l'époque la sortie "imminente" de dx11 j'ai attendu, ensuite il a fallu que j'attende nvidia pour des pilotes potables pour la carte graphique de mon portable et maintenant j'ai un projet de dx11/gpgpu à faire, j'en profite.

pour un portage full gpu, pour l'instant (et vu mes tentatives) c'est pas encore faisable, y a trop de contrainte (entre autre dx11 par encore supporté chez nvidia), donc compatibilité dx10, mais y a moins de fonctionnalités. pour l'instant c'est un casse tête; à part un shader monolithique par zones/groupes/etc je vois pas trop comment je vais découper ça correctement.

un autre point qui peut être avantageux/ou pas du full gpu, toutes les données seront en "mémoire graphique" plus rapide, mais si on en a besoin sur le cpu le rapatriement risque de poser problèmes.
enfin ce dernier point, j'aurai l'occasion de le tester sur le projet, je serai pas handicapé par dx10 pour ça ><

petit test en brutal : 150k particules affichées avec 60fps

150 000 particules à 60 fps ? Wow... Çà augure du bon!

ouais c'est pas mal, mais ça fait un gros chiffre surtout parce que toutes les particules sont totalement indépendantes, pas de collision, pas d'influence inter-particule etc...

je vais continuer à parler de la version 2 ici.

j'ai lu dans un autre topic que tu vas passer la gestion des couleurs de 4 floats à 1 DWORD. je suis pas sur que ça soit le bon plan, les cartes graphiques commencent à gérer en natif les couleurs avec 10 bits par composantes, voir 16 pour certains types de textures.

ça serait comme un retour en arrière.

Les framebuffers sont en 32 bits donc pour l'instant les couleurs 128 sont convertie en 32. Donc a par avoir 4 fois plus de données a transférer au GPU ca apporte pas grand chose. Et puis il y a une classe couleur donc suffit de la templatiser, de mettre un typedef et on pourra eventuellement compiler la lib avec les couleurs au format qu'on veut.

hum pas sous dx, je peux aller jusqu'à 16 bits par canal sur ma cg.

enfin si tu as une classe où on "peut" choisir le format, rien à dire, la maitrise ^^

Bah pour l'instant on peut pas choisir le format. Mais c'est pas très compliqué de la rendre générique. Seulement pour l'instant je ne vois pas trop l'interet comme je l'ai dis. Les frame buffer en 64 bits ca va être utile pour eviter de la perte de précision ou pour stocker autre chose que des couleurs mais dans le cas de spark, des couleurs 32 bits suffisent amplement je pense. Enfin a voir...

j'ai trouvé un autre inconvénient au DWORD à la place d'un float4, le float4 est le type natif de gestion des couleurs dans les shaders directx (la sémantique COLOR étant associé à un float4).

enfin "inconvénient" c'est un bien grand mot, il y aura toujours moyen de décoder sur le cpu ou le gpu. après faut voir le surtout, à tester.

comme j'ai dit, ça "me" parait juste bizarre, je serai pas traumatisé en tout cas, pas de problème de ce coté là.

ps: je vois dans le constructeur de GLBuffer que tu fais des new, j'ai vaguement un souvenir de quelqu'un sur développez qui disait que c'était pas recommandé si jamais un des new foirait.
qu'en penses tu?

Le probleme des particules dans un projet c'est que ca peux très vite devenir le facteur limitant d'une application si c'est mal utilisé. Il y a principalement 3 goulots d'étrangelement potentiels :
_ le cpu : trop de particules trop complexes a updater par ex
_ le bus : les data des particules etant dynamique vaut les renvoyer au gpu a chaque frame
_ le fillrate : Trop de particules trop grosses a l'écran vont mettre a genou les cartes graphiques même récentes
La en reduisant par 4 la taille des color buffer ca permet d'avoir moins de data a transférer au gpu et donc de soulager un petit peu un des goulots d'étranglements potentiesl. Après si vraiment ca pose problème, il y a toujours la solution de rendre la classe Color générique facilement, on verra

Pour les new, oui c'est sans doute pas la meilleur pratique mais en même temps si un new foire c'est que l'allocateur arrive pas a allouer donc que la RAM est soit pleine soit fragmentée mais en tout cas inutilisable. Si ca arrive, une exception va etre lancée, soit elle est attrapée soit non et dans ce cas la l'execution s'arrete. Mais de toute facon ca finira par planter quelque part. Mais oui la bonne pratique serait de bien gérer la construction d'objet avec des exeptions mais j'ai un peu la flemme de passer du temps pour gérer des comportements indéterminés. J'ai rajouté un logger déjà qui peut déjà faciliter le traquage de la cause des plantages.

totalement d'accord, normalement le décodage est quasiment gratuit sur le gpu (ça serait trop long à expliquer pourquoi, grosso modo faire des calculs permet de casser les temps d'accès à la mémoire, vive mes cours d'architecture de gpu).

pour le new dans le constructeur, c'était juste pour ma culture personnel ^^

question pratique, je peux commencer à revoir les renderers directx ou pas?

Oui si tu veux tu peux commencer. Je garantie pas que rien ne vas changer encore mais a priori c'est plus ou moins fixé. Tout n'est pas vraiment documenté non plus mais si t'as des questions hésite pas.

Code:

void GLBuffer::setNbTexCoords(size_t nb)
{
   if (this->nbTexCoords != nbTexCoords)
   {
      this->nbTexCoords = nbTexCoords;
      delete texCoordBuffer;
      if (nbTexCoords > 0)
         texCoordBuffer = new float[nbVertices * nbTexCoords];
      currentTexCoordIndex = 0;
   }
}

je crois que le nom de l'argument n'est pas bon (nb à la place de nbTexCoords), je corrige pas moi même je veux pas interférer par erreur avec le code sur le svn.

exact C'est corrigé. Et puis c'est un delete[] pas un delete aussi... J'ai pas encore tout bien testé

des nouvelles de mon coté (que j'aurai pu faire avant) :

j'ai commencé à faire les renderers directx, l'architecture a pas mal changé par rapport à avant, mais ça devrait se faire assez vite.

question : les RenderBuffer servent à quoi au fait?

A stocker les buffer pour le rendu

Comme on en avait déjà parlé, ca ne doit pas être les renderer qui stockent les buffers mais les groupes.
Lorsqu'un groupe doit être rendu, il appel la méthode render de son renderer en lui passant son RenderBuffer.

Le renderBuffer est créé pour un groupe avec la méthode attachRenderBuffer(Group&) des renderer. Le renderBuffer d'un groupe est détruit si le renderer du groupe est changé, si le groupe est réalloué ou si il y a un appel manuel a destroyRenderBuffer().

Le rendereur lui a pour role de remplir le renderBuffer du groupe et de l'envoyé au GPU.

Dans les rendereurs OpenGL, je ne les utilise pas tout le temps parceque parfois on peux envoyer les données directes sont les réorganiser mais pour DirectX c'est pas vraiment possible.

En gros les renderbuffer du module directx vont encapsuler l index et le vertexBuffer. Y a moyen de gérer le problème de la perte du device avec un container. Un renderbuffer directX stocke un pointeur sur son groupe. A la création on l'ajoute au container et a la suppression on le retire. Si y a perte du device, on fait un appel a destroyRenderBuffer pour chaque groupe.

ok, merci ça m'éclaire bien, merci.

ça va simplifier pour directx, je vais implanter ça assez vite.