Cartes Graphiques : DirectX 12

5780pts

Inscrit le: 28 mars 2012
Messages: 2739

Navigateur : n.c.
En ligne

Posté le: 10 février 2015 à 01:32

On est d'accord là dessus, en même temps je ne pense pas qu'on puisse vraiment prévoir.
A l'occasion je demanderai à mon pote qui vit à Montréal, il travaille dans une des boîtes qui bossent sur le jeu. Il saura peut-être.

0 pour,
0

funkydata @
Métayer

3600pts

Inscrit le: 12 septembre 2014
Age: 45
Messages: 2206

Navigateur : n.c.
Hors ligne

Posté le: 10 février 2015 à 13:36

Le coup des deux cartes en SLI/CF avec les RAM qui s'additionnent c'est dans la théorie. Dans la pratique ce sera impossible.
2 GPUs qui bossent sur la même scène ont fatalement besoin des mêmes données, ou du moins d'une grande partie d'entre-elles.Vu qu'il n'y a pas de pont vraiment performant entre les deux capable de permettre à 1 t'atteindre la mémoire de 2 par exemple, il faudra que 1 ait lui-même les données. De plus, données différentes dit tâches différentes. Il sera donc extrêmement difficile de scaler convenablement à cause de la répartitions des tâches.
On pourra au mieux trouver diverses optimisations et nouvelles techniques de rendus, et certaines pourront être super intéressentantes, mais dire que la mémoire de deux GPUs vont s'additionner sous DX12 c'est aussi vrai que de dire que la GTX 970 à 64 ROPs

Citation:

