Actualités informatiques du 21-03-2016

AMD a mis en ligne les pilotes Radeon Software 16.3.1 Hotfix. Par rapport aux 16.3 on a droit à un profil CrossFire mis à jour pour Hitman ainsi qu'a un support pour le dernier Need for Speed. Pour le téléchargement et plus de détails rendez-vous sur cette page ! .

En janvier dernier, Microsoft indiquait que le support complet des futurs processeurs ne serait assuré que sous Windows 10. Il était dans le même temps précisé que concernant Skylake le support Windows 7 et 8.1 ne serait total que jusqu'en juillet 2017.

Au-delà seules les failles les plus critiques concernant ces configurations seront comblées, à condition que la mise à jour n'entrave pas la fiabilité ou la compatibilité sur d'autres plates-formes, ce jusqu'en janvier 2020 pour 7 et janvier 2023 pour 8.1.

Comme l'indique cette page  cette date a été repoussée d'un an puisqu'il est désormais question de juillet 2018.

Lors d'une session d'AMD dédiée à DirectX 12, Oxide est revenu sur son implémentation du multi engine ("Async Compute") dans Ashes of the Singularity. L'occasion de comprendre comment cette fonctionnalité est exploitée pour booster les performances sur les GPU qui sont capables de prendre en charge plusieurs files de commandes.

Exploiter le multi engine pour booster les performances implique de traiter simultanément différentes tâches. Aucun GPU n'étant actuellement capable de traiter plusieurs files de type graphiques en parallèle (mais cela pourrait changer dans le futur), il y a deux groupes de tâches qui peuvent profiter d'un boost de performances dans DirectX 12 : les copies et les compute shaders. Les premières auront surtout de l'intérêt dans le cadre du multi-GPU et ce sont donc les seconds auxquels les développeurs vont devoir s'intéresser. La première étape est alors de déterminer quels sont ces compute shaders qui peuvent être isolés du reste du rendu et exécutés simultanément via une file dédiée.

Dans le cas du moteur d'Ashes of the Singularity (AotS) il y a 2 larges pans du rendu qui sont traités via des computes shaders : l'éclairage et les ombres d'une part et le post processing d'autre part. Ils représentent à peu près 30% du temps de rendu d'une image typique et semblent donc être de bons candidats. C'est particulièrement le cas pour le post processing qui intervient en fin de rendu et peut sans problème être traité pendant que le travail commence sur une nouvelle image.

Tout du moins c'est la théorie basique. En pratique la prise en compte par le moteur graphique du rendu de plusieurs images en parallèle est un peu plus complexe. Seules les files graphiques peuvent présenter l'image au moteur d'affichage, les files compute en sont incapables. Or il est compliqué, voire impossible suivant le moteur, d'alterner des commandes liées à des images différentes à l'intérieur d'une même file. En d'autres termes, de demander l'affichage de l'image 1 au milieu des commandes de rendu de l'image 2 n'est pas si simple.

La solution est d'exploiter une seconde file graphique qui servira exclusivement à présenter les images en vue de leur affichage. Reste que si les pilotes n'ont aucun problème avec cette possibilité, les GPU actuels ne sont pas capables de gérer deux files graphiques en parallèle. Or si la file secondaire doit attendre que la principale soit traitée avant d'être exécutée, cela entraîne une image de latence supplémentaire.

Oxide a cherché à éviter ce désagrément en faisant en sorte créer un maximum d'opportunités d'alternance entre les deux files graphiques via une décomposition du rendu principal de l'image en suffisamment de groupes de commandes. C'est peut-être légèrement moins efficace sur le plan des performances mais entre l'exécution de ces plus petits groupes de commandes, Windows pourra alterner entre les files graphiques et ainsi insérer la commande de présentation de l'image. Au lieu d'une image de latence supplémentaire, Oxide parvient ainsi à ne l'augmenter que de 1/3 à 1/2 image.

Reste le second point qui peut potentiellement être traité en parallèle via une file compute : l'éclairage et les ombres. Il est plus délicat à aborder et Oxide rentre moins dans les détails. Notre compréhension est que seule une partie passe dans une file compute : le filtrage des ombres qui a un coût élevé. Le problème est que cette phase ne peut pas être traitée en parallèle du reste du rendu qui en a besoin. Pour pouvoir malgré tout la paralléliser, Oxide a recours à une approximation : pour chaque image, les ombres sont issues de l'image précédente. Dans un jeu tel qu'AotS, cela passe presqu'inaperçu, mais cette approche ne pourrait probablement pas être utilisée dans un fps par exemple.

