[MMX] Optimisation d'un code C++ -> plus lent

**Laurent Gomila** · 16/05/2006, 04h36

Bonjour

Je ne suis pas vraiment un pro des langages d'assemblage, mais récemment j'ai tenté d'optimiser un bout de code C++ critique se prétant visiblement bien à une certaine parallelisation.

Il s'agit de traiter des entiers dans une boucle 3 par 3, j'ai donc pensé que MMX me permettrait d'avoir une instruction pour 3 opérations.

Le code fonctionne très bien, cependant il est plus lent que l'original. Avez-vous une idée de ce qui peut clocher ?

Voici le code (j'utilise des fonctions intrinsèques pour le MMX, si vous voulez les instructions ASM équivalentes je peux les donner), le code original associé à chaque instruction MMX est donné en commentaire à côté. Etant donné que je ne traite que 3 entiers à la fois, le 4ème élément est simplement une copie du troisième pour garder des calculs cohérents.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
_mm_empty();
 
__m64 CYmm   = _mm_set_pi16(CY[0], CY[1], CY[2], CY[3]);
__m64 DXmm   = _mm_set_pi16(DX[0], DX[1], DX[2], DX[3]);
__m64 DYmm   = _mm_set_pi16(DY[0], DY[1], DY[2], DY[3]);
__m64 Zeromm = _mm_setzero_si64();
 
for (int y = MinY; y <= MaxY; ++y)
{
	__m64 CXmm = CYmm;
	//int CX1 = CY1;
	//int CX2 = CY2;
	//int CX3 = CY3;
 
	for (int x = MinX; x <= MaxX; ++x)
	{
		//if ((CX1 >= 0) && (CX2 >= 0) && (CX3 >= 0))
		if (_mm_movemask_pi8(_mm_cmpgt_pi16(Zeromm, CXmm)) == 0)
		{
			if (ZValue < ColorBuffer[x])
				ColorBuffer[x] = ZValue;
		}
 
		CXmm = _mm_subs_pi16(CXmm, DYmm);
		//CX1 -= DY12;
		//CX2 -= DY23;
		//CX3 -= DY31;
	}
 
	CYmm = _mm_adds_pi16(CYmm, DXmm);
	//CY1 += DX12;
	//CY2 += DX23;
	//CY3 += DX31;
 
	ColorBuffer += m_Size;
}
 
_mm_empty();

Aussi, si vous voyez des erreurs ou des choses à optimiser, n'hésitez pas, je ne connais le MMX que depuis 2 jours

Pour info, le code original en C++ est mesuré à 60 ms, le code MMX à 100 ms. La procédure de test n'est je pense pas en cause : le temps d'exécution est renvoyé par un profiler, la fonction tournant en temps réel dans un moteur 3D.

Si cela peut vous aider, je peux aussi donner le code assembleur généré par le compilo.

Merci d'avance à tous.

**wwwwwwo** · 16/05/2006, 09h30

Ce n'est pas une réflexion qui t'est destinée, elle est générale :

Oui, juste pour rigoler... envoies la purée du compilo...

si si je suis sérieux !

Le plus "amusant"

c'est que le compilateur joue à cache-cache avec toi.

Le moindre mal (mais alors vraiment, le moindre mal) serait de faire ça en INLINE

pour augmenter ta surface de maîtrise.

Le fait d'utiliser MMX n'est pas magique (je vais finir par croire que c'est une pensée commune, voir un lieu commun...) et la // pose le problème de l'entrelacement efficace : Travailler en // ne sert de rien si tu n'utilises pas le temps libre... et ça aucun VTUNE ou autre "justificateur" ne te le montrera vraiment, c'est surtout pas leur but mais de justifier l'emploi des librairires et autres boites noires payantes qui rendent de plus en plus captifs ceux qui s'y perdent...

...

Il semblerait que tu connaisses OpenGL ou/et ses équivalents maintenant intégrés dans les cartes graphiques... Pourquoi, alors, ne pas // réèllement et utiliser le matériel pour et pourquoi il est conçu ?

A croire que l'informatique c'est juste écrire du code (pour pas dire de l'ASCII confié au dieu (plus l'esclave, puisque personne ne regarde ce qu'il fait rééllement !) compilator :

Pas de machine, pas de code... C'est la machine qui conditionne le code, pas le contraire et la portabilité est une paresse couteuse dans ces temps de Intel Only et de WDM...

En un mot : La stratégie n'est pas bonne (Je persiste et signe : Elle est un égarement, signe de l'incompréhension actuel des codeurs en général). Pourtant, il sera difficile d'en faire le reproche à M$ qui met (certes discrètement) tout sous les yeux du lecteur de doc attentif.

**Laurent Gomila** · 16/05/2006, 15h20

Oui, juste pour rigoler... envoies la purée du compilo... si si je suis sérieux !

Ok, je posterai le code généré demain matin (il est au boulot).

Le plus "amusant" c'est que le compilateur joue à cache-cache avec toi.

C'est-à-dire ?

Le moindre mal (mais alors vraiment, le moindre mal) serait de faire ça en INLINE pour augmenter ta surface de maîtrise.

C'est possible effectivement, mais ce sera un peu plus laborieux pour moi qui ne maîtrise pas l'ASM. Tu peux me dire en quoi cela améliorerait le schmilblick ?

Le fait d'utiliser MMX n'est pas magique (je vais finir par croire que c'est une pensée commune, voir un lieu commun...) et la // pose le problème de l'entrelacement efficace : Travailler en // ne sert de rien si tu n'utilises pas le temps libre... et ça aucun VTUNE ou autre "justificateur" ne te le montrera vraiment, c'est surtout pas leur but mais de justifier l'emploi des librairires et autres boites noires payantes qui rendent de plus en plus captifs ceux qui s'y perdent...

Certes, mais je suis juste parti du constat, a priori simple, que si je remplace mes triplets d'instructions par une seule MMX, il y aura forcément un gain quelque part. Je ne cherche pas forcément à mettre en place une architecture pour paralléliser au mieux mon code, seulement à réduire le nombre d'instructions de ce petit morceau.
Si ce n'est pas magique, j'aimerais un peu plus d'éclaircissements. C'était le but de mon post : savoir pourquoi c'était plus lent, alors que je m'attends au contraire.

Il semblerait que tu connaisses OpenGL ou/et ses équivalents maintenant intégrés dans les cartes graphiques... Pourquoi, alors, ne pas // réèllement et utiliser le matériel pour et pourquoi il est conçu ?

[...]

Il me semble que tu pars quelque peu en sucette là... Quoiqu'il en soit je ne suis pas sûr d'avoir compris la subtilité du message, cependant si tu veux parler parrallélisme on peut en parler, c'est justement la clé de l'algorithme dont est extrait ce bout de code.

En gros, il s'agit du coeur d'un rasterizer de triangles simplifié, qui tourne sur le CPU pendant que la carte graphique est occupée à rendre la scène à l'écran. Ainsi si j'arrive à optimiser (entre autre) ce bout de code, via MMX ou autre, j'aurais un algorithme qui s'exécute gratuitement ; pour le moment ce n'est pas tout à fait le cas, le GPU se tourne encore un peu les pouces en attendant la fin de ma rasterization.

Si cela te paraît toujours une mauvaise stratégie je suis prêt à écouter tes lumières.

**wwwwwwo** · 16/05/2006, 16h29

- Je pense que cela sera instructif pour plusieurs de jeter un coup d'oeil au code réel. De faire la différence entre intention ASCII et réalité code.

C'est dans cet esprit que je parle de cache cache...

Le INLINE (comme vraiment moindre mal minimum) t'éviterais de laisser la main au compilo qui gère très mal les registres la pile etc. car il ne comprends pas la stratégie globale que tu souhaite mettre en oeuvre et utilise des principes beaucoup trop "raides" d'optimisation qui deviennent absurdes par leur utilisation hors contexte... (je constate ça toutes les heures).

Mais je maintiens (si le post est bien sur un forum ASM) que l'INLINE est tributaire du compilo et du conxtexte stratégique donc : Moindre, moindre mal...

Pour MMX, il manque une gigogne de //. Pendant que MMX travaille et que les GPU/DVP travaillent que fait le CPU... Un petit problème de synchro et l'avantage visé devient un defaut, ce le cas du code présenté. FPU pose le même problème... wait... wait... wait... (si tu veux on monte un groupe

). La gratuité envisagée à un coût sur le coup

qu'il va être difficile de régler efficacement avec un HLL (j'y reviendrais plus loin).

...le GPU se tourne les pouces en attendant... Plains-toi ça pourrait-être le contraire

Donc, le baton est toujours à l'intérieur de la sucette : OpenGniaGnia ou DirectGnionGnion sont maintenant, (via WDM etc. désolé d'enfoncer des portes ouvertes avec des lieux-communs que tu connais par coeur, mais certains lecteurs pourront recadrer les enjeux stratégiques) "intégrés" dans nos carte graphiques. Pour un HLL cela veut dire transcodage opaque de ton code ASCII initial : Il est largement reformulé pour obtenir un code compatible avec des technologies natives (cela est transparent pour des questions de gros sous et de paresse fond de commerce mais la triste réalité est là...). Même le noyau c'est vu enrichi (il a doublé de taille sous XP64) de partie descendues en ASM pour récupérer les perf manquantes et supprimer toute une série de mécanismes lourds, obsolètes, situés au mauvais endroit et ne disposant pas des priorités necessaires... (ça permet aussi de protéger le commerce des outils sans fins...)