Concernant DirectX il est important selon moi de rappeler un peu l'historique.
Au début, époque Windows 3.1, Windows c'est pour bosser et MS-Dos c'est pour jouer et Microsoft sait très bien que c'est un gros problème car s'ils veulent imposer leur OS à fenêtre il vont devoir résoudre ce problème.
Il lance alors avec l'aide d'ATI (à l'époque) le développement de Windows Games SDK qui deviendra DirectX, une librairie permettant aux dev d'accéder au monde du multimédia sous Windows. Ce n'était pas aussi bas niveau que sous MS-Dos mais assez performant et moins compliqué/lourd à programmer.
A l'époque la puissance est dans les CPUs, les GPUs ne servant qu'à affichage donc l'API est pensée en ce sens. L'autre avantage c'est que DirectX couvre tout les aspects matériels (clavier, souris, son...). OpenGL quand à lui règne en maître sur le domaine de l'industrie et est réservé à l'élite sur du matos d'élite et ne gère que la partie visuelle. Puis OpenGL va se faire "standardiser" et passer en "accessible à tous" et la gueguerre entre les deux API commencent
Les versions de DirectX vont s’enchaîner à partir de là, Jusqu'à la 7ème version pas grand chose à dire mais la 8ème va être un bond en avant avec l'implémentation des shaders qui sont de petits sous-programmes qui vont permettre de manipuler et de calculer directement sur le GPU sans mettre le CPU à contribution ce qui est une avancée majeure : on commence enfin à sortir de l’hégémonie CPU. Mais ces shaders sont encore très limités au niveau du nombres d'instructions ce qui limite leur impact pourtant déjà énorme. DX9 arrive alors et augmente considérablement ce nombre d'instruction, on peut maintenant imaginer toutes sortes de techniques de rendu totalement impensable avec les versions précédentes, notamment le Deferred Shading pour ne citer que lui.
Le problème c'est qu'OpenGL n'a pas pu suivre le rythme de développement effréné de Microsoft et donc leur API, à la sortie de DX9, accuse un gros gros retard technologique. Hasard, ou pas..., le développement de DX va considérablement ralentir à partir de là, permettant à OpenGL de rattraper petit à petit son retard.

DX8 > Shaders de 96 instructions max
- Vertex Shader (Calculs et manipulations de la géométrie existante directement sur le GPU)
- Pixel Shader (Calculs et manipulations de de pixels directement sur le GPU)

DX9 > Shaders de 65536 instructions max

Grosse période de creux avec quelques maj DX9 puis arrive DX10. Outre un début de refonte dans l'approche même de l'API qui était franchement nécessaire, cette version a été la première à permettre de créer de la géométrie directement sur le GPU. Plus besoin de passer constamment par le CPU. Là encore c'est une avancée majeure bien que la fonctionnalité en elle-même soit plutôt limitée. Par exemple, pour un effet de fumée, on va créer des dizaines de plans texturés que l'on va superposer en transparence (pour simplifier). Avant il fallait créer tous les plans sur le CPU puis les envoyer au GPU. Soit, pour 100 plans : 400 points (vertex), 600 indices, 200 primitives. Avec DX10 on envoie juste 100 points et on créé la géométrie sur le GPU directement via un Geometry Shader.

DX 10 > Shaders sans limites d'instructions
- Geometry Shaders (Création de géométrie directement sur le GPU mais nombres de points limités)

Et enfin DX11. Il termine la refonte dans l'approche commencée avec DX10 et apporte beaucoup, beaucoup de nouvelles choses. Un nouveau Shader par exemple, le Hull Shader, qui va permettre de faire plus que le Geometry Shader de DX10 : du processing de vertices sur le GPU en masse. On peut donc s'amuser à faire un océan ultra-réaliste, une route pavée magnifique grâce au Displacement Mapping... Outre cette avancée, DX11 introduit les Compute Shader qui vont encore plus loin dans l'approche puisque ce n'est ni plus ni moins que du GPGPU. On peut demander au GPU d'effectuer des calculs qui n'ont rien à voir avec l'aspect visuel (IA, Physique...). Autre grosse évolution c'est le Multithreaded rendering qui permet d'exploiter enfin à son plein potentiel les cores des CPUs. Bref, une API qui ressemble bien à nos machines : CPU multi-cores, GPU à grosse puissance de calcul.

Maintenant l'avenir... Ce qui est sur malgré toutes ces évolutions, c'est que trop souvent on doit passer par le CPU pour modifier l'état (au sens très large) du GPU. Le CPU c'est un peut la gare de train où l'on est obligé de s'arrêter alors que ce n'est pas notre destination finale... forcément on perd du temps ! Mantle et DX12 vont tenter de résoudre ce problème en nous permettant d'avoir une ligne directe avec le GPU. Dans quelles proportions, avec quel degré de permissivité ? On en sauras plus dans quelques mois.

PS : Outch, je viens de me rendre compte du pavé, je le met en 'quote' pour les petits écrans

1 pour,
1

Sambre @
Cultivateur

1281pts

Inscrit le: 05 juin 2010
Messages: 657
Localisation: Hérouville Saint Clair
Navigateur : n.c.
Hors ligne

Posté le: 10 février 2015 à 14:08

funkydata a écrit:

Le coup des deux cartes en SLI/CF avec les RAM qui s'additionnent c'est dans la théorie. Dans la pratique ce sera impossible.
2 GPUs qui bossent sur la même scène ont fatalement besoin des mêmes données, ou du moins d'une grande partie d'entre-elles.Vu qu'il n'y a pas de pont vraiment performant entre les deux capable de permettre à 1 t'atteindre la mémoire de 2 par exemple, il faudra que 1 ait lui-même les données. De plus, données différentes dit tâches différentes. Il sera donc extrêmement difficile de scaler convenablement à cause de la répartitions des tâches.
On pourra au mieux trouver diverses optimisations et nouvelles techniques de rendus, et certaines pourront être super intéressentantes, mais dire que la mémoire de deux GPUs vont s'additionner sous DX12 c'est aussi vrai que de dire que la GTX 970 à 64 ROPs Cool

Si, c'est totalement envisageable en partant sur un mode split frame rendering, où chaque GPU gère une partie de l'image.
Dans ce type de traitement la Vram ne s'additionne pas totalement, puisqu'une certaine quantité reste dédiée à la communication entre les GPU et à certaines données dupliquées. Mais on peut espérer pouvoir profiter d'au moins 80% de la mémoire totale disponible.

0 pour,
0

garzebuth @
Fermier

6291pts

Inscrit le: 30 novembre 2011
Messages: 3667

Navigateur : n.c.
Hors ligne

Posté le: 10 février 2015 à 14:21

funkydata a écrit:

Le coup des deux cartes en SLI/CF avec les RAM qui s'additionnent c'est dans la théorie. Dans la pratique ce sera impossible.
2 GPUs qui bossent sur la même scène ont fatalement besoin des mêmes données, ou du moins d'une grande partie d'entre-elles.Vu qu'il n'y a pas de pont vraiment performant entre les deux capable de permettre à 1 t'atteindre la mémoire de 2 par exemple, il faudra que 1 ait lui-même les données. De plus, données différentes dit tâches différentes. Il sera donc extrêmement difficile de scaler convenablement à cause de la répartitions des tâches.
On pourra au mieux trouver diverses optimisations et nouvelles techniques de rendus, et certaines pourront être super intéressentantes, mais dire que la mémoire de deux GPUs vont s'additionner sous DX12 c'est aussi vrai que de dire que la GTX 970 à 64 ROPs Cool

Citation:

Concernant DirectX il est important selon moi de rappeler un peu l'historique.
Au début, époque Windows 3.1, Windows c'est pour bosser et MS-Dos c'est pour jouer et Microsoft sait très bien que c'est un gros problème car s'ils veulent imposer leur OS à fenêtre il vont devoir résoudre ce problème.
Il lance alors avec l'aide d'ATI (à l'époque) le développement de Windows Games SDK qui deviendra DirectX, une librairie permettant aux dev d'accéder au monde du multimédia sous Windows. Ce n'était pas aussi bas niveau que sous MS-Dos mais assez performant et moins compliqué/lourd à programmer.
A l'époque la puissance est dans les CPUs, les GPUs ne servant qu'à affichage donc l'API est pensée en ce sens. L'autre avantage c'est que DirectX couvre tout les aspects matériels (clavier, souris, son...). OpenGL quand à lui règne en maître sur le domaine de l'industrie et est réservé à l'élite sur du matos d'élite et ne gère que la partie visuelle. Puis OpenGL va se faire "standardiser" et passer en "accessible à tous" et la gueguerre entre les deux API commencent
Les versions de DirectX vont s’enchaîner à partir de là, Jusqu'à la 7ème version pas grand chose à dire mais la 8ème va être un bond en avant avec l'implémentation des shaders qui sont de petits sous-programmes qui vont permettre de manipuler et de calculer directement sur le GPU sans mettre le CPU à contribution ce qui est une avancée majeure : on commence enfin à sortir de l’hégémonie CPU. Mais ces shaders sont encore très limités au niveau du nombres d'instructions ce qui limite leur impact pourtant déjà énorme. DX9 arrive alors et augmente considérablement ce nombre d'instruction, on peut maintenant imaginer toutes sortes de techniques de rendu totalement impensable avec les versions précédentes, notamment le Deferred Shading pour ne citer que lui.
Le problème c'est qu'OpenGL n'a pas pu suivre le rythme de développement effréné de Microsoft et donc leur API, à la sortie de DX9, accuse un gros gros retard technologique. Hasard, ou pas..., le développement de DX va considérablement ralentir à partir de là, permettant à OpenGL de rattraper petit à petit son retard.

DX8 > Shaders de 96 instructions max
- Vertex Shader (Calculs et manipulations de la géométrie existante directement sur le GPU)
- Pixel Shader (Calculs et manipulations de de pixels directement sur le GPU)

DX9 > Shaders de 65536 instructions max

Grosse période de creux avec quelques maj DX9 puis arrive DX10. Outre un début de refonte dans l'approche même de l'API qui était franchement nécessaire, cette version a été la première à permettre de créer de la géométrie directement sur le GPU. Plus besoin de passer constamment par le CPU. Là encore c'est une avancée majeure bien que la fonctionnalité en elle-même soit plutôt limitée. Par exemple, pour un effet de fumée, on va créer des dizaines de plans texturés que l'on va superposer en transparence (pour simplifier). Avant il fallait créer tous les plans sur le CPU puis les envoyer au GPU. Soit, pour 100 plans : 400 points (vertex), 600 indices, 200 primitives. Avec DX10 on envoie juste 100 points et on créé la géométrie sur le GPU directement via un Geometry Shader.

DX 10 > Shaders sans limites d'instructions
- Geometry Shaders (Création de géométrie directement sur le GPU mais nombres de points limités)

Et enfin DX11. Il termine la refonte dans l'approche commencée avec DX10 et apporte beaucoup, beaucoup de nouvelles choses. Un nouveau Shader par exemple, le Hull Shader, qui va permettre de faire plus que le Geometry Shader de DX10 : du processing de vertices sur le GPU en masse. On peut donc s'amuser à faire un océan ultra-réaliste, une route pavée magnifique grâce au Displacement Mapping... Outre cette avancée, DX11 introduit les Compute Shader qui vont encore plus loin dans l'approche puisque ce n'est ni plus ni moins que du GPGPU. On peut demander au GPU d'effectuer des calculs qui n'ont rien à voir avec l'aspect visuel (IA, Physique...). Autre grosse évolution c'est le Multithreaded rendering qui permet d'exploiter enfin à son plein potentiel les cores des CPUs. Bref, une API qui ressemble bien à nos machines : CPU multi-cores, GPU à grosse puissance de calcul.

Maintenant l'avenir... Ce qui est sur malgré toutes ces évolutions, c'est que trop souvent on doit passer par le CPU pour modifier l'état (au sens très large) du GPU. Le CPU c'est un peut la gare de train où l'on est obligé de s'arrêter alors que ce n'est pas notre destination finale... forcément on perd du temps ! Mantle et DX12 vont tenter de résoudre ce problème en nous permettant d'avoir une ligne directe avec le GPU. Dans quelles proportions, avec quel degré de permissivité ? On en sauras plus dans quelques mois.

PS : Outch, je viens de me rendre compte du pavé, je le met en 'quote' pour les petits écrans Clin d'oeil

Beau pavé

La question que je me pose c'est sur la réaction d'OpenGL. Maintenant que steamOS arrive (on y croit), avoir une API plus bas niveau serait vraiment intéressante vu la puissance souvent moindre des hardwares proposés.
Mais avec les nombre d'applications industrielles d'OGL ça risque d'être dur de faire autant bouger l'API

@Sambre : le split frame rendering résoud pas le problème majeur de la mémoire partagée sur les SLI/CF, à savoir la lenteur du port PCIe. D'ailleurs je vois pas comment ça serait possible de résoudre le soucis, dans tous les cas il y a une grande partie de données qui seront nécessaires aux deux GPUs en même temps.
Edit : en fait j'ai l'impression qu'on est pas d'accord sur la proportion de mémoire partagée entre les deux GPUS.

0 pour,
0

funkydata @
Métayer

3600pts

Inscrit le: 12 septembre 2014
Age: 45
Messages: 2206

Navigateur : n.c.
Hors ligne

Posté le: 10 février 2015 à 14:42

Sambre a écrit:

Si, c'est totalement envisageable en partant sur un mode split frame rendering, où chaque GPU gère une partie de l'image.
Dans ce type de traitement la Vram ne s'additionne pas totalement, puisqu'une certaine quantité reste dédiée à la communication entre les GPU et à certaines données dupliquées. Mais on peut espérer pouvoir profiter d'au moins 80% de la mémoire totale disponible.

Justement je ne vois pas comment, mais je suis open, explique-moi comment tu vas gérer la VRAM au niveau de ton moteur dans cette situation. Ça m’intéresse

Prenons un exemple simpliste. Un cube texturé qui tourne au centre de ton écran. Tu divises ton rendu en 2 parties, le GPU 1 pour haut, l'autre pour le bas.
Le 1 doit avoir en mémoire la géométrie du cube, forcément, le deux aussi, idem pour la texture. Le Z Buffer doit être identique... bref, tout doit être partagé, je ne vois rien qui puisse être déporté.
Le seul truc qui pourrait être possible serait de splitter le scenegraph en lui-même mais là le scaling du SLI va s'effondrer parce qu'il est impossible de déterminer à l'avance la charge qui sera appliquer sur l'un ou l'autre des GPUs, d'autant plus qu'il y a des données qui faudra faire transiter obligatoirement à chaque frames pour avoir une image cohérente comme le ZBuffer ou les calculs d'illumination pour ne citer qu'eux.

garzebuth a écrit:

Beau pavé

La question que je me pose c'est sur la réaction d'OpenGL. Maintenant que steamOS arrive (on y croit), avoir une API plus bas niveau serait vraiment intéressante vu la puissance souvent moindre des hardwares proposés.
Mais avec les nombre d'applications industrielles d'OGL ça risque d'être dur de faire autant bouger l'API Triste

@Sambre : le split frame rendering résoud pas le problème majeur de la mémoire partagée sur les SLI/CF, à savoir la lenteur du port PCIe. D'ailleurs je vois pas comment ça serait possible de résoudre le soucis, dans tous les cas il y a une grande partie de données qui seront nécessaires aux deux GPUs en même temps.
Edit : en fait j'ai l'impression qu'on est pas d'accord sur la proportion de mémoire partagée entre les deux GPUS.

Je partage ton interrogation concernant OpenGL, et effectivement il sera certainement plus difficile de faire bouger l'API pour les raisons que tu cites très justement. Je pense quand même qu'ils vont suivre à terme le mouvement comme ils l'ont toujours fait en conservant au maximum la compatibilité descendante au risque de complexifier un peu plus leur API.

Dernière édition par funkydata le 10 février 2015 à 14:57; édité 1 fois

0 pour,
0

Finch @
Meuhdérateur

17268pts

Inscrit le: 18 août 2013
Age: 42
Messages: 9328
Localisation: Bordeaux
Navigateur : n.c.
Hors ligne

Posté le: 10 février 2015 à 15:54

y'a encore des jeux sous OpenGL?

0 pour,
0

garzebuth @
Fermier

6291pts

Inscrit le: 30 novembre 2011
Messages: 3667

Navigateur : n.c.
Hors ligne

Posté le: 10 février 2015 à 16:09

Finch a écrit:

y'a encore des jeux sous OpenGL?

Tous les jeux du futur steamOS, ainsi que les jeux ps4 (sur une version maison cela dit).
Et tous les jeux android/iOS.

En gros tous les jeux qui ne sont pas sur plateforme microsoft, directX proprio oblige^^

0 pour,
0

Finch @
Meuhdérateur

17268pts

Inscrit le: 18 août 2013
Age: 42
Messages: 9328
Localisation: Bordeaux
Navigateur : n.c.
Hors ligne

Posté le: 10 février 2015 à 16:14

ok, donc jeux ps4/droïd/IOs je m'en fous un peu (mon papi dirait que ça lui en touche une sans faire bouger l'autre, un grand sage quoi) par contre pour SteamOS c'est plus ballot effectivement...

de mémoire, je sais que certains vieux fps, comme quake 4 par exemple, étaient sous opengl, mais j'ai pas d'exemples plus récents, en effet...

0 pour,
0

Lysfith @
Saisonnier

22pts

Inscrit le: 17 décembre 2014
Messages: 2

Navigateur : n.c.
Hors ligne

Posté le: 10 février 2015 à 16:30

A priori selon quelques articles sur le net, OpenGL 5 permettra à OpenGL de rattraper son retard sur ses concurrents, grâce à une API bas niveau comme DX12 et Mantle.

http://www.mac4ever.com/actu/93061_opengl-5-dependra-moins-des-pilotes-graphiques
http://www.extremetech.com/gaming/187796-opengl-4-5-released-next-gen-opengl-unveiled-cross-platform-mantle-killer-dx12-competitor

On en saura surement plus à la GDC, une conf. va parler du futur d'OpenGL : http://schedule.gdconf.com/session/glnext-the-future-of-high-performance-graphics-presented-by-valve

0 pour,
0

Finch @
Meuhdérateur

17268pts

Inscrit le: 18 août 2013
Age: 42
Messages: 9328
Localisation: Bordeaux
Navigateur : n.c.
Hors ligne

Posté le: 10 février 2015 à 16:37

merci pour les infos...

plus de news en mars donc...

0 pour,
0

maptiviou @
Fermier

5780pts

Inscrit le: 28 mars 2012
Messages: 2739

Navigateur : n.c.
En ligne

Posté le: 10 février 2015 à 16:45

Finch a écrit:

ok, donc jeux ps4/droïd/IOs je m'en fous un peu (mon papi dirait que ça lui en touche une sans faire bouger l'autre, un grand sage quoi) par contre pour SteamOS c'est plus ballot effectivement...

