Topic sur la repartition de charge CPU/GPU, Versions de DirectX, etc

  • Auteur de la discussion Tetedeiench
  • Date de début

Tetedeiench

Expert
Non, je cherche pas la merde, mais me semble qu'un point est necessaire, la.

Avant la naissance des shaders et T&L, tout allait pour le meiux dans le meilleur des mondes.

le CPU prenait en charge :
-Le calcul des polygones
-L'eclairage et autres joyeusetes ( qu'il soit statique ou dynamique)

le GPU s'occupait :
-Du texturing
-Des filtrages et effets divers (bump mapping etc).

Puis arriva le T&L (directX7 ). On commenca alors a soulager le CPU de quelques taches que l'on pouvait tres bien cabler, a savoir :

-L'eclairage statique
-Le calcul de certains polys

Donc le CPU se trouvait soulage d'une partie des calculs, effectues par la carte graphique.

Puis arriva les shaders programmable. Au lieu dutiliser des fonctions preprogrammes, les programmeurs ont eu acces a un code leur permettant de faire effectuer a la carte des calculs sur les vertex ( a savoir les polygones) et les pixels. Cela leur permettait de faire effectuer n'importe quel calcul a la carte grpahique ou d'inserer les effets que l'on connait bien ( flotte et autre).



De plus, il ne faut pas croire que parce que une TNT2 peux faire tourner un jeu DirectX8 que la carte balance tout les calculs sur le CPU :)

Il faut savoir que DirectX evolue autour d'une base concrete, qui ne change globalement jamais ( calculer les polys, blabla). Les programmeurs definissent avant un jeu la plate forme minimale, et programment le jeu pour cette plate forme minimale, en utilisant que les instructions supportees par cette plate forme minimale.

Ensuite, ils programment les fonctions plus avancees, et les rendent activables/desactivables a volonte pour ceux dont les becanes peuvent les faire tourner, ou desactivees par defaut si elle ne les accepte pas.

Ainsi, une TNT2 peux faire tourner un jeu necessitant DirectX8.1 . Mais elle ne fera pas plus que ce qu'elle supporte, c'est a dire faire tourner un jeu DirectX8.1 avec des fonctions DirectX6.

Le minima requis etant toujours specifie.

Vous remarquerez que les options introduites par les DirectX successifs sont quasiment toujours desactivables ( bump mapping, shaders, etc). Maintenant vous connaissez la raison :)

On peux emuler lesdites fonctions par le CPU principal. Cependant, le cout est bien trop eleve pour un resultat bien souvent mediocre, donc cette fonction est totalement delaissee.

Voila pour ce que j'avais a dire, si quelqu'un a des corrections ou des changments a faire, tant qu'ils sont justifies, il est le bienvenu, je ne suis pas omniscient en la matiere :hello:
 

Tetedeiench

Expert
Je ne peux m'empecher d''aborder la croyance selon laquelle en cas de surcharge de la carte graphique, une partie des calculs est reportee sur le CPU.

C'est tout bonnement impossible.

Tout d'abord, il faudrait traduire les instructions a reporter sur le CPU en language CPU ( la CG parle un language a des annees lumieres de ce que l'on connait). L'efficacite de cette emulation est ridicule ( si en 1 seconde pour faites 100 operations sur le GPU, sur votre CPU principal vous en ferez 1 ( j;exagere, mais le rapport de 1:100 en temps d'execution ne me parait pas si eloigne de la realite) ).

De plus, il faudrait relacher toutes les donnees du calcul actuel vers le CPU. Ce qui entraine le chargement e tous les registres CPU. Ce qui entraine l'interruption des calculs en cours par le CPU ( polygones, son, etc). Puis enfin leur rapatriement vers la carte graphique qui doit les afficher. Ca fait beaucoup, non ? De plus, la memoire vive d'un CPU etant globalement plus lente que celle d'une Carte graphique, il serait suicidaire de lui donner d'autres fonctions que les fonctions de calcul, le texturing etant bien trop gourmand en memoire pour etre envisageable.

Bilan des courses, on aurait un systeme ralenti enormement a faire une telle chose.

Dans la pratique, il y a tujours un element limitant. CPU ou carte graphique. Si vous utilisez un logiciel de monitoring de charge CPU, vous verrez qu'en 1600x1200 32 bits tous effets a fond, il travaille enormement moins que la carte graphique.

En effet, ces deux elements sont symchrones. Si la carte grahique a pas fini son image actuelle, il ne sert a rien au CPU de calculer l'image suivnte. Il attends donc que la CG aie fini avant de lui envoyer son resultat.

Par contre, en 640x480 16bits, n'importe quelle carte graphique tiens le choc facilement. La, c;estle CPU qui doit bosser comme un fou pour lacher tous les polygones pour donner a manger a la carte graphique. A cette resolution, votre logiciel vous donnera un taux d'occupation CU proche des 100% dans les jeux.

