Reprise du message précédent :

Non, que l'on pourrait utiliser Mantle sur XB1, et même un wrapper D3D par dessus.

En gros que l'API "native" de la XB1 c'est Mantle, mais que MS a préféré créer un wrapper au-dessus de Mantle, et cette API présentée aux développeur est nommée DirectX 11.2, nom purement marketing qui n'aurait pas grand chose à voir avec le DirectX qu'on a sur PC.
Mais honnêtement je vois pas bien l’intérêt. Que l'API de la XB1 et de la PS4 soient proches de Mantle, c'est plausible : ce sont 3 API "close to metal" de la même architecture GPU, donc peu probable qu'elle soient très différentes (du moins pour la partie 3D) et c'est la raison pour laquelle Mantle n'a aucun intérêt sur console puisqu'il y a déjà l'équivalent. Mais pourquoi MS se ferait chier à wrapper l'API de la XB1 sous une autre API proprio (qu'ils auraient appelé DirectX) ? Ils pouvaient le faire sans wrapper.

Voilà ce que raconte Xbitlabs sur le sujet :

http://www.xbitlabs.com/news/multi [...] 1_API.html

Le type mélange tout. Il n'y a pas de Mantle ou de wrapper sur Xbox One juste un DirectX qui n'a pas grand chose à voir avec la version Windows hormis l'API publique. Sur Xbox c'est un "thin layer" qui communique directement avec le hardware et donc a un overhead très faible comparé avec la version Windows.  
 
Sur Windows tu as le cheminement suivant :
App->DirectX->UMD (User-Mode driver)->KMD (Kernel Mode driver)->Hardware
 
Alors que sur Xbox tu as
App->DirectX->Hardware
 
Sur consoles, DirectX va directement écrire dans le command buffer de la carte contrairement au PC où c'est le KMD qui se charge de ça.

Je comprend rien à vos histoires, mais je suis repassé aux 13.12, en attendant d'avoir des 14.1 (Beta ou WHQL) qui tiennent la route !

Pareil, assez déçu dans l’ensemble par la 14.1 et par Mantle. Le maximum de FPS augmente bien mais le minimum descend bien aussi... plus les micros freeze et les plantages plus fréquents... retour au 13.12

 
J'ai passer mon temps à lire des articles, message sur forum sur ce premier "jet" de mantle ( mais je n'ai pas pu le test étant sur pc portable ) et les premiers sentiments qu'on peut ressentir c'est qu'il n'y as aucune logique sur les plantage, gain de FPS, de framerate ect...
 
Je crois bien que l'équipement et l'OS sont des variables importantes au bon fonctionnement de mantle.
C'est sur qu'au niveau des test fait pas AMD/DICE il n'ont pas pu tester toutes les configurations possible ( c'est impossible d'ailleurs de le faire )
Donc la communauté va devoir faire les beta testeur pour améliorer petit à petit l'expérience Mantle.
 
Puis je connais pas le fonctionnement interne de Mantle, mais on ne peut pas savoir si c'est les développeur DICE qui ont mal codé Mantle ( normal ça fait peut de temps qu'il développe dessus ) ou si ce sont les drivers AMD qui sont pourri.
 
En tout cas, pour les développeurs faire de Mantle un standard multi plateforme c'est un gros plus. Je me souviens encore des plaintes des développeur pour développer le même jeux sous Xbox 360 et PS3, c'était le jour et la nuit.
 
Le seul a avoir fait l'effort d'harmoniser le développement à l'époque sur X360/PS3/PC c'était Cryteck avec le CE2 pour la sortie de Crysis 2.
 
Donc des avantages oui, un début difficile comme toute nouvelle techno, une utilité discuter forcement.
Mais si personne bouge les choses on restera bloquer en utilisant incorrectement la puissance de nos PC
 
Un exemple similaire actuelle... la fibre : c'est bien beau de pouvoir DL a plus de 60 mo/s quand on sait que la plupart des disques dur vendu ont du mal à l'atteindre sous windows.
Se serait comme nous déployer de la fibre 1 TO/S et rester sur de vieux DD 5400 tr/min et se dire bon ça suffit, ça fonctionne pas besoin de trouver un nouveau standard de stockage plus rapide.
 
Enfin bref, moi je suis en faveur d'AMD ( I am a true fan boy ). Et je suis heureux que cette alpha de mantle soit tout de même intéressante et apporte déjà de vrai gain.
 
Maintenant faut prendre ça avec du recul et se dire ça marche pas pas grave on attendra la prochaine

pilote beta + api alpha , tu t'attendais à quoi ?    
 
ça va prendre du temps faut pas se faire d'illusion
 
@OrcusZ   +1

 
Ceux qui ont la fibre ont des SSD  

 
Heu, personnellement je risque d'avoir la fibre avant le SSD
 
