renderer directx

Cool, ca veut dire que c'est quasiment fini. Donc ca pourra être intégré a la prochaine version.
Je regarderai tout ca en profondeur quand j'aurai du temps.

j'ai une question sur la méthode setRenderer du Group, si tu passes le bufferManagement à false (pour pas être embêter sur la création des buffers sans device existant), la destruction des anciens buffers n'est plus assuré ici, mais il n'y aurait pas de risque de memory leak, parce que je vois pas où ailleurs ceux ci sont détruits.

Code de la fonction pour t'éviter de chercher :

Spoiler:

Non pas de risque de memory leak, tous les buffers sont détruits avec le groupe auquel ils appartiennent.

J'ai commencé a regarder le module DirectX.

Pour l'instant j'ai juste compilé les lib et les démos.
Au passage la lib dxerr9 est déprécié et n'est plus inclus dans le dernier SDK, je l'ai donc remplacé par la nouvelle a savoir dxerr.
Sinon il y a des messages d'erreurs dans les démos du au fait que le device est deleté sans que les buffers de SPARK le soit. C'est parceque les objets de SPARK sont créé sans être détruit. Il faut mieux utiliser les méthode create plutot que des new et deleté les objets avant de détruire le device. Je vais m'occuper de ca.

ouais le code des démos est assez pourri, je te laisse faire ça ^^

va falloir trouver une solution plus propre que les oncreatedevice et autre, perso ça me plait pas des masses

Ouais les oncreatedevice et autres, j'ai vu ca.

Je suis pas très familier avec directX donc je sais pas exactement comment fonctionne le changement de device, reset et toute la gestion des ressource associé au device. Mais je vais me renseigner.

Pour l'instant en gros, ca fonctionne comment ? Les fonction On... implémenté dans le renderer DX9 de base emprunte leur syntaxe a direct3D mais elle doivent etre appelé directement par l'utilisateur, c ca ?

en fait direct3d fonctionne comme opengl, on ne peut pas appeler de méthode gl* tant qu'on a pas initialisé quelque chose, en opengl la fenêtre, en dx, le device.

ce qui fait qu'on est obligé de créé pour spark les buffers (vu que je les ai implanté comme ça) après la création du device, quand on créé tout à la main, pas de problème;

mais dans les démos dx, on utilise souvent dxut (un glut pour dx) et c'est ça le problème :

voici les callbacks de dxut (dans l'ordre d'exécution) :

OnCreateDevice
OnResetDevice [...]


je finirai mon post un peu plus tard, je crois que avant d'émettre un pseudo problème, il faudrait que je réfléchisse un peu plus, je teste ma solution et je reviens dire si ça marche T_T

ps: je suis effectivement un blaireau, ma solution marche, bon vu qu'il est assez tard ici, je vais pas avoir le temps de faire un post complet ainsi que les mises à jour du code nécessaire, je ferai ça demain tout à l'heure à la première heure, désolé de te faire patienter avec cette bétise ><

t inquiete. prend ton temps.

J'aimerai sortir le module directX 9 avec la nouvelle version. Il me reste encore des trucs a faire dans le core (retirer les callback et gérer "l'émission" d'emetteurs et de modifiers).

j'ai un problème, grosso modo les buffers doivent être détruits si j'ai un problème avec mon device.

le problème c'est que le problème n'est détectable que dans le main de l'application, je dois donc à cette endroit trouver un moyen simple de supprimer les buffers posant problème.

ps: j'ai peut être une solution, garder une trace dans ma classe dx9info des buffers potentiellement problématiques, pour directement les effacer si besoin.

[EDIT] en gros c'est la même idée que toi [/EDIT]

Une solution pourrait être de garder une trace de tous les buffers par exemple dans ta classe DX9Info.
Apres dans le code des DX9Buffer, lorsqu'un buffer est créé, il est ajouté a ce container et lorsqu'il est deleté, il est retiré de cette liste.

Le truc chiant c'est qu'il faut garder le groupe ainsi que le nom du buffer dans le container, pour pouvoir les retirer des groupes. Peut etre avec le container etant un set contenant des objets du style :

Code:

struct DXBufferInfo
{
Buffer* buffer;
Group* group;
string name;
}

Le tri du set se faisant avec la valeur de buffer (en surchargeant les operateur < et ==), ou bien utilisé une map avec l'addresse des buffers en clé.

Ensuite tu a une fonction du style :

Code:

void resetDXBuffers()
{
pour tout les DXBufferInfo
    group->deleteBuffer(name)
}

C'est la solution qui me viens a l'esprit la maintenant. Ce qui est chiant c'est que les ID des buffers sont dupliqués (dans les groupes et dans le containers).

Y a peu etre mieux.

