Khronos Group : Vulkan dans la voie de Metal et OpenCL en 2.1
Le Khronos Group a annoncé aujourd’hui une toute nouvelle API graphique qui va plus loin qu’OpenGL, sa technologie multiplateforme et ouverte exploitée par OS X, entre autres.
Vulkan est une API de bas niveau qui donne plus de contrôle aux développeurs. Ceux-ci peuvent notamment gérer la mémoire et le multi-threading de manière efficace. Le pilote de la carte graphique est donc moins sollicité et les performances s’en retrouvent améliorées. On retrouve la philosophie de Metal, l’API graphique de bas niveau d’Apple introduite avec iOS 8.
Vulkan est par ailleurs destiné aussi bien au mobile qu’aux systèmes de bureau. OpenGL a pour sa part une déclinaison OpenGL ES conçue spécialement pour les terminaux mobiles. « Valve et les autres membres de Khronos travaillent dur pour assurer que cette interface graphique haute performance soit disponible aussi largement que possible. Nous la voyons comme un composant essentiel de SteamOS et des futurs jeux Valve », a déclaré Gabe Newell, le patron du studio.
OpenGL et OpenGL ES ne sont pas abandonnés pour autant. Ils vont continuer à évoluer en parallèle et rester des API de plus haut niveau.
Le Khronos Group a également dévoilé OpenCL 2.1, une évolution de sa technologie permettant de confier des tâches de calcul à la carte graphique ou à une puce dédiée. Cette version introduit un nouveau langage de kernel basé sur un sous-ensemble de C++. Ce langage doit faciliter le travail des développeurs en les délestant de certains éléments de bas niveau, sans sacrifier les performances. OpenCL 2.1 et Vulkan partagent par ailleurs un nouveau langage intermédiaire, SPIR-V.
Des démos de Vulkan se tiendront à la GDC cette semaine. Les spécifications sont attendues pour plus tard dans l’année. Les spécifications provisoires d’OpenCL 2.1 sont quant à elles disponibles dès aujourd’hui.
[supprimé]
Beaucoup trop tard. La messe est déjà dite.
En particulier avec Apple qui absorbe la presque totalité de l'attention des développeurs de jeux sur mobile, donc peu de motivations pour OpenGL/OpenCL.
-
Metal, OpenCl, OpenGL , ce sont des usages différents: OUI. Je ne dis pas que OpenCL et Metal font la même chose. Mais mon point est que comme l'industrie est obnubilée par le "mobile" et que l'Argent est là où est Apple, ce sont les priorités d'Apple qui influencent l'ensemble de l'industrie informatique: l'ordi de bureau est assujetti aux priorités du mobile.
Cela m'ennuie particulièrement, car je préfèrerais voir OpenCL se développer et être adopté massivement pours les logiciels de rendus et imagerie, plutôt que le seul CUDA.
Je préférais un OpenGL très efficace plutôt que Mantle, car Mantle exclue de fait Linux. (même si j'apprécie le travail d'apple pour iOS)
Les investissements de l'industrie sont sur le mobile, cela aspire tout vers ce qui marche sur mobile, et manifestement ça sera Metal ou autre API propriétaire (directX12) ou ce que finira par faire Google pour faire du jeu (je ne pense pas que ça sera du standard), et c'est tout. Cela a un impact négatif sur OpenGL évidemment, mais aussi OpenCL (par ricochet), même sur ordi de bureau.
Il faut s'attendre à ce qu'Apple mette à jour Os X que en 2038 après la terraformation de Mars, limitant l'intérêt des développeurs d'améliorer leurs logiciels.
[supprimé]
la playstation 3 ou 4 resteront aux versions qu'elles ont. cela ne bougera pas.
On peut imaginer une PS 5, mais encore une fois, cela a très peu d'impact sur le "pc" (ou mac). Qu'importe le succès de la PS3 ou de la Wii, cela n'a même pas effleuré Microsoft et son Direct X sur windows, et Apple est resté tranquillement à OpenGL 3.x sur Os X pendant toute la période ps3-wii.
Les consoles n'affectent pas l'évolution des normes sur PC/Mac. C'est bien un soucis.
-
Steam n'impose pas OpenGL. Source oui, mais est ce que Source de Valve est assez pour influencer l'industrie ? Je ne le pense pas.
-
Mon point n'est pas de dénigrer OpenGL ou les consoles ou Steam ou tous les trucs où OpenGL/OpenCL marchent, bien au contraire. Mais qu'il ne faut pas s'attendre à une évolution rapide des systèmes et logiciels qu'on UTILISE sous prétexte que Khronos a (enfin) fait évoluer ses recommandations.
Le problème est que le manque d'investissement sur les os BUREAU (windows, os x, linux). L'industrie est focalisée sur le mobile, et cela signifie donc Mantle. Et Microsoft bien entendu emploie ses moyens à pousser DirectX. On peut donc espérer Google ?mais je crains que Google fasse la voie à la Apple, et créé son clone propriétaire de Mantle et non utiliser les évolutions d'OpenGL.
Mais ce n'est pas réellement mon soucis. Mon soucis est le MAC et le principe que si l'industrie (dont Apple) reste focalisée que sur le mobile, l'évolution d'OpenCL (bien + importante que GL pour moi) ne sera PAS une priorité.
-
le revenu n'est pas tant la question, les entreprises veulent la croissance. Ce qui croit actuellement, c'est le mobile.
[supprimé]
[supprimé]
Mantle est desormais mort.
Apple est condamné. DOOOOOOOmed.
c'est ici : http://www.lesnumeriques.com/amd-laisse-cote-mantle-fait-valoir-directx1...
Mantle de côté, DirectX12 en priorité
Bonsoir à tous,
après avoir lu les commentaires précédents, je voudrai apporter quelques précisions.
Tout d'abord, ni la PS3 ni la PS4 utilisent OpenGL. Il y a bien eu une implémentation OpenGL sur PS3 mais, à ma connaissance, elle a été très peu utilisée. Sony fourni une API bas niveau pour tout ce qui est graphique, dans la même veine que Mantle, DirectX12 ou Metal (et oui, le concept n'est pas neuf).
La XOne, bien qu'utilisant DirectX, propose une API étendue qui permet, là aussi, d'accéder aux fonctionnalités bas niveau. C'était déjà le cas sur X360.
Bien que les deux consoles aient une architecture très proche, le GPU de la PS4 est quand même plus performant : c'est purement hardware et une amélioration des driver de la XOne ne pourra jamais corriger ce fait.
Si Vulkan est le nouveau nom de glNext, alors il me semble que AMD a fourni une partie de Mantle pour construire cette nouvelle API.
Toujours est-il que c'est une bonne nouvelle : beaucoup d'appareils utilisent OpenGL et on peut espérer que Vulkan sera lui aussi adopté de façon massive.
[supprimé]
correction de faute
Je ne peux pas parler pour OpenGL, Mantle et Vulkan.
Par contre, pour OpenCL, je crois que la messe est très loin d'être dite. S'il n'y avait que nVidia et ATI, CUDA eut pu l'emporter, mais il y a Intel et ses puces graphiques de plus en plus présentes. Or CUDA est propriétaire, tant Intel qu'ATI doivent donc opter pour OpenCL.
Jusqu'il y a peu, les cartes graphiques nVidia offrait des performances moyennes, mais assez soudainement (et sans changement radical de technologie) les dernières cartes nVidia (960, 970 et 980 GTX) ont fait un bond dans les performances OpenCL, dépassant même les cartes AMD.
nVidia n'a pas "optimisé" ses cartes en OpenCL si elle était certaine de l'emporter avec CUDA seul et ça me parait logique. Les développeurs d'application à large audience qui peuvent tirer parti du GPGPU (effet sur les vidéos, ...) ont tout intérêt à choisir OpenCL, surtout que les PCs/Mac sans cartes graphiques dédiées sont de plus en plus nombreux (carte Intel).
Pour les applis purement GPGPU, CUDA à une avance certaine mais OpenCL offre quand même des possibilités intéressantes. Les jeux sont encore ouverts.
Très bonne nouvelle: OpenGL accuse depuis trop longtemps son age, un age ou le GPU était forcément en accès synchrone, disposait de sa propre mémoire, d'un jeu de commandes limité et où la CPU déleguait les calculs et émettait des commandes en séquence vers le GPU qui à l'époque les exécutait en séquence mais nettement plus vite, rien de plus.
Aujourd'hui les GPU peuvent faire plein de calculs en parallèle, la mémoire est de plus en plus unifiée ou du moins partagée entre CPU et GPU, les commandes viennent et remontent en parallèle. Le modèle d'OpenGL datant de 25 ans est devenu l'API qui créé le goulet d'étranglement (et la complexité de la pile des technos) désormais.
Vulkan semble etre un OpenGL 4.0 massivement parallèlisé avec un byte code normalisé pour les shaders / calcul OpenCL, le tout en restant une API multiplaforme dont les spécifications des interfaces sont disponibles à tous pour permettre différentes implémentations sans dépendre forcément d'une brique propriétaire.
Appeler ça OpenMantleMetalCL, si vous préférez. Le mot clé important ici, c'est l'aspect Open de cette API qui fait converger toutes les évolutions de briques technos récentes dans le domaine autour d'une API taillée pour les besoins d'aujourd'hui, et non engoncée dans un modèle construit sur des besoins de y'a 25 ans ou sur un modèle récent mais propriétaire ou mono-plateforme.
KronosGroup ayant réussi à sortir OpenGL de sa léthargie coincée en 1.x pendant 10 ans pour en faire l'API multiplateforme de référence pour le 3D, le son en 3D, le calcul déporté, j'ai plutôt confiance dans leur capacité à créer l'impulsion à ce saut générationnel nécessaire.
Dans tous les cas, y'a une demande pour une telle API multiplateforme indépendante des vendeurs de moteurs et autres briques trop spécialisées sur les cas d'usage principaux...
Merci pour cet éclairage.
J'ai eu la chance de vivre l'évolution des CPU, où on gagnait en gros un facteur 10 de puissance tous les 5 ans.
Certes, pour des applications plus limitées, le GPGPU vient de connaitre ces 5 dernières années une progression encore plus importante. Cette évolution est telle qu'elle permet pour quelques centaines d'euros de rivaliser avec des calculateurs qui en valait au mois cent fois plus voici à peine 5 ans.
De plus, jusqu'à l'avènement d'OpenCL, il n'était pas aisé de programmer une application capable d'exploiter les différents coeurs, même d'un CPU. Ici, tout est transparent pour le programmeur.
Qui aurait dit, voici quelques années à peine qu'une carte graphique à 400 euros serait plus de 10x plus performante qu'un processeur du même prix ?
Bien sûr, nous ne connaitrons pas une telle révolution tous les 5 ans. Néanmoins, les dernières cartes nVidia (9x0 GTX) chauffent tellement peu et sont tellement performantes qu'elles ouvrent la voie d'abord à leurs grandes soeurs "Pro" et à de nouvelles déclinaisons futures.
Rappelons qu'elles sont toujours gravées en 28 nm. Imaginez ce que donnerait, ne fut-ce qu'en terme de consommation le passage à 14 nm ou même à 22 nm !
Les [GP]GPU sont (très nettement) plus performantes qu'un CPU sur un segment particulier de calculs, le calcul par flux de données, et c'est parfaitement logiquement puisque les GPU modernes fédèrent en gros bien plus massivement des processeurs vectoriels autour d'un bus de mémoire qu'il n'y a de pipeline vectoriels (dédiés aux instructions SIMD) dans un CPU.
Le CPU devant également implémenter le support plus générique pour permettre d'autres types de calcul, il ne peut pas s'offrir le luxe d'offrir 512, 1024 ou plus encore d'unités vectorielles en parallèles.
Ce qui explique la tentation d'utiliser ceux du GPU plutôt que ceux du CPU, mais explique également pourquoi on ne peut déléguer facilement tout type de traitement à un GPGPU.
L'avenir dira qui du CPU ou du GPU va un jour fusionner dans l'autre, ou si finalement ce duo est amené à continuer de collaborer de plus en plus étroitement...
Bref. En tout cas, voir qu'il y a une demande *et* une proposition d'API multi-patforme modernisée pour le pilotage des GPU est une bonne nouvelle.