Microsoft avait réservé pour sa conférence Build 2015 les détails concernant une énième nouvelle fonctionnalité de Direct3D 12 : le support explicite du ...
Lire la suite ...

comptez sur nVidia pour verrouiller à mort et empêcher toute utilisation conjointe avec les produits du concurrent

Il y a aussi un autre point à prendre en compte dans le cas de l'utilisation du GPU intégré Intel : il va faire chauffer le processeur un peu plus, ce qui risque de throttler ce dernier. Du coup ça va être un savant mélange d'équilibre à réaliser, c'est pas sûr que ça soit viable. Cela dit, ça ouvre la voie à plein de possibilités.

en effet ça parait assez surréaliste  
sans oublier que toutes ces avancées , même si elles amènent plus de libertés pour les développeurs , vont aussi augmenter leur charge de travail  
et quand on voit comment sont portés les jeux multi plateformes ces dernières années , ça laisse perplexe  

Si ces libertés sont implémentées dans les moteurs de jeux, ça peut très bien être transparent pour les développeurs de jeux non ?  
L'idée peut sinon être interessante pour ceux qui changent de carte graphique, l'ancienne peut alors servir à gagner en performance. Ou encore on peut se payer une carte moyen de gamme pour aider une plus haut de gamme. Il faut voir si c'est potentiellement rentable. (exemple : coupler une 280X avec une 260 pour espérer dépasser une R9 290 à prix équivalent) (si des gens ont envie de calculer la rentabilité réelle, je vous laisse vous amuser, moi je n'émets qu'une hypothèse )

Plein d'opportunités ce DX12! Dans un premier temps ce serait déjà génial de pouvoir faire travailler les APUs présentes dans dans nos CPU histoire de gratter quelques FPS

Gagner 4FPS pour avoir 17ms de latence supplémentaire, non merci.
 
Je suppose que le gain montré dans la démo est le meilleur qu'on puisse obtenir. Si la carte graphique débite 90fps le gain risque d'être moindre voir négatif ?  
 
Car le GPU secondaire à l'air d'ajouté une latence finale de 23ms (et permet de gagner 6ms sur le traitement principal). Mais dès qu'on dépasse les 44fps (23ms) qu'est ce qu'il se produit ? Le gpu principal se tourne les pouces ?

 
Non je pense en fait le contraire. On assiste à une convergence à la fois pour le soft et le hard entre les plate-forme PC et console. Cela impliquera une convergence beaucoup plus grande et donc une portabilité beaucoup plus facile. On peut même peut-être s'attendre à ce que DX12 soit intégré à la XboX one en tant qu'API de bas niveau. Un jeu développé pour XboX sera ainsi directement utilisable sur PC et inversement.

Wep rien d'extraordinaire quoi se DX12.
 
Des nouvelle soit disant que Dx12 gérerait un SLI/CrossFire comme un seul GPU?

Est-ce que le système d'exploitation de la xbox one est compatible avec dx12?

Que DX12 permette d'utiliser 100% de la RAM disponible sur un SLI, ce sera déjà pas si mal.

Toutes ces nouveautés permet telle d'enfin cumuler la ram en multi gpu ?

vu que la bp mémoire se retrouverait également partagée , pas sûr que ce soit si intéressant que ça , au contraire  
 

en même temps ça collerait pas vraiment avec la politique de la boite en question

vu que la bp mémoire se retrouverait également partagée , pas sûr que ce soit si intéressant que ça , au contraire  
 

Pourquoi la bande passante serait partager ?

Pourquoi la bande passante serait partagé ?

Dans l'exemple de l'article, il y a déjà cumul de la mémoire de la CG et de la mémoire du système (pour le travail effectué par le gpu intégré). Mais il est évident qu'on ne doit pas considérer que cela correspond à une cg virtuelle qui aurait la VRAM + la mémoire système. Pour pouvoir cumuler les mémoires, il faut que les tâches soient indépendantes, sinon on perd beaucoup en perf pour transférer les données d'un système mémoire à l'autre.
La réponse à ta question est donc "non", mais il pourrait y avoir quelques optimisations de l'utilisation VRAM grâce à DX12.

Heu il a franchement raison c'est pas un troll. Je suis prêt à parier que ce sera le cas ou qu'il y aura volontairement des limitations ou bridages d'une manière ou d'une autre.
 
Exact pour le coup de la mémoire partagé si un GPU doit lire la RAM de l'autre GPU ça va augmenter à mort le trafic sur le bus PCI donc pas sûr que ce soit si intéressant que ça.
 
Pour l'iGPU il faudrait lui trouver une autre utilisation que l'exemple donné ici pour avoir un gain sans latence supplémentaire. C'est dommage car bien utilisé ça pourrait être super intéressant mais je me fais pas trop d'illusions.

 
Loin d'etre un troll, puisque Nvidia a deja fait ce genre de pratique.  
 