de mémoire, je sais que certains vieux fps, comme quake 4 par exemple, étaient sous opengl, mais j'ai pas d'exemples plus récents, en effet...

Dans l'optique de faire tourner les jeux sous SteamOS, il y a aussi L4D2 qui avait été porté sur OpenGL, et ce dernier tournait mieux que sous DirectX.
Le problème d'OpenGL, de ce que j'ai compris, c'est qu'il est plus chiant à exploiter que DirectX, d'où la préférences des développeurs pour ce dernier... Et peut-être quelques chèques de Microsoft pour aider à la décision.

0 pour,
0

funkydata @
Métayer

3600pts

Inscrit le: 12 septembre 2014
Age: 45
Messages: 2206

Navigateur : n.c.
Hors ligne

Posté le: 10 février 2015 à 17:01

maptiviou a écrit:

Finch a écrit:

ok, donc jeux ps4/droïd/IOs je m'en fous un peu (mon papi dirait que ça lui en touche une sans faire bouger l'autre, un grand sage quoi) par contre pour SteamOS c'est plus ballot effectivement...

de mémoire, je sais que certains vieux fps, comme quake 4 par exemple, étaient sous opengl, mais j'ai pas d'exemples plus récents, en effet...

Dans l'optique de faire tourner les jeux sous SteamOS, il y a aussi L4D2 qui avait été porté sur OpenGL, et ce dernier tournait mieux que sous DirectX.
Le problème d'OpenGL, de ce que j'ai compris, c'est qu'il est plus chiant à exploiter que DirectX, d'où la préférences des développeurs pour ce dernier... Et peut-être quelques chèques de Microsoft pour aider à la décision.