Sinon la solution barbare etant de supprimmer les buffers a la main (un destroyAllBuffers pour tous les groupes).
Je veux dire, est ce que la perte du device doit être gérer coté librairie ou coté utilisateur ?

c'est impossible (à première vu) de gérer ça en interne à la librairie, l'élément permettant de détecter le problème étant l'équivalent du swapBuffers de opengl, c'est donc à l'utilisateur de dire à la librairie de détruire les buffers problématiques, enfin je le vois comme ça.

perso dans le module openGL, je n'ai pas du tout géré le changement de contexte, c'est a l'utilisateur de le faire.

Mais sinon ouais faciliter la tache de l'utilisateur en directX peut etre interessant. Même si je ne sais pas si la perte du device est vraiment quelque chose qui arive souvent...

en directx, le redimensionnement d'une fenêtre suffit à perdre le device ... ><

ah ouais ? Le redimensionnement de fenetre dans les démos fonctionne correctement pourtant.

ça dépend dans quelle zone de mémoire sont créés les buffers, si en ram, une perte de device n'aura aucune incidence, problème la ram est moins rapide que la mémoire gpu, mais elle, elle est sensible à la perte du device, bref un sacré bazard XD

ok c'est la meme en OpenGL avec les VBO vs VA. En plus j'imagine que les textures sont perdues aussi. Mais bon ca c'est a l'utilisateur de les recharger et resetter les textures des renderers.

D'ailleurs en parlant de VRAM, il faudra vraiment optimiser les flags D3D des buffers et des lock pour avoir un max de perf.

ouaip je regarderai ça après ce problème de buffers ^^

