Discussion :

[LAPLACE]

Bonjour,

dans mon appli, j'ai deux parties, une qui calcule une image a partir de données et une qui va afficher l'image calculée.
Pour cela, je fais donc deux gros memcpy, le premier qui construit l'image (en fait je fais une transition entre deux images, donc l'image change a chaque frame) et le deuxieme qui copie les données construites dans la texture finale.
Cela marche très bien mais malheureusement tout cela fait énormément baisser le frame rate.
Auriez vous une idée de comment je pourrais optimiser cela ?

En gros, je créé d'abord l'image finale a partir des deux images comme ca :

memcpy(m_pResultData,pDest,iPitch*iFrame);
m_pResultData+=iPitch*iFrame;
memcpy(m_pResultData,pSource,iPitch*(m_iImageHeight - iFrame));

je retourne m_pResultData

et dans mon autre module, pour l'afficher :

memcpy(pBuffer,pData,iPitch*Desc.Height);

je mets les données dans pBuffer, qui est le buffer de la texture.

sachant que c'est des images par exemple en 512*512*4 donc ca fois deux fois ca avec les deux memcpy...

D'avance merci

[Laurent Gomila]

Il y a fort à parier que ton problème ne se résoudra pas du côté du C++, mais du côté de l'API que tu utilises. DirectX ? OpenGL ?

Parce qu'à partir du moment où tu veux copier des données, difficile de faire plus rapide que memcpy

[LAPLACE]

eh bien coté moteur 3D en fait c'est un jeu Virtools et justement niveau performances on a pas mal de problème avec, mais c'est pas forcément lié, parce que si je mets en commentaires le deuxieme memcpy (donc l'image est bien constuite mais pas affichée) ca rame aussi, meme si moins, bien sur

en gros, les deux font ramer ;p

[Laurent Gomila]

Ce que je voulais dire c'est qu'il faudra sans doute trouver une autre stratégie (s'il y en a d'autre), parce que là je ne sais pas trop ce que tu attends de nous ; si tu as un memcpy qui ralentit ton programme c'est que tu manipules beaucoup de données, je ne vois pas comment tu voudrais améliorer ça.

[Jan Rendek]

Parce qu'à partir du moment où tu veux copier des données, difficile de faire plus rapide que memcpy

Beaucoup d'applications très gourmandes en temps de calcul redéfinissent 'memcpy' en utilisant notamment des instructions de type SSE.
Le gain lorsque l'on fait du calcul intensif est conséquent. Néanmoins, à moins d'utiliser un compilo qui est capable de générer ce type de code tout seul (genre intel), il faut se l'écrire soi même, soit directement en assembleur, soit sous gcc en passant par les 'intrinsic'.
Une recherche sur Google avec 'memcpy' et 'SSE' comme mots clefs devrait permettre de récupérer le code.

[Laurent Gomila]

Le SSE c'est très bien oui, mais est-ce réellement utilisable pour accélérer une simple copie de bits ?

[Jan Rendek]

Le SSE c'est très bien oui, mais est-ce réellement utilisable pour accélérer une simple copie de bits ?

Oui, et c'est très employé.

http://www.google.fr/search?hl=fr&q=...e+Google&meta=

[Flo.]

Absoluement,

dans notre programme de traitement d'images temps réél tout les memcopy, les memset on été remplacé par des fonctions optimisées en SSE. Desassemblés, ces méthodes (memset et memcpy) n'utilisent aucune améliorations SSE (idem les std::fill et std::copy par exemple).

Les compilos n'utilisent le SSE juste pour faire des conversions (des casts) en accéléré.

L'utilisation pleine du SSE par les compilos est rendu difficile par l'obligation de parallélisation des calculs ... Il est difficile pour le compilo de savoir si dans tes opérations, les traitements des bytes ne dépendent pas des bytes calculés précédemment. Il faut une grande part d'intelligence lors de la compilation (là c'est mieux que la 1ere fois ).

C'est ce qui préoccupe énormement les développeurs de gcc en tous cas.

Faire de la copie massive de byte, word ou meme double-word ... mieux que le sse tu trouveras pas (excepté calcul carte vidéo & co) ...


Flo.

[LAPLACE]

ok, merci beaucoup, je vais essayer ca !