Raison : Fibre = presque gratuite ( abonnement au même prix, installation au charges de la co pro )
SSD : 120 go pour 80 euros = trop chère et pas assez de stockage ( je dev et joue donc mes logiciels prennent de la place )
 
Mais je pense qu'en général c'est vrai ^^

La plupart des HDD qui tiennent pas 60Mo/s va falloir mettre à jour tes disques alors
On est plus en 2005.

 
En séquentielle???
 
de Disque a disque on doit être a 100 Mo/s (Windows ) et 140 Mo/s ( linux )
 
En clef USB sur un bon disque ( 75/90 Mo/s )
 
Faut au moins un 7200 tr/min avec 32 mo de cache pour être certain d'avoir cette vitesse
 
Aujourd'hui la plupart des gens achète des ordi portable bureautique.
 
En général : disque dur 5400 tr/min avec 16 mo de cache...
 
Donc oui il les passe, mais tout le monde ne fait pas attention a ce genre de détail ( surtout les néophyte )
 

/HS

Si en 2014, tu n'as pas d'SSD, c'est que tu as raté ta config,    

Si tu es ric-rac niveau budget tu as des ssd de 64go à moins de 60€, les 120go à 70-80€ et les 240go à 120-130€, (on peut très bien avoir un HDD pour le stockage et un SSD pour l'os+applications !)

Pas de pc fixe j'ai un portable. Donc j'ai que 2 emplacement disque ( un windows + un linux ).
Donc un SSD de 64 ou 128 c'est à banir et 240 go c'est limite.
Quand je vois qu'en 2 semaine d'utilisation j'était a 200 go d'utilisation a terme c'est relou ( je doit faire plein de sauvegarde, avoir 2 mille clef usb ou DD externe ).

Pour les configuration qu'on propose ici a HFR, c'est pas toujours simple d'intégrer directement un SSD aussi...
Donc en 2014 le SSD n'est pas encore un standard malheureusement. ( Mais je suis d'accord ça devient de plus en plus indispensable mais pas récurant dans les configuration )

En 2014 pc avec SSD inclu c'est rare, et cette exemple visé des configuration tout prête.
Tout le monde ne monte pas sont PC...

//HS OFF

[HS] On peut très bien être dév et faire tenir Win + Linux sur un 60gb, je l'ai fait dans le passé. Linux ne prend quasiment rien, une partoche de 4 à 10gb lui suffisent largement (c'est pourtant mon système principal). Win7 64bits tient dans le reste avec les applis, et les jeux + data sur le(s) HD(s) à coté. Dans un portable on peut très bien faire cela aussi - avec 2 emplacements HD ou en mettant le HD à la place du lecteur dvd.

y aussi des combo SSD , HDD je crois
 

[hs]Surtout sous linux avec les mount point, tu met ton /home sur un hdd, par exemple.  
 
sinon, non HS, Mantle me fait regarder du coté d'AMD pour ma prochaine carte graphique. J'ai hâte de voir les cartes en 20 nm.

Vous pensez réellement que le 20nm va apporter quelques chose d'extra au GPU ?

ça sera un plus petit gap que le passage du 40 au 28 selon moi,
Il n'ya qu'a voir les CPU, de 32 à 22 il n'ya pas eu de gap de perf/conso/chauffe extra, même pire il s'oc moins bien

Même si ça n'a pas grand chose à voir à mon avis le 20nm ne sera pas LE gap que tout le monde à l'air d’espérer

Peut être sur la conso ...

c'est surtout la stacked mémory qui pourrais apporter et la généralisation de la gestion de la transparence façon intel (je c'est plus si c'est out of order ou l'inverse justement)  
 

c'est surtout que ça fait longtemps qu'on a pas eu ce gap justement, et que du fait, l'acceleration des performances était moins rapide en croissance négative!  

 
enfin bref, ça va redonner de l'air aux concepteurs quoi

Rien à voir : la technologie de transparence sans tri ("Order Intdependent Transparency" ) utilise une extension hardware permettant de réorganiser l'exécution des pixel shaders par pixel pour les finir dans le bon ordre. http://software.intel.com/en-us/bl [...] ronization

 
Les CPUs s'en servent principalement pour ajouter du cache et/ou augmenter la taille du GPU. Dans le cas d'un GPU, on pourra augmenter pas mal le nombre de CU. Et oui la stacked memory apportera beaucoup. (ou permettra de faire des cartes 128 bits/256 bits abordable)
 