La solution est donc de truver un couple equilibre, faisant qu'a une certaine resolution votr systeme est homogene, votre carte grpahique n'attends pas le CPU trop longtemps, et vice versa :)
 

bitcheur

Grand Maître
[citation=8452,1][nom]Tetedeiench a écrit[/nom][g]Je ne peux m'empecher d''aborder la croyance [/g]selon laquelle en cas de surcharge de la carte graphique, une partie des calculs est reportee sur le CPU.

C'est tout bonnement impossible.

Tout d'abord, il faudrait traduire les instructions a reporter sur le CPU en language CPU ( la CG parle un language a des annees lumieres de ce que l'on connait). L'efficacite de cette emulation est ridicule ( si en 1 seconde pour faites 100 operations sur le GPU, sur votre CPU principal vous en ferez 1 ( j;exagere, mais le rapport de 1:100 en temps d'execution ne me parait pas si eloigne de la realite) ).

De plus, il faudrait relacher toutes les donnees du calcul actuel vers le CPU. Ce qui entraine le chargement e tous les registres CPU. Ce qui entraine l'interruption des calculs en cours par le CPU ( polygones, son, etc). Puis enfin leur rapatriement vers la carte graphique qui doit les afficher. Ca fait beaucoup, non ? De plus, la memoire vive d'un CPU etant globalement plus lente que celle d'une Carte graphique, il serait suicidaire de lui donner d'autres fonctions que les fonctions de calcul, le texturing etant bien trop gourmand en memoire pour etre envisageable.

Bilan des courses, on aurait un systeme ralenti enormement a faire une telle chose.

Dans la pratique, il y a tujours un element limitant. CPU ou carte graphique. Si vous utilisez un logiciel de monitoring de charge CPU, vous verrez qu'en 1600x1200 32 bits tous effets a fond, il travaille enormement moins que la carte graphique.

En effet, ces deux elements sont symchrones. Si la carte grahique a pas fini son image actuelle, il ne sert a rien au CPU de calculer l'image suivnte. Il attends donc que la CG aie fini avant de lui envoyer son resultat.

Par contre, en 640x480 16bits, n'importe quelle carte graphique tiens le choc facilement. La, c;estle CPU qui doit bosser comme un fou pour lacher tous les polygones pour donner a manger a la carte graphique. A cette resolution, votre logiciel vous donnera un taux d'occupation CU proche des 100% dans les jeux.

La solution est donc de truver un couple equilibre, faisant qu'a une certaine resolution votr systeme est homogene, votre carte grpahique n'attends pas le CPU trop longtemps, et vice versa :)

[/citation]
tu sais moi , du moment que ca marche je ne cherche pas a comprendre :hello:
 

potemkin

Grand Maître
je vois pas où tu veux en venir

mail tout ca à Nvidia ou Ati,voire Matrox,mais pas ici :heink:
 

NiahBoumPof is back

Grand Maître
ca doit etre a cause de moi. Je veux bien croire qu'il ait raison en tout cas je veux plus d'ennuies. Sinon on va finir par se faire TT tout les 2.

Je m'explique a mon tour:
Pour moi (ou je dis bien pour moi) la carte gere ce qu'elle peut gerer; si les calculs a gerer etaient hors de portée de ce que le gpu pouvait gerer, le cpu prenait la suite.
On a eu un topic la dessus y'a pas longtemps et je tiens cette argumentation de la. Si tu veux je peux essayer de retrouver le lien ? :)
 

katkar

Grand Maître
Bon rappelle du modo ki sait tout


LE LOAD BALANCING (répartition de charge) ca n'existe po entre les procs et la CG :D

Tedeiench a raison et l'explication k'il vient de donner est assez exacte ........
 

potemkin

Grand Maître
quand le GPU est saturé d'operations,il en reduit simplement le nombre,ceci causant les célèbres ralentissements

pke,si le cpu pouvait prendre en charge les opérations de la CG,croyez bien qu'on pourrait faire tourner doom3 sur une TNT2 pour peu qu'on ait un P4 3,2Ghz

vs pouvez faire le test,avec un P3 1ghz et un p4 2,5ghz,et la meme CG pour les 2:le framerate est sensiblement identique

à part l'IA et autres petits détails,le cpu n'effectue aucun calcul graphique

(je crois que c ce que tu dis en gros,le iench :merci: )
 

NiahBoumPof is back

Grand Maître
[citation=8468,1][nom]katkar a écrit[/nom]Bon rappelle du modo ki sait tout


LE LOAD BALANCING (répartition de charge) ca n'existe po entre les procs et la CG :D

Tedeiench a raison et l'explication k'il vient de donner est assez exacte ........
[/citation]

La répartition de charge je suis tou a fait d'accord: le gpu se tape ce qu'il se tape et renvoie rien sur le cpu. Mais ma quesiton reste toujours pour les autres calculs: ceux que le GPU ne sais pas gerer
 

katkar