La // des cartes via PCI express (deux cartes graphique qui partagent dynamiquement les ressources etc.) l'accès direct au flux sans utilisation DMA (KS)... Le but de tout ça c'est de // effectivement, mais pas de synchroniser ! (heureusement)
Il n'est pas possible de // deux traitements interdépendants et partageant un contexte, sans pertes en vitesse (l'echec basique du multitâches)...

Donc, vouloir "gruger" le compilo en lui machant le boulot, c'est tenter d'essayer de le faire sortir de son contexte et de sa logique de travail (Si tu n'utilises aucune librairie Direct Blabla peut-être (et encore, je te défie de savoir ce qui est réèllement dans ton code

)).

Il me semble qu'une partie basse est dédiée à ce genre de boulot (sinon pourquoi s'ennuyer à court-cicuiter DMA, déplacer le code natif du coté des DSP/DVP...) comme ça tu peu utiliser le CPU pour garder la bière au frais... Mais bon, tu es très au fait de tout ça, je veux pas te prendre la tête...

Pour faire simple : En C/C++ tu ne pourras jamais (mais alors,vraiment jamais) optimiser ton truc proprement et les bidouilles "infâmes" que tu devras utiliser seront renversées par la prochaîne librairie / dll qui tombera de l'arbre... Sacrée portabilité

.

Ceci dit un petit tour du coté de chez DDK ou, par exemple, comme je le proposait à quelqu'un peiné de n'y trouver que du C et pas de l'ASM GDC2003_VideoShader.pdf (en fait, lire entre les lignes

)
Désolé donc, pour la subtilité du message, c'est tout moi ça... sub-tilt

Bon code et bravo pour tout le boulot déjà accompli et proposé sur ton site.

**Laurent Gomila** · 16/05/2006, 17h00

Le INLINE (comme vraiment moindre mal minimum) t'éviterais de laisser la main au compilo qui gère très mal les registres la pile etc. car il ne comprends pas la stratégie globale que tu souhaite mettre en oeuvre et utilise des principes beaucoup trop "raides" d'optimisation qui deviennent absurdes par leur utilisation hors contexte... (je constate ça toutes les heures).