Au final, ce recours au multi engine dans AotS permet de gagner environ 15% de performances (voire un peu plus) au prix d'une demi-image de latence supplémentaire (voire un peu moins), ce qui représente un bon compromis. Tout du moins pour les Radeon qui profitent des avantages, contrairement aux GeForce qui actuellement se contentent des désavantages de cette approche.

Vous pourrez retrouver l'intégralité de la présentation d'Oxide ci-dessous :

 

 

Futuremark, dont le produit le plus célèbre est sans aucun doute 3DMark, a décidé de mettre les bouchées doubles sur le développement d'une nouvelle suite de tests dédiée à la réalité virtuelle (VR). La GDC était l'occasion pour le finlandais de détailler ses plans et d'essayer de convaincre l'industrie de l'utilité de sa solution baptisée VRMark.

Les investissements conséquents opérés récemment par les différents acteurs de l'industrie envers le développement de la réalité virtuelle entretiennent l'idée du développement d'un large marché et donc de la multiplication des casques dédiés et des systèmes exploités à cet effet. Ce type d'environnement est idéal pour les spécialistes du benchmark qui tirent la majorité de leurs revenus de l'exploitation professionnelle de leurs outils d'évaluation.

Tout comme Basemark, Futuremark travaille ainsi depuis quelques temps à la mise au point d'un benchmark dédié à la VR en essayant d'en prendre en compte un maximum d'éléments. Contrairement à la 3D temps réel classique, la VR n'a pas simplement besoin d'un certain niveau de performances, mais a également des exigences en termes de régularité et de latence. Des aspects qui en fait sont importants pour tout type d'affichage, même si dans une moindre mesure, mais c'est l'arrivée de la VR et du marché potentiellement énorme qu'elle représente qui pousse Futuremark et Basemark à aller plus loin que précédemment.

Une version preview de VRMark est proposée depuis quelques temps déjà, mais la version finale va aller beaucoup plus loin, c'est d'ailleurs déjà en partie le cas pour les versions beta que nous évaluons et qui sont fournies avec un équipement externe chargé d'observer la latence. Cet équipement est constitué d'un oscilloscope et d'une photodiode pilotés par VRMark pour mesurer la latence de l'application au photon, que ce soit pour un casque de réalité virtuelle (HMD - Head Mounted Display) ou pour un moniteur classique.

Futuremark développe également un équipement supplémentaire équipé d'un moteur qui va faire bouger les HMD de manière contrôlée pour aller plus loin et mesurer la latence de la prise en compte du mouvement de la tête. D'autres tests sont prévus par exemple pour mesurer la précision du système de positionnement ou encore la qualité du time warping, cette technique qui consiste à reprojeter l'image rendue pour simuler un angle de vue légèrement différent. Abuser du time warping peut réduire la latence et améliorer les performances mais conduire à des défauts visuels importants.

Mais évidemment à la base de VRMark nous retrouvons un benchmark 3D qui reprend d'ailleurs des scènes aperçues dans les précédents 3DMark. Des modifications plus ou moins importantes ont cependant dû être apportées pour la VR, par exemple l'abandon de certains effets de post processing tels que la simulation de la profondeur de champ ou les réflexions liées aux lentilles.

La modification principale concerne cependant le niveau de performances visé. Traditionnellement un 3DMark va chercher à pousser les cartes graphiques dans leurs derniers retranchements quitte à faire appel à des effets graphiques au coût disproportionné. Pour VRMark le but est d'obtenir une expérience réaliste. Deux niveaux de qualité sont proposés. Le premier cherche à obtenir au moins 90 fps en permanence sur les systèmes recommandés par Oculus et HTC (GTX 970 ou R9 290, alors que le second augmente quelque peu la charge et a plutôt besoin d'une GTX 980 Ti pour maintenir les 90 fps. Pour atteindre ce niveau de performances avec un contenu relativement riche, Futuremark a simplifié la géométrie ou encore réduit le nombre de particules. Deux aspects qui permettent des gains conséquents sans trop nuire au résultat final.

Une version encore plus simple est par ailleurs envisagée pour la VR sur mobile. Enfin, Futuremark développe une version haut de gamme de VRMark qui fera appel à DirectX 12 et Vulkan ainsi qu'un test spécifique à la réalité augmentée. Si aucune date n'est fixée pour l'arrivée de tous ces outils, il est évident que Futuremark fait le maximum pour les sortir le plus rapidement et profiter de l'exposition liée au lancement des premiers HMD.

Vous pourrez retrouver l'intégralité de la présentation de Futuremark ci-dessous :