Je dit surtout ça parce que j'ai une GTX 570, je n'achèterai jamais le haut de gamme, j'ai toujours été plus moyen/haut de gamme ou je trouve le meilleur rapport qualité/prix et j'attend un bon gain en performance pour le faire ( ou qu'elle crame...  )

 
 

mais de quoi tu parles ?!  
n'importe quel HDD sait sequentiellement ecrire a 60Mo/S aujourdhuis. meme les 5200tr/min ...  
 
Mantle est plus proche du metal. ya pas a tergiverser. les perfs sont meilleurs . /  
ca demandera un peu plus d'effort de la part des devs , au moins pour la premiere adaptation d'un moteur.  
 

Sur GPU c'est bien différent. Tout comme lors du passage 40->28nm, le passage 28->20nm va surtout permettre d'ajouter plein de transistors et donc un gros gain de perf, et ce ne sera pas au détriment de la conso (contrairement à un grossissement de GPU à gravure égale comme lors du passage 7970->290X). Pour la fréquence on s'en fou, c'est pas comme si ça faisait un moment que ça stagne...

 
 
 
C'est peux être le cas si tu fou ton download sous clé USB3 comme disque dure principal ou un dock HD externe de basse qualité mais pas les disques dures mech/SSD

Je trouve au contraire que les fréquence des GPU évolue au moins autant que le reste

Aujourd'hui tous les GPU sont à au moins 1ghz et beaucoup supporte les 1200+
Alors qu'en 40nm chez nvidia c'étais du 700-800mhz et amd du 800-900

 
ma clé USB 3.0 écrit @200Mo/s    
 
Il a du tester uniquement sur des pc portable vérolé vieux de 5ans  

Le passage du 28nm au 20nm aura les mêmes effets que les changements de gravure précédents (notamment celui du 40nm au 28nm) , c'est à dire qu'on pourra mettre deux fois plus de transistors sur une même surface.
Ça a toujours fonctionné pareil : il faut diviser par racine de 2 à chaque fois. C'est fait exprès.

Beaucoup moins que le reste ! Ils profitent clairement des nouvelles finesses de gravure pour y ajouter un max de transistors, le plus qu'ils peuvent sans dépasser un TDP "raisonnable". La fréquence elle suit timidement.

Chez nVidia
Juin 2008 : GTX280 55nm 602/1296MHz 1.4Md
Mars 2010 : GTX480 40nm 700/1401MHz 3.0Md
Nov 2010 : GTX580 40nm 772/1544MHz 3.0Md
Mars 2012 : GTX680 28nm 1006(+Boost) 3.5Md
Mai 2013 : GTX780 28nm 863(+Boost) 7.xMd

Chez AMD
Juin 2008 : HD4870 55nm 750MHz 0.96Md
Sept 2009 : HD5870 40nm 850MHz 2.1Md
Dec 2010 : HD6970 40nm 880MHz 2.6Md
Jan 2012 : HD7970 28nm 925MHz 4.3Md
Sep 2013 : R9 290X 28nm 1000MHz 6.2Md

Le GHz, on flirtait avec dès la fin de l'année 2009 (pas forcément sur les plus gros GPU, ou alors via des OC usine).
Entre 2008 et 2013, le nombre de transistors a été multiplié par 5 ou 6 !
Si la fréquence des Radeon avait suivi "au moins autant que le reste", la R9 290X serait aujourd'hui à 5GHz

 
Certain dock usb3 ou clé usb vraiment de de basse qualité qui use de vieux contrôleur qui vaut que dale c'est à peine 30-60 sinon tu as raison pour ce qui de bonne qualité et haute qualité on est sur la même longueur d'onde

AMd va nous faire le coup de BD fréquence avant IPC graphic pour GCN 2.0  

 
rien à voir de quoi?  
 
c'est justement de quoi je parlais  
il y a une notion d'ordre
 
les GPU AMD et NVIDIA ne semble pas pouvoir faire ça (ou de manière détourné mais coute trop de ressource)  
faut revoir leur archi
 
ça sera la première grosse évolution qui permettra des effet fancy comme de la fumé volumétrique ... mais vraiment volumétrique pas comme les truc merdique que l'ont a dans les jeux actuellement
et surement un tas d'autre truc  
 
après la stacked memory sera une évolution au niveau perf  
de la bande passante à gogo
 
après pourra t'on fourré 5 giga de stacked mememory? ou ça sera un genre de gros buffer? ou mémoire indépendante pour certaine taches
est ce que ça vas pas faire un GPU qui surchauffe? est ce que ça sera pas réservé seulement au GPU entrée de game low conso...  
enfin bon on y crois faut rever un peut ^^

 
Ce n'était pas clair dans ton message original, j'en ai compris que la stacked memory permettrait l'OIT (cette phrase semble mal construite) :

Yep, on doit le faire à la main, ce qui est couteux. Ou une approximation inexacte mais rapide.

L'extension d'intel permet de faire un kBuffer en une seule passe, sans cette extension c'est impossible. Certains ont réussi à simuler un mutex sur GPU en utilisant des instructions atomiques mais c'est totalement indéfini par la spec des API graphiques et par conséquent absolument pas robuste (ça marchait sur certains drivers nvidia, ça ne marche plus actuellement mais ça pourrait fonctionner de nouveau prochainement).

Sans support hardware, il n'y a pas de solutions miracles : avec un kBuffer de taille fixe par pixel, sans l'extension intel, si tu excedes les limites tu auras des tonnes d'artefacts. Une autre solution c'est une liste chainée par pixel, tu évites les problèmes de synchronisation mais c'est plus couteux et tu as un pool de mémoire global pour stocker les "maillons" de la liste chainée si tu dépasses tu auras des artefacts. Sinon c'est depth peeling mais ça nécessite plusieurs passes donc ce n'est pas praticable. Après effectivement il y a des approximations.

L'OIT est un sacré casse tête   c'est le cas depuis toujours mais bizarrement les GPU makers ne semblent pas y accorder beaucoup d'importance hormis intel dernièrement.

Yep.

• Il y a les solutions très lentes, présentées précédemment par Nv et Ati : depth peeling, buffer contenant une liste chainée par pixel à résoudre ensuite etc.
• Il y a le papier précédent d'Intel : un buffer stoquant un nombre fixé de samples par pixel, et à l'insertion d'un nouveau fragment on applique l'opacité courante à tous les samples précédents plus loin (les samples trop peu importants sont éliminés si on sature le nombre max de samples par pixcel), puis une passe résolvant la valeur finale. http://download-software.intel.com [...] DC2011.pdf
• Et une approximation rapide mais un peu dégueux : calculer l'opacité en fonction de la distance + l'alpha de la texture, et faire une somme pondérée des couleurs*opacité-trafiquée. Et ça marche pas si mal en fait. Surtout si fait par layer.

La liste chainée a un coût certain, mais c'est exploitable j'ai eu de bons résultats pour remplacer un algo de depth peeling. Sur un GPU puissant type K6000, la liste chainée peut facilement être 10/15 fois plus rapide que le depth peeling. Le point fort c'est que les perfs suivent celles du GPU, alors que le depth peeling du fait des nombreux draw calls nécessaires à chaque layer devient rapidement limité par le CPU.  
 
Overhead CPU que Mantle essaie justement de limiter... ouf, c'est limite mais je retombe sur le sujet du topic et je suis pas complètement HS

Bon ben c'est pas très stable pour l'instant Mantle J'ai des freezes + j'ai pas remarqué de hausse significative .
 
R9 290 + 2550K@4,4 Ghz

La présentation d'Intel à la GDC2011 est la même idée, mais en plus rapide : les slots sont préalloués et connexes, et ne stockent qu'un RGBA8, donnant moins de cache-miss, moins de bande passante consommée, etc.
Mantle n'aidera pas dans ton cas vu que le cout est dans les shaders units, pas coté CPU.

 
ok j'étais au taf j'ai pensé un truc et mes doigts on tapés n'importe quoi. En effet c'était incompréhensible  
mais merci pour les précision techniques !
 
d'après l'interview du gar de chez DICE il a dit qu'il demandais souvent ça au table ronde avec les constructeur de GPU
qui sais peut être prévu dans 1 ou 2 génération  
 

j'suis pas du tout expert comme vous mais j'espère qu'on on vas pas rester au GNC 1.1 ad vitam eternam

Oh bordel une 290x à 5ghz j'imagine même pas le refroidissement qu'il faudrait

Bon je rectifie alors, les fréquence évolue doucement mais sûrement

 
Ah oui la remarque sur Mantle était juste une petite pirouette pour retomber sur le sujet du topic je parlais du cas du depth peeling où tu multipliais par n ton nombre de draw calls (n passes de rendu pour générer n layers de peel) donc si les draw calls sont moins coûteux c'est toujours ça de pris. Mais ça n'en reste pas moins une solution à éviter, Mantle ou pas.  
 
Pour la présentation d'intel oui j'ai implémenté un truc comme ça, ça marche bien tant que tu ne dépasses pas ton nombre de slots, sinon il faut la synchro entre fragments et pour l'instant hormis les GPU intel Gen 7.5 ça n'est malheureusement pas supporté Après si tu as un accès bas niveau au GPU et qu'il supporte les atomics 64-bit (comme le GK110) tu peux packer couleur et depth dans 64-bit et faire des échanges atomiques, ça doit fonctionner mais niveau perf je n'ai pas testé.

En regardant les perfs aujourd'hui ça a l'air vraiment prometteur.
 
Reste plus qu'à négocier un échange de tech entre Nvidia GSync et AMD Mantle.....