Ok, je crois comprendre ce que tu veux dire. Par exemple, j'ai regroupé certaines variables dans un tableau afin qu'elles soient contigües en mémoire, en pensant que ça allait simplifier leur placement dans un registre MMX. En observant le code ASM généré, j'ai l'impression que le compilo me les recopie tout de même ailleurs avant d'appeler le MOVQ correspondant.

Pour MMX, il manque une gigogne de //. Pendant que MMX travaille et que les GPU/VSP travaillent que fait le CPU... Un petit problème de synchro et l'avantage visé devient un defaut, ce le cas du code présenté. FPU pose le même problème... wait... wait... wait... (si tu veux on monte un groupe ). La gratuité envisagée à un coût sur le coup qu'il va être difficile de régler efficacement avec un HLL (j'y reviendrais plus loin).

Mais MMX, c'est justement le CPU non ? Que pourrais-je lui faire faire en même temps que mes instructions MMX ? Pas des calculs sur flottants visiblement, puisque MMX utilise les registres des flottants. Et cela voudrait donc dire que l'utilisation du MMX est intrinsèquement plus "lente" que le code normal (si mal parallèlisé), même si ça génère moins d'instructions ?

Ensuite j'ai un peu perdu le fil de ton explication, mais j'imagine que c'est en partie dû au fait que j'ignore ce qu'est un HLL

Sinon tu parles toujours de GPU et de VSP, mais j'ai du mal à voir le rapport avec mon problème.

Pour faire simple : En C/C++ tu ne pourras jamais (mais alors,vraiment jamais) optimiser ton truc proprement et les bidouilles "infâmes" que tu devras utiliser seront renversées par la prochaîne librairie / dll qui tombera de l'arbre... Sacrée portabilité .

Pourtant, toutes les personnes qui ont dû écrire un rasterizer software en C++, l'ont bien optimisé avec du MMX et du SSE. Et le gain constaté est conforme aux attentes naïves que l'on peut avoir : x2 pour les parties MMX, et x4 pour les parties SSE (grosso modo). Et le principe n'était pas compliqué : il s'agissait de regrouper des traitements identiques par 2 ou 4 dans des registres MMX / SSE, et de les balancer en parallèle sur le GPU.
Donc, pourquoi pas moi ? Comment faire ?

**wwwwwwo** · 16/05/2006, 18h26

Mais MMX, c'est justement le CPU non ? Que pourrais-je lui faire faire en même temps que mes instructions MMX ? Pas des calculs sur flottants visiblement, puisque MMX utilise les registres des flottants. Et cela voudrait donc dire que l'utilisation du MMX est intrinsèquement plus "lente" que le code normal (si mal parallèlisé), même si ça génère moins d'instructions ?

Si MMX et son pote verlent utilise F(PU) cela veut dire que tout ça c'est du co-process, donc... wait... (tu sais l'instruction FPU qui fait mal là où ça fait du bien, enfin un truc différent du Synthol

)

De plus, le code le plus court n'est pas toujours le plus rapide loin s'en faut ! Par contre, ne pas le faire va plus vite : Oui.

Ensuite j'ai un peu perdu le fil de ton explication, mais j'imagine que c'est en partie dû au fait que j'ignore ce qu'est un HLL

Humour suite : Pour générer du code machine tu peux utiliser soit un compilateur (Hight Level Language) soit un assembleur...
Dans l'un tu fais de l'ASCII et tu espères très fort que le compilo (et tous ses occultes copînes) va être sympa et faire pleins de choses que tu veux ignorer, pour que ça tourne...

Dans l'autre cas, avec un bon outil, ce que tu écrits c'est ce qui sera (tu sais à qui la faute

).

Sinon tu parles toujours de GPU et de DVP, mais j'ai du mal à voir le rapport avec mon problème.

Ben c'est le DVP qui fait le boulo, normalement, cad : Pas seulement afficher un écran calculé par le CPU (ce qui serait désastreusement lent... mais y encore des fondus de l'ASM 16 bits pour travailler comme ça, je te rassure... enfin, si ça rassure quelqu'un

)
Le CPU ne fait qu'initialiser le code de celui-ci (l'automate) par moteurs interposés (m'enfin je t'apprends rien). La carte stocke tes données mais aussi tes "traitements". C'est le pôvre CPU qui va s'ennuyer (remarques, si tu veux surveiller le pointeur...).

COM devrait aussi pas mal t'aider... mais chut...on nous écoute...

et j'aimerais pas donner des idées

Pourtant, toutes les personnes qui ont dû écrire un rasterizer software en C++, l'ont bien optimisé avec du MMX et du SSE. Et le gain constaté est conforme aux attentes naïves que l'on peut avoir : x2 pour les parties MMX, et x4 pour les parties SSE (grosso modo). Et le principe n'était pas compliqué : il s'agissait de regrouper des traitements identiques par 2 ou 4 dans des registres MMX / SSE, et de les balancer en parallèle sur le GPU.
Donc, pourquoi pas moi ? Comment faire ?

Je pense que le "pourquoi pas moi" n'est pas seulement une réplique piquée qu'au qu'Ali amère héros... Si tu n'obtiens pas le résultats c'est que :

- Tu ne compares peut-être pas la même chose opu de la même manière.

