Les contenus liés au tag DirectX 11

AFDS: Microsoft annonce C++ AMP

Publié le 17/06/2011 à 00:35 par Damien Triolet

Microsoft a choisi l'AFDS pour présenter une nouvelle version de C++ optimisée pour l'exploitation des GPUs, et potentiellement de tout autre accélérateur. Baptisée AMP pour Accelerated Massive Parallelism, cette extension vient compléter C++0x et la Parrallel Patterns Library (PPL) pour faciliter l'écriture du code qui va inclure des fonctions destinées à être accélérées par le GPU.


Herb Sutter, Software Architect chez Microsoft et guru du C++, a insisté sur l'importance de ne pas complexifier le langage et de se contenter d'ajouts aussi simples que possibles en profitant de la signification implicite qu'ils peuvent amener pour laisser le compilateur se charger de toute la lourdeur qui est liée à l'utilisation de tels accélérateurs.

Seules deux nouveautés font ainsi leur apparition au niveau du langage. La première, array_view, permet de représenter une mémoire non uniforme, incohérente et/ou disjointe sans avoir à spécifier explicitement des .copy()/.sync(). Un niveau d'abstraction qui simplifiera nettement le code.

La seconde se nomme restrict(). Comme son nom l'indique, elle permet de spécifier des restrictions liées à une certaines architecture pour certaines fonctions. Celles-ci concernent les limitations inhérentes aux accélérateurs actuels et indiquent implicitement qu'il s'agit d'un morceau de code au parallélisme important qui pourra être exécuté sur le GPU. Dans la première version de C++ AMP préparée par Microsoft, il est question de viser l'API maison DirectCompute 11 en utilisant simplement restrict(direct3d), restrict(cpu) étant le mode par défaut implicite. Dans le futur Microsoft envisage un restrict(pure) qui n'aurait aucune restriction mais permettrait de déclarer le parallélisme au compilateur.


A gauche du code classique, à droite en version C++ AMP.

Aucun autre élément de langage ne sera introduit, tout le reste étant implicite. Par exemple attacher une variable à "const" sera interprété comme du "read only". Microsoft précise cependant à ce sujet qu'il n'y a actuellement aucun moyen similaire pour spécifier que des éléments sont "write only", ce qui pourrait être utile dans le futur.


Une démonstration réalisée par Microsoft a mis en avant la possibilité, avec un seul exécutable, de profiter de tout type de matériel : CPU, GPU, APU, APU + GPU, double GPU…

Tout ceci devrait faire son apparition dans la prochaine version de Visual Studio. Par ailleurs Microsoft entend faire de C++ AMP un standard ouvert de manière à ce qu'il puisse être exploité sur différentes plateformes, que ce soit au niveau de l'interface compute ou du système d'exploitation. Herb Sutter a ainsi directement annoncé travailler avec AMD de manière à ce que ce dernier puisse en proposer une version FSA. ARM semble également intéressé par cette évolution. De son côté, Nvidia semble avoir été surpris par cette annonce et s'est empressé de publier sur son blog accueillir toute évolution qui facilite l'exploitation de la puissance de calcul des GPUs en précisant que la version d'AMP initiale visant DirectCompute11, ses GPUs en profiteraient également. Pas un mot sur une version CUDA d'AMP par contre…

PCI Express 3.0 pour Ivy Bridge

Publié le 01/04/2011 à 21:02 par Guillaume Louel
Imprimer

Nos confrères de Semi Accurate viennent de publier un slide issue de la roadmap d’Intel . Dédié aux processeurs Ivy Bridge (le pendant en 22nm de l’actuel Sandy Bridge lancé en janvier dernier, et attendu pour début 2012), il confirme la rumeur voulant que ces processeurs disposeront bel et bien de la compatibilité PCI Express 3.0.


Le slide confirme également d’autres détails plus ou moins attendus, comme le support natif de l’USB 3.0 (enfin !) dans le chipset série 7 dédié à Ivy Bridge. La puce graphique évoluera également avec le support (enfin !) de DirectX 11 (la gamme Core Sandy Bridge n’étant que DirectX 10.1). Pas de confirmation en revanche d’une autre rumeur lancée par nos confrères de Semi Accurate, à savoir la présence de mémoire dédiée à la partie graphique du processeur, directement à l’intérieur du package . Peut être pour corriger le problème de performances que nous avions relevé dans notre test en janvier lorsque partie processeur et partie graphique sont stressées en simultanée. Un problème qu’Intel nous a confirmé avoir reproduit, sans pour autant pouvoir nous donner d’explication sur sa raison (la saturation du ring-bus étant une hypothèse plausible).

Top articles