(et j'étais pas au courant du problème similaire pour opengl)

ps: bon j'ai mis une solution, me reste à la tester sur tous les samples

ps2: bon ça marche pas des masses ...

l'opération swap sur les buffers est ce que c'est une fonction vitale dans le moteur?

bah oui la swap est assez vital dans certains cas (pour garder les données des particules correctes) mais uniquement quand le buffer est créé en lui spécifiant d'activer le swap.

Pour les buffer ou il n'y a pas besoin de faire de read back (en write only) comme ceux servant a organiser les données pour le GPU, le swap n'est pas utilisé.

Mais en fait je ne vois pas trop le rapport avec le device ?

en fait j'avais réglé le problème des buffers invalides, je n'avais plus d'erreur lors du rendu avec des buffers invalides, et je suis tombé sur un cas ou particleSystem->update(fElapsedTime); tentait de faire un swap (LineTrailRenderer) sur les buffers invalides, et donc ça plantait lamentablement.

mais si tu me dis que le swap des buffers gpu peut être désactivé, il ne me reste plus qu'à éprouver ma solution.

Bah justement le LineTrailRenderer à besoin de pouvoir être lu, puisque les positions/couleurs des différents points des lignes sont stockés et updaté ici. Donc il faut garder le swap. Normalement un update sur un buffer invalide ne devrait pas arriver.

Mais en fait j'ai regardé ta solution et ca me parait compliqué. Le seul truc qu'il faut rajouter a l'interface de DXPool ca devrait être une fonction permettant de détruire tous les buffers de SPARK utilisé par direct3D. Cette fonction est ensuite a appelé par l'utilisateur juste avant le reset ou la destruction d'un device.

En fait utiliser la méthode que j'ai exposé dans un post avant. L'ajout de buffer a conteneur de DX9info se fait dans les renderers direct 3D et dans la méthode clone des buffers et le suppression des entrées dans le conteneur a la destuction des buffers. Le add et removeBuffer de DX9info peut eventuellement etre caché a l'utilisateur en ayant des méthode dans la classe de base DX9Renderer en protected faisant le lien et en rendant DX9Renderer friend de DX9Info.

Après tout ce qui se passe dans le OnCreateDevice des renderer et autres peut être déporté dans le setDevice de DX9Info

Sinon je me suis renseigné un peu aussi et je pense qu'il ne faudrait pas laisser a l'utilisateur la possibilité de setter le pool mais tout passer en Pool par défaut en ce qui concerne les buffers. En fait le pool managed créé une copie en RAM de tous les buffers au cas ou il y a une perte de device pour pouvoir les récupérer du coup c'est plus lent et ne s'applique pas au buffers dynamique de toute facons.

http://msdn.microsoft.com/en-us/library/ee416513.aspx
http://msdn.microsoft.com/en-us/library/ee422025.aspx

bon plus je lis ton post et moins je comprend ce que tu veux dire, la seule chose que j'ai saisi c'est que tu ne veux pas laisser le choix du pool à l'utilisateur, ça ok mais le reste ....

En fait ce que je disais c'est que tout ce dont a besoin l'utilisateur dans DX9Info c'est :

• setDevice
  
• getDevice
  
• deleteAllBuffers
  

le deleteAllBuffers est a appeler explicitement juste avant un reset/perte/destruction du device.

Apres tout est géré automatiquement en interne.

Mais en fait après reflexion mon explication va pas fonctionner, alors en voila une autre qui elle devrait fonctionner :

Il va sans doute falloir rajouter un membre group aux buffers directX qui sera simplement un pointeur sur le groupe du buffer.
DX9Info a un set de Buffer* (un set me parait etre mieux qu'une list parceque l insertion/deletion se fera en O(log n) plutot que du O(1) pour l insertion et O(n) pour la suppression)
Ensuite dans le constructeur des buffers on rajoute le buffer dans le set de DX9Info. Et aussi dans le constructeur de copie pour que ca marche sur les buffer clonés.
Et dans le destructeur on l'enleve.
Apres un appel a deleteAllBuffers parcours le set et detruit chaque buffers dans son groupe. Un appel a Group::destroyAllBuffers détruit tout (donc aussi des buffers pas forcément directX). Du coup je peux eventuellement rajouter un Group::destroyBuffer(Buffer*) a partir de son addresse pour détruire uniquement le bon buffer. Ce sera moins rapide que le Group::destroyBuffer(string name) mais ca evite d'avoir a se trimballer le nom.

C'est plus clair la ou pas ?

[EDIT]Ah ouais mais merde lors du clone, le groupe n'est pas connu. Du coup ca va pas bien fonctionner avec la copie.
Va sans doute y avoir des trucs a changer. Les buffers ont pas été fait a la base pour être gérer en dehors des groupes.

que penses tu de ça :

on remet les buffers comme pour avant (plus de buffer spéciaux pour dx), et pour les buffers (index/vertex) dx, vu qu'ils sont directement liés à un renderer, ils seront donc gérés par eux seul.

donc plus rien n'affectera les buffers, groups, seul les renderers créeront et géreront leurs index et vertex buffers.

on devra à chaque frame faire un memcpy des buffers normaux vers les index/vertex buffers mais au moins on retrouvera une facilité de gestion pour une perte minime de performance.

on pourra à la rigueur simplifier la gestion en enregistrant les renderers dans la classe DX9Info pour avoir une gestion centralisée de la perte/destruction du device, et tout cela sans toucher au fonctionnement du moteur.

Désolé pour le delai avec lequel je répond, j'ai été pas mal occupé ces derniers temps (et ca va continuer un peu).

Pour te répondre : Ton idée d'implémentation permettrait de gérer directement les renderers plutôt que les buffers et faciliterai donc clairement l'intégration du truc. Maintenant pour moi ca pose quelques petits soucis :

• D'une part, un soucis d'ordre conceptuel : le rôle d'un renderer est de traiter des données pour les rendre utilisables par la carte graphique. Or dans ton cas, le renderer devient propriétaire des données interprétées par la carte graphique.
  
• Ensuite il y a un soucis qui touche plus a l'implémentation. Dans ta proposition tu vas utiliser un buffer unique par renderer. Sachant qu'un renderer peut très bien être partagé entre plusieurs systèmes, tu te retrouves a faire des read/write/read/write... consécutifs sur le buffer. Si tu n'es pas en mode discard sous direct3D ca va se traduire par une grosse perte de performance (car il faut attendre que le GPU ai fini d'utiliser le buffer pour écrire dedans). Si tu es en mode discard, ca devrais mieux passer, quoique je ne sois pas sur que les drivers sois optimisé pour ce genre d'utilisation.
  
• Autre problème, tu vas devoir gérer la taille du buffer dynamiquement en fonction de la taille du groupe passé au renderer. Que se passe t'il en direct3D si tu détruit un buffer pour le réallouer alors qu'il est utilisé par le GPU ? (Je n'en sais rien mais je me demande si ca ne peux pas poser des problèmes).
  
• Finalement, c'est plus un problème d'homogénisation du comportement. Si on fait comme çà pour le renderers DX9, il faudrait le faire pour tous les autres renderers. Dans le cas d'OpenGL ca peux poser porblème avec les vertex array car il n'y a pas de système de lock comme en Direct3D. L'envoie des buffers étant asyncrhone, tu peux théoriquement te retrouver à écrire dans un buffer que le GPU est en train d'utiliser.
  

Bref pour moi, garder le buffer attaché au système plutôt qu'au renderer me parait mieux. Je pense qu'il faudrait mieux revoir l'implémentation des buffers (que j'ai fait rapidement pour permettre le développement du module Irrlicht) pour pouvoir gérer leur suppression facilement a l'extérieur des groupes.

Après ta solution a du sens mais pour tous les soucis que j'expose plus haut, je serais pour remanier l'ancien système plutôt.

Le truc étant que je vais être assez occupé ces prochains jours, donc ce sera pas dans l'immédiat.