- Les dites comparaisons sont visibles où, histoire de vérifier ? (je ne nommerai pas certains jeux bien connus, écrits entièrement en ASM, qui ne tirent pas leurs performances d'un compilo ou d'une mise en commun de travaille // ...

- Pour balancer en // au GPU... Je serais curieux de savoir par quel buss PCI express tu passes

... Surtout qu'il faut "sortir" du coprocess et ensuite demander au CPU de causer à DMA qui voudront bien bouger leurs fesses pour ton code qui va se retrouver à la bourre là où il est attendu par sa maman si ça continue à ce faire des coucous, c'est moi, t'es libre, t'es où, tu fais quoi (heureusement les portables sont éteinds dans les buss)...

- D'où tiens-tu tes chiffres ? As-tu comparé le code ? Ou est-ce encore un délire d'illustre inconnu sans code comparé ? (ça devient la plus sale habitude que je connaise en ces temps d'intox rempantes).

- Si tu veux obtenir le maximum de résultats en optimisant sérieusement ta stratégie (tu as compris que tu ne peux pas macher le boulot au compilo qui fait qu'askyveu et qui comprend rien à rien si ce n'est que " n'importe comment les perfs c'est plus le code, c'est la machine, elles sont tellement puissantes qu'on a plus besoin de l'ASM

ben voyons... elle est rigolote celle-là en plus d'être complètement absurde dans le principe même !!!)
Le seul et unique moyen sérieux c'est de tout coder en ASM (ou pourquoi pas une dll si vraiment tu as encore des doutes ou simplement un peu la trouille...). De tout loger dans les différentes cartes de traitement et de // des process indépendants le tout en mode kernel.
Je pense qu'après ça tes copains, et toi aussi j'espère, pleureront devant les perfs et que la taille de ton code devrait-être divisé par 1/10000 (l'exemple de lecteur multidémia proposé dans un autre poste (8Ko) en est une bien pâle illustration. http://www.developpez.net/forums/sho...d.php?t=145351 )

bon code

**Laurent Gomila** · 16/05/2006, 19h28

Si MMX et son pote verlent utilise F(PU) cela veut dire que tout ça c'est du co-process, donc... wait... (tu sais l'instruction FPU qui fait mal là où ça fait du bien, enfin un truc différent du Synthol )

Très honêtement, si tu parlais parfois au premier degré, en allant droit au but, je te comprendrais mieux

Dans l'autre cas, avec un bon outil, ce que tu écrits c'est ce qui sera

Bon, j'en déduis que je dois me taper un morceau entier d'assembleur, et éviter de simplement insérer des intrinsics MMX comme je le fais. Ca me paraît effectivement une bonne idée.

Ben c'est le VSP qui fait le boulo, normalement

Mais quel VSP ? Et puis je ne veux pas faire de traitement d'image, je veux stocker la profondeur de triangles 3D (transformés en 2D donc) dans un tableau d'entiers. Plus d'explications (et pareil, droit au but please

) sur ce sujet m'intéresseraient.

- Tu ne compares peut-être pas la même chose opu de la même manière

Les comparaisons sont souvent du type "mon code en C++ vs. le même optimisé MMX / SSE". Au moins ça va droit au but.

- Les dites comparaisons sont visibles où, histoire de vérifier ? (je ne nommerai pas certains jeux bien connus, écrits entièrement en ASM, qui ne tirent pas leurs performances d'un compilo ou d'une mise en commun de travaille // ...

Dans les divers sujets de forum dans lesquels j'ai trouvé de l'information pour mon algorithme. Je n'en n'ai pas sous la main, mais si j'en retrouve je donnerai les liens. Le mec duquel je m'inspire pour ma rasterization, et qui dit toujours gagner en perfs avec MMX / SSE, est Nicolas Capens, qui a écrit (je ne sais pas si tu connais) swShaders

- Pour balancer en // au GPU... Je serais curieux de savoir par quel buss PCI express tu passes ... Surtout qu'il faut "sortir" du coprocess et ensuite demander au CPU de causer à DMA qui voudront bien bouger leurs fesses pour ton code qui va se retrouver à la bourre là où il est attendu par sa maman si ça continue à ce faire des coucous, c'est moi, t'es libre, t'es où, tu fais quoi (heureusement les portables sont éteinds dans les buss)...

Je n'ai pas tout compris, mais le parallelisme avec le GPU est géré plus ou moins tout seul.

- D'où tiens-tu tes chiffres ? As-tu comparé le code ? Ou est-ce encore un délire d'illustre inconnu sans code comparé ? (ça devient la plus sale habitude que je connaise en ces temps d'intox rempantes).

Comme je te l'ai dit ce ne sont que des propos tenus sur des forums, mais comme je l'ai dit aussi, leurs auteurs sont loin d'être des rigolos.

De tout loger dans les différentes cartes de traitement et de // des process indépendants le tout en mode kernel.

Comme d'hab : quelles cartes de traitement ? Et puis c'est quand même très spécifique ce que je souhaite faire.

**wwwwwwo** · 16/05/2006, 20h18

Si MMX utilise F(ProUnit) cela veut dire que tout ça c'est du co-process, donc... wait (instruction FPU servant à faire poireauter le CPU en attendant la fin du calcul). Calculer en // avec FPU ... pourquoi pas... pour gagner en vitesse ben...

Tu demandes à ta carte graphique d'afficher un contenu calculé et transmis par le CPU...

Ben la carte sait calculer et afficher comme une grande sans attendre qu'un copain lent comme le CPU (même via MMX) daigne bien faire le boulot à sa place...
Ce que tu appelles du traitement d'image c'est, par exemple, ce que fait une fonction (pour prendre un exemple ultra basic) comme Bitblt et tous ses dérivés (la les calculs sont plutôt simples, masques, étirements, transparences, rotations) à patir et dans la RAM de la carte graphique. Le même problème navrant est constaté par tous les gus qui veulent rivaliser avec Bitblt via MMx pour faire de la copie de blocs... ils comprennent pas d'où vient le problème... localité quand tu nous tiens...
Donc -> la carte graphique qui est dans ton PC de compétiton sait faire ce que tu fais avec le CPU (plus direct, c'est la vision unitaire de l'univers

)

Comparer son code au sien, certes, comment ? vu que tout ça est // dans tous les sens, la seule comparaison possible est de compter le nombre de frames (et encore la méthode utilisée peut t'amener à des conclusions complètement erronées...).

Je n'ai pas tout compris, mais le parallelisme avec le GPU est géré plus ou moins tout seul.

Naturellement méchant, le wwwwwwo pourrait taper là où ça fait mal mais bon... faute avouée, travail de romain pardonné

Tout seul veut dire : Je sais pas et je suis content comme ça... ben pas moi... mais alors pas du tout... et puis toi non plus finalement ou je me gourre

?

Comme je te l'ai dit ce ne sont que des propos tenus sur des forums, mais comme je l'ai dit aussi, leurs auteurs sont loin d'être des rigolos.

C'est quoi un forum, un lieu libre d'intox ? (Tu veux parler de la liscense de MASM

? ça risque de péter très fort... surtout sur un forum

)

Pas besoin d'être super sérieux pour se faire promener par des gars qui écrivent en C++ et qui parlent electronique... Ron Kupper (pas un triste non plus) à bien soutenu M$ dans son intox Direct KS (je me suis laisser avoir avant de vérifier... et ça fait un peu mal de voir que ces gars là sont des industriels (on ne peut plus "pas rigolos" qui protègent ceux qui protègent machin BG qui les tiens pas les cpu (flottants)

qui à des gus "pas des rigolos non plus" qui developpent un OS qu'ils ne connaissent pas, sinon ils raconteraient pas les inepties qu'ils racontent sur des forums agréés M$ quand tu parles un peu sérieusement... Je te promets, c'est effarant : ils ne mentent pas (dans la durée c'est pas possible) ils savent pas, c'est tout, c'est aussi simple que ça et ils pensent qu'ils connaissent la boite pour laquelle ils bossent (quand tu parles des points d'entrées dans toute application générée avec VC++ net (WC net en fait) ils tombent de nues et découvrent la guerre... ils sont pas mignons

... ???

De tout loger dans les différentes cartes de traitement et de // des process indépendants le tout en mode kernel.

Comme d'hab : quelles cartes de traitement ? Et puis c'est quand même très spécifique ce que je souhaite faire.

Ben... la carte graphique.

Très spécifique, avec tout le respect que je te dois et que je te porte (si si... sinon j'arrêterais pas de coder pour répondre) c'est ce pourquoi on à construit les coprocess graphiques et leurs armées de DVP et d'algos intégrées... Y'a plus qu'à lire la doc (electronique, WDM... chez ATI ils demandent que ça

).

Dernière minute : Je viens de regarder en 2 minutes la page indiquée : Tout est fait, comme d'hab, via Direct tagazou, donc dans la carte. Les articles parcourus en diagonal parlent tous d'API utlisant vertex and co (tout ça c'est hard...).

At the developer level, SwiftShader presents a familiar API, providing application developers with a drop-in D3D8 or D3D9 DLL file. The SwiftShader D3D DLLs provide the same COM-based APIs that Direct3D applications expect, making them binary compatible with existing applications. Most applications can be tested with SwiftShader by simply moving the SwiftShader D3D8 or D3D9 DLL into the same directory as the application. SwiftShader will provide an OpenGL-compatible interface in the future so that OpenGL applications can also make use of high performance software rendering.

Tiens tiens COM... quant à high performance software rendering ça c'est l'intox -> Les API qui appellent des DLL ou des objets COM utilisent le hard mais celui de ta carte graphique (sinon quel interêt et quelle logique dans toutes la prose à l'entour...) Ou alors, cela veut dire que M$ bosse de plus en plus ses softs pour accéler le matos

d'ailleurs la XBox en est une super application re

En fait WDM est le moyen pour M$ d'augmenter ses performances sans bosser mais en déportant la charge de travail sur les industriels et leurs cartes (ce qui est la démarche "logique" de toutes les logiques programmables si j'ai bien compris mon job...).

**Laurent Gomila** · 17/05/2006, 03h14

En fait je crois qu'on s'est mal compris : je ne demande pas à mon CPU de calculer une image qui sera envoyée ensuite au GPU.

Mon algo consiste à rendre des occluders (seulement leur profondeur) dans une surface en mémoire système, et ensuite à tester les objets de la scène avec cette surface pour savoir si oui ou non ils sont cachés ou non.

Et je ne peux pas utiliser le GPU, puisque je fais justement ce traitement pendant qu'il affiche la "vraie" scène à l'écran.

Donc je ne souhaite pas émuler une fonctionnalité du hardware pour le remplacer en espérant être plus rapide (ce serait bien naïf de le penser), juste faire mon calcul d'occlusion (pour la frame suivante) pendant que la scène est affichée.

L'algorithme à la base utilise bien le GPU d'ailleurs, mais étant donné que cela n'exploite aucun parallelisme, cette approche est moins bonne que la mienne ; comme je l'ai dit si j'arrive à avoir un rasterizer software optimisé je pourrai faire ce calcul totalement gratuitement.

Tout seul veut dire : Je sais pas et je suis content comme ça... ben pas moi... mais alors pas du tout... et puis toi non plus finalement ou je me gourre ?

Je n'ai pas voulu m'étendre sur ce point, mais puisque tu es soucieux des détails... Lorsque l'on envoie des primitives à traiter à la carte graphique (fonctions DrawPrimitive avec DirectX), la fonction rend la main tout de suite et l'on peut faire autre chose avec le CPU pendant que le GPU s'occupe de nos triangles.
Ainsi pour paralleliser CPU et GPU, il suffit de mettre notre code au bon endroit, à savoir juste après l'envoi de toute la scène au GPU.
Il faut également veiller à ne pas casser le pipeline d'exécution du GPU (des transferts VRAM -> SRAM par exemple), ce qui resynchroniserait GPU et CPU et perdrait tout parrallelisme.

C'est quoi un forum, un lieu libre d'intox ?

Faut pas être si pessimiste, il y a des forums sérieux sur lesquels des gens sérieux prennent la parole. Si on commence à penser de cette manière, alors je dois douter de tes réponses aussi ?

Dernière minute : Je viens de regarder en 2 minutes la page indiquée : Tout est fait, comme d'hab, via Direct tagazou, donc dans la carte. Les articles parcourus en diagonal parlent tous d'API utlisant vertex and co (tout ça c'est hard...).

Tu devrais regarder plus de deux minutes

Ce projet est un moteur de rendu 100% software, qui peut émuler 100% des fonctionnalités de Direct3D avec le CPU. Rien ne passe pas le hardware.
Ce qui t'a peut-être induit en confusion, c'est que des DLLs DirectX modifiées sont fournies, pour pouvoir tester le moteur de rendu sur des exécutables compilés pour DirectX, de manière totalement transparente.

**Laurent Gomila** · 17/05/2006, 03h53

Voici le code ASM généré par le compilo. On peut voir notamment qu'il a réarrangé les lignes de code (on voit des bouts de code qui ne se trouvent pas dans mon premier post ; elles se trouvent juste avant dans la fonction), je ne sais pas trop dans quel but.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
; 394  : 	_mm_empty();
 
	mov	edx, DWORD PTR [esi+16]
	mov	esi, DWORD PTR [esi+4]
	imul	edx, ecx
	mov	esi, DWORD PTR [esi+4]
	lea	edx, DWORD PTR [esi+edx*4]
	mov	ebx, DWORD PTR _MinX$[esp+480]
	imul	ebx, DWORD PTR _DY$[esp+480]
	mov	DWORD PTR _ColorBuffer$[esp+480], edx
	mov	edx, DWORD PTR tv667[esp+480]
	imul	edx, DWORD PTR _X3$[esp+480]
	mov	esi, edi
	imul	esi, eax
	sub	edx, esi
	mov	esi, DWORD PTR _DX$[esp+480]
	mov	eax, ecx
	imul	eax, esi
	imul	esi, DWORD PTR _Y1$[esp+480]
	sub	eax, ebx
	mov	ebx, DWORD PTR _MinX$[esp+480]
	imul	ebx, DWORD PTR _DY$[esp+484]
	sub	eax, esi
	mov	esi, DWORD PTR _DY$[esp+480]
	imul	esi, DWORD PTR _X1$[esp+480]
	add	eax, esi
	mov	esi, DWORD PTR _DX$[esp+484]
	imul	ecx, esi
	imul	esi, DWORD PTR _Y2$[esp+480]
	sub	ecx, ebx
	mov	ebx, DWORD PTR _MinX$[esp+480]
	imul	ebx, DWORD PTR tv667[esp+480]
	sub	ecx, esi
	mov	esi, DWORD PTR _DY$[esp+484]
	imul	esi, DWORD PTR _X2$[esp+480]
	add	ecx, esi
	mov	esi, DWORD PTR _MinY$[esp+480]
	imul	esi, edi
	sub	esi, ebx
	mov	ebx, DWORD PTR _MinX$[esp+480]
	imul	ebx, DWORD PTR tv667[esp+480]
	add	esi, edx
	mov	DWORD PTR _CY$[esp+488], esi
	mov	esi, DWORD PTR _MinY$[esp+480]
	imul	esi, edi
	sub	esi, ebx
	add	esi, edx
	emms
	mov	dx, WORD PTR _CY$[esp+488]
	mov	WORD PTR tv768[esp+486], ax
	mov	ax, WORD PTR _DX$[esp+484]
	mov	WORD PTR tv768[esp+484], cx
	mov	cx, WORD PTR _DX$[esp+480]
	mov	WORD PTR tv768[esp+482], dx
	mov	dx, WORD PTR _DY$[esp+484]
	mov	WORD PTR tv768[esp+480], si
	movq	mm1, MMWORD PTR tv768[esp+480]
	mov	WORD PTR tv763[esp+484], ax
	mov	eax, DWORD PTR tv667[esp+480]
	mov	WORD PTR tv763[esp+486], cx
	mov	ecx, DWORD PTR _MinY$[esp+480]
	mov	WORD PTR tv763[esp+480], di
	mov	WORD PTR tv763[esp+482], di
	movq	mm4, MMWORD PTR tv763[esp+480]
	mov	WORD PTR tv758[esp+480], ax
	mov	WORD PTR tv758[esp+482], ax
	mov	ax, WORD PTR _DY$[esp+480]
	mov	WORD PTR tv758[esp+486], ax
	mov	eax, DWORD PTR _MaxY$[esp+480]
	cmp	ecx, eax
	mov	WORD PTR tv758[esp+484], dx
	movq	mm2, MMWORD PTR tv758[esp+480]
	pxor	mm3, mm3
	jg	SHORT $L19403
	mov	edi, DWORD PTR _MinX$[esp+480]
	mov	edx, DWORD PTR _ZValue$[esp+480]
	mov	esi, DWORD PTR _MaxX$[esp+480]
	sub	eax, ecx
	mov	ecx, DWORD PTR _ColorBuffer$[esp+480]
	inc	eax
	mov	DWORD PTR tv575[esp+480], eax
$L16453:
	cmp	edi, esi
	movq	mm0, mm1
	mov	eax, edi
	jg	SHORT $L16460
	npad	2
$L16458:
 
; 372  : 		{
; 373  : 			//if ((CX1 >= 0) && (CX2 >= 0) && (CX3 >= 0))
; 374  : 			if (!_mm_movemask_pi8(_mm_cmpgt_pi16(Zeromm, CXmm)))
 
	movq	mm5, mm3
	pcmpgtw	mm5, mm0
	pmovmskb ebx, mm5
	test	ebx, ebx
	jne	SHORT $L16463
 
; 375  : 			{
; 376  : 				if (ZValue < ColorBuffer[x])
 
	cmp	edx, DWORD PTR [ecx+eax*4]
	jae	SHORT $L16463
 
; 377  : 					ColorBuffer[x] = ZValue;
 
	mov	DWORD PTR [ecx+eax*4], edx
$L16463:
 
; 339  : 
; 340  : 	// Go to the first pixel to test
; 341  : 	uint32* ColorBuffer = m_Maps[0].GetArray();
; 342  : 	ColorBuffer += MinY * m_Size;
; 343  : 
; 344  : 	// Half-edge constants
; 345  : 	int C1 = DY[0] * X1 - DX[0] * Y1;
; 346  : 	int C2 = DY[1] * X2 - DX[1] * Y2;
; 347  : 	int C3 = DY[2] * X3 - DX[2] * Y3;
; 348  : 
; 349  : 	int CY[] =
; 350  : 	{
; 351  : 			C1 + DX[0] * MinY - DY[0] * MinX,
; 352  : 			C2 + DX[1] * MinY - DY[1] * MinX,
; 353  : 			C3 + DX[2] * MinY - DY[2] * MinX,
; 354  : 			C3 + DX[3] * MinY - DY[3] * MinX
; 355  : 	};
; 356  : 
; 357  : 	_mm_empty();
; 358  : 
; 359  : 	__m64 CYmm   = _mm_set_pi16(CY[0], CY[1], CY[2], CY[3]);
; 360  : 	__m64 DXmm   = _mm_set_pi16(DX[0], DX[1], DX[2], DX[3]);
; 361  : 	__m64 DYmm   = _mm_set_pi16(DY[0], DY[1], DY[2], DY[3]);
; 362  : 	__m64 Zeromm = _mm_setzero_si64();
; 363  : 
; 364  : 	for (int y = MinY; y <= MaxY; ++y)
; 365  : 	{
; 366  : 		__m64 CXmm = CYmm;
; 367  : 		//int CX1 = CY[0];
; 368  : 		//int CX2 = CY[1];
; 369  : 		//int CX3 = CY[2];
; 370  : 
; 371  : 		for (int x = MinX; x <= MaxX; ++x)
 
	inc	eax
	cmp	eax, esi
 
; 378  : 			}
; 379  : 
; 380  : 			CXmm = _mm_subs_pi16(CXmm, DYmm);
 
	psubsw	mm0, mm2
	jle	SHORT $L16458
$L16460:
 
; 381  : 			//CX1 -= DY[0];
; 382  : 			//CX2 -= DY[1];
; 383  : 			//CX3 -= DY[2];
; 384  : 		}
; 385  : 
; 386  : 		CYmm = _mm_adds_pi16(CYmm, DXmm);
; 387  : 		//CY[0] += DX[0];
; 388  : 		//CY[1] += DX[1];
; 389  : 		//CY[2] += DX[2];
; 390  : 
; 391  : 		ColorBuffer += m_Size;
 
	mov	eax, DWORD PTR _this$[esp+480]
	mov	eax, DWORD PTR [eax+16]
	lea	ecx, DWORD PTR [ecx+eax*4]
	mov	eax, DWORD PTR tv575[esp+480]
	dec	eax
	paddsw	mm1, mm4
	mov	DWORD PTR tv575[esp+480], eax
	jne	SHORT $L16453
$L19403:
 
; 392  : 	}
; 393  : 
; 394  : 	_mm_empty();
 
	emms
 
; 395  : }

**wwwwwwo** · 17/05/2006, 09h32

En fait je crois qu'on s'est mal compris : je ne demande pas à mon CPU de calculer une image qui sera envoyée ensuite au GPU.

Mon algo consiste ... pendant que la scène est affichée.

Oui, c'est bien de cela dont nous parlons depuis le debut.

L'algorithme à la base utilise bien le GPU d'ailleurs, mais étant donné que cela n'exploite aucun parallelisme, cette approche est moins bonne que la mienne ; comme je l'ai dit si j'arrive à avoir un rasterizer software optimisé je pourrai faire ce calcul totalement gratuitement.

non

(la gratuité dont tu parles est couteuse aujourd'hui)

Lorsque l'on envoie des primitives à traiter à la carte graphique (fonctions DrawPrimitive avec DirectX), la fonction rend la main tout de suite et l'on peut faire autre chose avec le CPU pendant que le GPU s'occupe de nos triangles.

Ce qui se faisait avec un ATARI (depuis que les cartes graphiques existent indépendament du CPU, la forme change, certes, mais le principe reste le même, on ne va pas reprendre le Zen de MA

).
Seulement, les cartes // elles mêmes (je ne parle pas ici de deux cartes via PCI express mais de l'évolution de leurs architectures internes) et les mécanismes utilisés par les Direct... sont de plus en plus élargis pour libérer le CPU d'un travail non seulement coûteux pour lui mais aussi pour limiter le débit des flux communs (libérer de la BP sur les buss).

Ainsi pour paralleliser CPU et GPU, il suffit de mettre notre code au bon endroit, à savoir juste après l'envoi de toute la scène au GPU.
Il faut également veiller à ne pas casser le pipeline d'exécution du GPU (des transferts VRAM -> SRAM par exemple), ce qui resynchroniserait GPU et CPU et perdrait tout parrallelisme.

cqfd

C'est quoi un forum, un lieu libre d'intox ?

Faut pas être si pessimiste, il y a des forums sérieux sur lesquels des gens sérieux prennent la parole. Si on commence à penser de cette manière, alors je dois douter de tes réponses aussi ?

Evidement

La vérification de l'info étant de ta responsabilté, pas de pessimisme ici, juste du bon sens. Le sérieux n'est en aucun cas gage de vérité : Il y a des interlocuteurs qui sont sérieusement à coté de la plaque en toute bonne foi (c'était l'exemple des gars de chez Croque$oft...).

Ce projet est un moteur de rendu 100% software, qui peut émuler 100% des fonctionnalités de Direct3D avec le CPU. Rien ne passe pas le hardware.
Ce qui t'a peut-être induit en confusion, c'est que des DLLs DirectX modifiées sont fournies, pour pouvoir tester le moteur de rendu sur des exécutables compilés pour DirectX, de manière totalement transparente.

Cool, le code tourne plus vite que le hard

-> Il suffit de le déplacer dans le CPU et de travailler en même temps à deux endroits différents et de transmettre les données au bon moment... je comprends bien l'intention...

La carte sait faire ça sans béquilles mais je n'insisterai pas.

Voici le code ASM généré par le compilo. On peut voir notamment qu'il a réarrangé les lignes de code (on voit des bouts de code qui ne se trouvent pas dans mon premier post ; elles se trouvent juste avant dans la fonction), je ne sais pas trop dans quel but

C'est pour cela que je te proposais de ré-écrire tout-ça en inline (le minimum syndical) tu pourrais de cette manière tenter de situer le problème de code/synchro.

bon code.

**Laurent Gomila** · 17/05/2006, 18h09

Oui, c'est bien de cela dont nous parlons depuis le debut.

Alors je ne comprends pas pourquoi tu me parles sans cesse de GPU et de VSP. L'intérêt est d'utiliser la ressource disponible à un moment donné, et la ressource disponible c'est le CPU.

non (la gratuité dont tu parles est couteuse aujourd'hui)

Là encore je ne comprends pas. La gratuité dont je te parle est assez logique, et c'est d'ailleurs un fait constaté ; pour des grosses scènes et des petits occluders ça ne me coûte pas un copec à l'exécution. Pour avoir des occluders plus chargés tout en gardant un truc gratos, j'ai donc besoin d'améliorer le temps d'exécution en optimisant ma fonction.
Mais je me répète là...

Evidement La vérification de l'info étant de ta responsabilté, pas de pessimisme ici, juste du bon sens. Le sérieux n'est en aucun cas gage de vérité : Il y a des interlocuteurs qui sont sérieusement à coté de la plaque en toute bonne foi (c'était l'exemple des gars de chez Croque$oft...).

J'ai testé SwiftShaders : c'est réellement très rapide.
CQFD

C'est pour cela que je te proposais de ré-écrire tout-ça en inline (le minimum syndical) tu pourrais de cette manière tenter de situer le problème de code/synchro.

C'est ce que j'ai fait (peut-être mal, mais je ne peux pas faire mieux actuellement), aucun gain constaté. De plus j'ai vu par exemple que l'instruction EMMS mangeait déjà 50 cycles à elle seule, ça ne motive pas trop... J'ai également tenté d'autres stratégies : stocker mes triangles et tous les rasterizer à la suite, afin de ne garder que du calcul entier (pour n'appeler EMMS qu'une fois par frame), rien de concluant non plus.

J'en ai conclu que ce genre d'optimisation était bien plus compliqué que je ne le pensais, et que j'aurai les idées plus claires en y repensant dans quelques temps.

Donc si tu as encore des infos qui pourraient m'aider (maintenant ou dans le futur) à optimiser ce genre de traitement je suis preneur, sinon je pense que je vais en rester là.

**wwwwwwo** · 17/05/2006, 18h47

La logique proposée tourne en rond (ce n'est pas un reproche, c'est juste le constat de tes constatations qui ne me surpennent pas). La ressource "disponible" ne l'est pas vraiment à cause de sa "distance" et du fait quelle doit transférer des données de manière synchrone... L'idée était bonne à une époque ou c'était la seule solution en compétition.

Je vais radoter au risque de lasser, j'endends bien, mais les DVP des cartes travaillent en commun (à moins que l'on pense que les têtes creuses de chez A.., par exemple, ne sachent pas, ou plus, à quoi servent leurs cartes et quels sont les besoins de leurs utilisateurs et clients...). Le multi-corp, par exemple, n'est qu'une application bruyante (en plus très particulière et liée à un besoin très spécifique de l'OS) d'un vieux principe utilisé dans toute les conceptions électroniques de logiques programmables... (je t'apprends rien c'est sûr

). Donc, croire que les gus qui planchent sur les monstres qui nous servent de cartes graphiques ne font pas de code et ne se sont pas confrontés aux problèmes que tu penses résoudre de l'extérieur, c'est un peu "violent" (n'y vois aucune attaque perso c'est juste une expression.|). Le Kernel streaming permet de laisser une carte gérer le flux disque (ou d'autre chose) dont elle à besoin sans demander : DMA, s'il te plais grouille toi au lieu de t'occuper des autres... Je pense que le bien-connu qui a pondu le truc chez M$ était quelque peu conscient du commun de ce problème...

En fait, le seul problème que tu rencontres avec cette méthode est celui de la synchro, pas vrai ? (le code est optimisable, certes, mais cela ne résoudra pas ton problème j'en ai bien peur... et toi aussi finalement). La fragilité d'un tel code est évidente : En mode User par exemple, tu auras 10 ms dans le meilleur des cas pour toi, certes, mais à quels moments et à quel niveau de priorité ? Tu ferais déjà un service Kernel (si ce n'est pas déjà le cas) tu serai déja plus sûr qu'avec un time critical perturbant pour tous les petits copains...

Etudier les docs de ses braves gens et les contacter n'est pas non-plus la pire des idées qui pourrait de titiller

. Faudrait leur proposer de pouvoir changer le microcode à l'aide d'un protocole...flute...c'est déjà fait...

c'est dingue, je suis sûr qu'ils pourraient faire des jeux ces types là

!

[MMX] Optimisation d'un code C++ -> plus lent

x86 32-bits / 64-bits Assembleur

Discussions similaires

Partager

Partager