Il utilise le Source Engine, moteur qui supportait déjà OpenGL en 2009 quand le jeu est sorti. En 2012 il tournait mieux simplement parce que ce même Source Engine avait 3 ans d'évolution en plus dans la musette et qu'en plus ils avaient optimisé le jeu en lui-même. J'ai envie de dire, heuresement que ça tournait mieux, le contraire aurait été grave. Bref, le "Ca tourne mieux sous Linux/OGL" de l'époque, égal, "regardez notre SteamOS va tout arracher !", c'est du marketing pur et simple.

Non OGL n'est pas plus chiant a exploiter c'est juste une question d'habitude, enfin, de mon point de vue, même si je préfère DX, surtout depuis la version 11.

0 pour,
0

maptiviou @
Fermier

5780pts

Inscrit le: 28 mars 2012
Messages: 2739

Navigateur : n.c.
En ligne

Posté le: 10 février 2015 à 17:05

Ok, autant pour moi.

0 pour,
0

Lysfith @
Saisonnier

22pts

Inscrit le: 17 décembre 2014
Messages: 2

Navigateur : n.c.
Hors ligne

Posté le: 11 février 2015 à 10:15

Je viens de trouver un autre article sur Tomshardware : http://www.tomshardware.fr/articles/test-directx-12,1-55469.html