Qui se rappelle des modifications des pilotes Physx pour empecher l'utilisation d'une carte Nvidia couplé avec une carte AMD pour avoir le Physx actif avec une radeon en carte principale
 
http://www.vrworld.com/2014/07/31/ [...] installed/
 
http://www.ngohq.com/graphic-cards [...] esent.html
 
http://www.slashgear.com/nvidia-di [...] d-2558108/

C'est plutôt Ravenloft qui est en dehors de la réalité là. On commence à bien savoir comment il fonctionne le caméléon.
C'est comme l'ouverture du code de PhysX je reprends la phrase très bien formulé que j'ai vu sur un site "Nvidia is as open source friendly as a great white shark".
Genre CUDA. OK tu veux pas utiliser CUDA tu veux OpenCL ? ben on divise par 4 la mémoire video utilisable histoire de bien t'obliger à utiliser CUDA (si si, c'est pas un troll c'est vraiment le cas).
Ils sont malins leur technique c'est de faire que ce soit utilisable mais de bien prendre soin de mettre suffisamment de limitations pour que personne utilise autre chose que toutes leurs technos et matos propriétaires.

 
Si j'ai bien compris l'article, c'est ce qui rend compliquée l'implémentation de cette fonctionnalité. La partie du post processing envoyer à iGPU doit prendre moins de temps à être réalisé que le traitement principal de l'image ainsi que son envoie. Donc la latence ajoutée sera toujours d'un peu moins d'une image. De plus, pour qu'il n'y ait pas de perte d'efficacité, le gain obtenu doit être supérieur au temps pris au transfert.

Et c'est quoi ton explication sur la mémoire video divisé par 4 en utilisation OpenCL sur les cartes Nvidia ?
tu t'es bien gardé faire un commentaire la dessus.
En plus c'est complètement faux je suis persuadé que si ils le voulaient l'accélération matériel PhysX serait facile à mettre ne place sur les cartes AMD et je vois pas en quoi le fait que PhysX n'appartenait pas à Nvidia avant change quelque chose au fait qu'ils ont tout verrouillé.
C'est encore une manoeuvre très habile de Nvidia "mais si regardez PhysX tourne sur tous les PC par contre les performances sont ridicules quand ça tourne sur le CPU c'est pas grave vous avez qu'à acheter une carte Nvidia"

RRRooo on s'en fout de vos débats de fanboy:
 
Voilà la réalité.
 
- les APU, c'est à 90% des APU de chez intel (qui en sont tous maintenant), donc si la techno apporte vraiment quelque chose, bien sur que Nvidia la développera, et certainement exclusivement sur les APU d'intel.
- Pour AMD, il y a eu déjà des essais de fait la-dessus (APU + CG), et bien sûr qu'ils développeront cette techno si ça apporte quelque chose au moins avec leur APU

Je dirais même que c'est 100%  

Pour PhysX je suis persuadé que si je recherche je vais voir que la partie non accéléré propose les technologies les moins intéressantes.

C'est les mêmes. Le truc par contre, c'est que les devs aidés par nvidia utilisent la puissance gagnée par le passage au GPU pour ajouter des effets.

 
Ben je connais pas trop les part de marché d'AMD sur les APU, mais il ne me semble pas s'être écroulé à ce point quand même ... ;-)

J'avais pas pris la phrase dans ce sens la. Mes excuses  

On s'en fout de PhysX. Pratiquement plus aucun jeu n'offre cette option qui n'apporte de toute façon pas grand chose visuellement.

PhysX GPU ok, mais physX CPU c'est une des solutions les plus utilisées dans le domaine.
 
Le pas grand chose, c'est relatif quoi. Il y a une vrai diff entre un borderlands sans physX Gpu et avec. Pareil pour Batman.

 
Il ne confond rien du tout, physx est inutilisable si tu n'as pas une carte nvidia, point.
 

imho havok est plus utilisé que physx et on comprend pourquoi !
à part en étant sponsorisé($$$$) par nvidia je vois pas trop l’intérêt d'intégrer des effets qui ne tourneront avec un débit d'images potable que sur une part du marché.

N'importe quoi. PhysX marche très bien sur CPU. Ce qui marche moins bien sur les cartes non nvidia, c'est les effets que le passage de PhysX en GPU permet de rajouter.

à 3fps ?
 
framerate divisé par plus de 2 sur batman...inutilisable donc. 26 de moyenne... au lieu de 59

Les effets en plus sont pas optimisés CPU. Quand tu forces leur activation (donc quand tu as une carte AMD), cela rame. Ce qui est normal vu que les effets physX en plus sont alors gérés par le CPU.

A noter que les devs pourraient mettre les mêmes effets dans leur version CPU pour tout le monde, mais cela impacterait un max les perfs vu les effets en question.

Je vois pas de "moitié physx"("physx avec moins d'effets" ) dans les jeux. C'est avec ou sans.
 
edit on sait modifier le niveau de physx sur certains jeux mais ça ne change rien, le débit d'images chute énormément même avec un "niveau moyen" contrairement à la désactivation.
 