Grand Maître
ben ca passe a la trappe ......... pour les effet graphique ....
Ou sinon tu en as l'exemple sous 3dmark 2003 ..... la ou certain GPU gere un éffet graphique en 1 pass , d'otre le gere en 2 ou 3 pass , cai ski fait ke ton frame rate se pete la geule , le proc , lui ne fait rien d'autre ke d'envoyer la purée .......
 

NiahBoumPof is back

Grand Maître
[citation=8480,1][nom]katkar a écrit[/nom]ben ca passe a la trappe ......... pour les effet graphique ....
Ou sinon tu en as l'exemple sous 3dmark 2003 ..... la ou certain GPU gere un éffet graphique en 1 pass , d'otre le gere en 2 ou 3 pass , cai ski fait ke ton frame rate se pete la geule , le proc , lui ne fait rien d'autre ke d'envoyer la purée .......
[/citation]

:ouch:
Quelle horreur !!!
je vais tout de suite raouté mes GF256 et GF2MX au mur et acheter des vraies cartes.
euh qd meme pas. Mais en gros ca veut dire que sous un jeu utilisant des effets spécifiques au DX_, ces effets n'appareteront pas si ta carte ne gere pas le DX8 en hard ?
 

patry

Expert
[citation=8517,1][nom]NiahBoumPof is back a écrit[/nom]

:ouch:
Quelle horreur !!!
je vais tout de suite raouté mes GF256 et GF2MX au mur et acheter des vraies cartes.
euh qd meme pas. Mais en gros ca veut dire que sous un jeu utilisant des effets spécifiques au DX_, ces effets n'appareteront pas si ta carte ne gere pas le DX8 en hard ?
[/citation]

C'est pas le rôle de DirectX justement de faire ce boulot ?
On est plus à l'ère héroïque où les applications étaient compilées pour tel ou tel carte graphique. On est à l'ère de DirectX, qui est le passage obligé de tout programmeur pour accèder aux fonctions d'affichage. C'est au rôle du DRIVER de faire le passage entre la fonction et la carte et vous êtes pas naïfs pour croire que Nvidia ou Ati se programment de la même manière tout de même.
Donc c'est le rôle du driver d'implémenter en HARD, ou en SOFT ou PAS DU TOUT une fonction DirectX.

Désolé katkar tu a tort (je vais me faire modérer sec moi) et raison à la fois (il restait une branche solide dans ma chute tu a vu ?). Le driver peut très bien implémenter dans une carte réputée DirectX8 des fonctions DirectX9 qui seraient réalisées en SOFT, mais au risque de perdre énormément en performances. Par contre pas de load balancing (ce qui n'a rien a voir avec le sujet).

Généralement (expérience faite avec une Rage 128 première génération) certaines fonctions spécifiques sont approximées pour s'approcher du rendu souhaité (ex brouillard) d'autres sont parfaitement réalisées en soft (ex ombres portées).
Du coup l'application tourne mais avec un rendu différent de celui attendu, voire identique, mais **très** lent !

En gros faut simplement que les fabriquants bichonnent les drivers.
 

NiahBoumPof is back

Grand Maître
ba c'est bien ce qu'il me semblait la...je trouvais ca gros l'histoire de cases manquantes dans un jeu.(symbolique bien sur)
 

Tetedeiench

Expert
les shaders sont loins d'etre indispensables au jeu ( introduits DX8 et modifies avec DX9).

Le T&L aussi.

Le bump mapping aussi.

Tu perds des effets, mais ton jeu est tjs jouable. Je vois pas ou est le souci.

Oui les constructeurs peuvent faire ca en soft. En pratique, rares sont ceux qui le font. Pour l'instant, Nvidia et ATI ne choisissent pas cette solution. Y a guere que sis et son xabre qui a foutu les shaders en soft.

Tu n'aura jamais les shaders sur ta GeForce2 MX. Mais elle fera tres bien tourner morrowind ( enfin comme elle peut), mais sans shaders.

Ensuite, faut comprendre qu'un peu, a la base, le rendering est une boucle infinie. C'est le nombre d'iteration par seconde qui fait votre framerate. Donc, si la CG prends trop de temps a calculer l'image, elle fera moins d'iterations par seconde, et donc, le framerate diminuera. Elle "decide" rien la dedans. Elle fait juste son taff aussi bien qu'elle peux. Si on lui file enormement de taff et qu'elle ne puisse faire qu'une iteration toutes les 2 secondes, bah vous aurez 0.5 fps, c'est tout :hello:
 

Tetedeiench

Expert
Je vois pas ce qu'il y a de dur a comprendre.

Une carte non DX9 ne peux pas faire tourner les instructions DX9. Il faut donc les emuler en soft.

En pratique, personne le fait.

Donc comment faire tourner un jeu DX9 sur une carte DX8 ? tu desactives les instructions DX9. Et voila.
 
Vous devez vous inscrire ou vous connecter pour répondre ici.
Derniers messages publiés
Statistiques globales
Discussions
730 098
Messages
6 717 100
Membres
1 586 287
Dernier membre
lucilleguffey
Partager cette page
Haut