Intéressant de voir le fait, vu que les cartes graphiques seront mieux exploités, la consommation augmentera aussi.

0 pour,
0

funkydata @
Métayer

3600pts

Inscrit le: 12 septembre 2014
Age: 45
Messages: 2206

Navigateur : n.c.
Hors ligne

Posté le: 11 février 2015 à 10:29

Lysfith a écrit:

Je viens de trouver un autre article sur Tomshardware : http://www.tomshardware.fr/articles/test-directx-12,1-55469.html

Intéressant de voir le fait, vu que les cartes graphiques seront mieux exploités, la consommation augmentera aussi.

Article original déjà posté Page 5

C'est ce qui a relancé le débat d'ailleurs

0 pour,
0

Sujet		Auteur	Forum	Réponses	Posté le
Sujets similaires
	[OS] - DirectX - autre?	the_man3	Optimisation Windows	12	12 août 2023 à 15:39
	Office 2016 imprime page blanche	cordobaseb	OsLand	5	11 août 2021 à 19:57
	Infection de page web sur le test des pâtes thermiques	Bobblebubble	Amélioration du site	54	24 juillet 2021 à 21:34
	Voyez-vous les images sur la page d'accueil sur votre tél ?	beubeu	Amélioration du site	19	14 janvier 2021 à 10:06
	Vend gtx 1070 ti / 250 euros , page 2	batigol	Ventes	0	15 décembre 2019 à 09:47

DirectX 12 , page 8

Sujets similaires