Donc il est où ce physx sur cpu qui soit disant est exploitable sans gpu nvidia ? (et sans avoir le haut de gamme amd)

C'est surtout que PhysX est complètement dispensable ont a les même effets proposés par des moteurs de physique tiers (ou un moteur proprio déjà implanté de base comme sur CryEngine par exemple) qui au moins fonctionne sur toutes les cartes graphiques.

C'est logique, c'est la physique pas une option. Quand tu desactives PhysX sur Batman, ton perso ne se met pas a traverser les décors, a taper dans le vide. C'est le moteur physX CPU qui fait le boulot.
 
Quand tu actives l'option, cela fait passer le calcul de la physique sur GPU (si tu as une Nvidia). Le gain de puissance qui l'on obtient alors est utilisé par les devs pour ajouter de nouveaux effets gourmands en puissance si ils sont exécuté CPU : eau dynamique, voiles qui bougent dans le vent, destruction plus poussée, particules plus avancées, ...
 
Les devs n'utilisent pas deux moteurs physiques différents. Cela serait la galère.

 
Tu te trompes parce que la manière dont sont présentées ces options dans les jeux est trompeuse. PhysX c'est un ensemble d'API qui doivent être intégrées au coeur du moteur du jeu. C'est par exemple ce qui peut faire que des caisses tombent quand tu fonces dedans, que le personnage peut sauter à une hauteur limitée, qu'il meure s'il tombe de trop haut... Tout ça fait partie de la simulation du monde et est pris en charge exclusivement par le CPU. PhysX n'est pas spécifique au PC, mais compatible également avec toutes les consoles.
 
Ensuite il y a GPU PhysX (très souvent simplifié en PhysX tout court dans les options). Ce sont des modules optionnels à PhysX qui permettent d'ajouter des effets graphiques qui n'ont pas trop d'importance directe sur le gameplay et la simulation du monde (par exemple animer des liquides, des gaz, des vêtements). Les modules GPU PhysX peuvent être accélérés par les GPU Nvidia ou tourner en mode CPU. Dans ce second cas ils sont en gros inutilisables tellement c'est lent (bien qu'il s'agisse de très bons candidats pour  profiter de tous les coeurs/threads des CPU et de leurs unités vectorielles, ils sont aussi peu optimisés que possible histoire de favoriser les GPU). Nvidia joue sur les mots entre PhysX et GPU PhysX, probablement pour que les joueurs pensent que tous les jeux dans lesquels apparaît le logo PhysX tournent mieux sur GeForce, d'où la confusion.
 
Sinon c'est un peu HS

Moi je constate surtout que dx12 demande plus de rigueur coté editeurs de jeux
Déjà que t'as pas envi d'acheter day one des jeux ubisoft finit à la truelle
Alors des jeux ubisoft dx12 ça va encore moins donné envie d'achat dayone
Avant que les pro amd et pro nvidia se fritte la gueule, faut déjà que les editeurs de jeux enfin surtout les feveloppeur de moteur de jeu : frostbite engine, unreal engine, ego engine, .... S'approprie ce fameux dx12
Nul doute que amd ou nvidia bosse déjà avec eux avec des 'blackbox' remplit d'engineer sample de leurs prochains gpu
 
Mais voilà je demande à voir les premiers jeux dx12 'in action' et leur premiers bug 'cas de figure'
Car pour le moment sorti de pauvre 'demo technique' non interractive.... Bof quoi

En faite plus que le support directX 12 je me demande combien de jeux vont ajouter le support des shaders asynchrones.
 
Star Citizen en directX 12 + support shaders asynchrones le gain de perfs  
après les graphismes explosion de la rétine

 
Le problème c'est que les effets physique surtout mit en avant sur gpu sont souvent de type éphémère et pas persistent (débris suite à explosion qui disparaissent au bout d'un laps de temps, impact sur surface qui disparaissent au bout d'un laps de temps)
 
Perso je préfère la biblio havok pensé multithread cpu et dont les effets sont plus 'persistant' (mouvement de tissu, destruction de structures, ....)
 
de toute façon physx gpu au jour d'aujourd'hui s'appuie sur "CUDA", mais je dirais qu'à terme (directx13 ?) certaines opérations lié à la physique pourrait bien retrouvé dans un cablage hardware "standardisé" à tout les fabricants pour une simple raison d'efficience  
ou le retour de la revanche du "PPU", reste à savoir si ce "ppu" à plus sa place du coté cpu ou du coté gpu (bon comme de toute façon à terme tout ce beau monde se retrouvera sur un même die)
 
mais dans la majorité des jeux le plus souvent pour le moment on a plus intérèt à filer le boulot au cpu qui a encore de la marge d'utilisation avec tout ce potentiel sous exploité avec tout ces core pas du tout à pleine charge, plutôt que le gpu qui en général est au taquet pour l'affichage (politique du tout à fond mode gros boeuf des gamers )