Steam se prépare à l'arrivée des jeux exploitant Vulkan 1.0

Steam se prépare à l’arrivée des jeux exploitant Vulkan 1.0

Une bibliothèque après l'autre...

Avatar de l'auteur
Kevin Hottot

Publié dans

Logiciel

19/02/2016 2 minutes
51

Steam se prépare à l'arrivée des jeux exploitant Vulkan 1.0

La nuit dernière, Valve a poussé une nouvelle mise à jour sur le canal bêta du client Steam, accompagnée par la version 2.63 de SteamOS. Toutes deux ont pour point commun d'apporter les bases du support de l'API Vulkan.

Au début de la semaine, le Kronos Group levait le voile sur la version 1.0 de son API Vulkan. Celle-ci ambitionne de répondre à un maximum d'usages sur autant de plateformes que possible, tout en permettant la manipulation de données graphiques à bas niveau. On pourrait ainsi la vulgariser comme étant un équivalent multiplateforme du Mantle d'AMD, ou de Metal chez Apple.

L'initiative est d'ores et déjà soutenue par AMD ou NVIDIA, et Qt est récemment venu s'ajouter à cette liste. C'est aujourd'hui au tour de Valve de marquer son intérêt, via la diffusion de deux mises à jour pour ses produits. La première concerne le canal bêta du client Steam. Dans sa dernière itération, il est question de l'ajout du support préliminaire de l'overlay pour les jeux exploitant Vulkan, ainsi que l'implémentation de libvulkan dans la version dédiée à Linux.

SteamOS profite aussi indirectement du même genre d'amélioration. Dans sa mouture 2.63 déployée la nuit dernière, Valve a intégré les pilotes NVIDIA en version 355.00.27 pour Linux. Il s'agit pour rappel de la variante apportant le support en bêta des fonctionnalités de Vulkan, pour les cartes équipées d'un GPU de la génération Kepler ou Maxwell. La liste des modèles supportés est accessible à cette adresse. Les plus chanceux pourront essayer tout cela au cours d'une partie de The Talos Principle, l'un des rares titres exploitant déjà en partie l'API.

Écrit par Kevin Hottot

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (51)


De ce que j’ai pu en lire “the Thalos principale” n’utilisent pas vraiment les capacités de Vulkan, ça a plus été fait comme un défi du genre “regardez ça marche” Je n’ai plus la source mais c’était dans un article posté dans un commentaire de la news sur vulkan justement ^^.


Quelle est la différence ?


Vulkan peut et DOIT en glisser une belle à Microsoft et DirectX, qui doit descendre de son piédestal. C’est peut-être un tournant pour Linux qui a une très belle carte à jouer dans cette histoire…! Je suis à 100% pour


Bah il n’y pas d’amélioration particulière en terme de performances^^ (ça n’exploite pas les forces de vulkan qui sont grosso modo les même que celle de dx12 à savoir pouvoir alléger le cpu pour afficher beaucoup plus de choses)


Sachant que comme dit dans d’autres news vulkan n’est que l’api graphique quand dx12 est bien plus que ça, la comparaison ne peut se tenir que sur le rendu 3d.








Mirage_FL a écrit :



Vulkan peut et DOIT en glisser une belle à Microsoft et DirectX, qui doit descendre de son piédestal. C’est peut-être un tournant pour Linux qui a une très belle carte à jouer dans cette histoire…! Je suis à 100% pour





Tout à fait.

D’ailleurs il serai temps que ça presse le pas car quand les jeux sortiront uniquement pour DX12, même les joueurs ne voulant pas de Windows 10 seront trainés de force par les cheveux pour migrer afin continuer de jouer.

Le monopole de Microsoft est néfaste à tout les étage et ça commence à même déranger ceux qui “n’ont rien à cacher”.



Donc Vulkan va s’intercaler entre le jeu et le GPU part l’intermédiaire d’OpenGL si j’ai bien tout compris. ça serait bien aussi que ça fonctionne sur Mac avec les IGP Intel. Encore faut-il que les jeux soit a jour évidement…



 


Il faudra 3 ou 4 api au lieu d’une pour remplacer dx, mais je trouve normal de séparer les api par domaine.








noraj a écrit :



les forces de vulkan qui sont grosso modo les même que celle de dx12 à savoir pouvoir alléger le cpu pour afficher beaucoup plus de choses









noraj a écrit :



vulkan n’est que l’api graphique quand dx12 est bien plus que ça





Ton avis m’intéresse, mais tu ne te contredis pas entre tes deux commentaires?



J’ai voulu vulgariser ^^ mais en gros vulkan se compare à direct3D


Si c’est ça, il était temps…


Ne faut-il pas plutôt comparer Vulkan à Direct3D 12 ?



edit : grilled.


De plus en plus de bon jeux sur linux… Ca ce serait excellent








noraj a écrit :



J’ai voulu vulgariser ^^ mais en gros vulkan se compare à direct3D





Ok, g pigé, tu parlais de dX comme interface pour autre chose que le graphisme.



Du coup, c’est plutôt une bonne chose ce petit, s’il peut rivaliser en affichage avec le modèle proprio.









fullsun a écrit :



Si c’est ça, il était temps…





OpenGL est le concurrent de Direct 3D







Vengeful-frog a écrit :



Ne faut-il pas plutôt comparer Vulkan à Direct3D 12 ?



edit : grilled.







Direct3D 12 permet effectivement d’attaquer le GPU au plus bas niveau.



J’ai envie de dire : OpenGL + Vulkan = Direct3D 12 mais je ne suis pas complètement sur de moi <img data-src=" />



C’est rigolo un libriste, à chaque news de ce type ils peuvent écrire le même commentaire.


tant que X11 est pas complétement dégagé au profit de Wayland sur les distribs grand public, ça va pas être facile ..








Hugues1337 a écrit :



C’est rigolo un libriste, à chaque news de ce type ils peuvent écrire le même commentaire.





Les libristes sont des optimistes irrécupérables. Ils ne perdent jamais espoir.









Hugues1337 a écrit :



C’est rigolo un libriste, à chaque news de ce type ils peuvent écrire le même commentaire.



Je ne suis pas un libriste mais je suis aussi motivé que lui (même si certaines expressions ne sont pas de mon goût).



Vive la diversité, vive la saine concurrence.



Vivement que le pilote Vulkan rejoigne la branche courante, et qu’il soit déployé un peu partout !


OpenGL n.existe plus sous sa vieille numérotation, il est renommé et remplacé par vulkan.



Directx inclue bien plus d’api, vulkan se concentre globalement sur la 3D.



OpenGL – direct3d

OpenAL – directsound

OpenCL – directcompute

Etc








DahoodG4 a écrit :



OpenGL n.existe plus sous sa vieille numérotation, il est renommé et remplacé par vulkan.



Directx inclue bien plus d’api, vulkan se concentre globalement sur la 3D.



OpenGL – direct3d

OpenAL – directsound

OpenCL – directcompute

Etc





Donc il suffirait d’avoir un OpenXL qui regroupe tout pour pouvoir concurrencer avec DirectX ?









Mirage_FL a écrit :



Vulkan peut et DOIT en glisser une belle à Microsoft et DirectX, qui doit descendre de son piédestal. C’est peut-être un tournant pour Linux qui a une très belle carte à jouer dans cette histoire…! Je suis à 100% pour









chris.tophe a écrit :



De plus en plus de bon jeux sur linux… Ca ce serait excellent









gokudomatic a écrit :



Les libristes sont des optimistes irrécupérables. Ils ne perdent jamais espoir.





Malheureusement, ce n’est pas forcement les API 3D qui sont un frein à l’arrivée massive des jeux sous Linux. Par exemple, Blizzard utilise pour ses jeux des API 3D déjà portables sur d’autres systèmes (OpenGL), et a déjà fait une patie du boulot puisque leurs titres tournent sous Mac OS X. Mais la firme a récemment dit (environ 1 an) que développer pour le pingouin ne les intéressait pas car le marché est trop faible.&nbsp;

On est toujours dans le fameux dilemme : on sortira du contenu quand vous serez populaire / on sera populaire quand vous fournirez du contenu.

L’e-spoir est à chercher du côté d’initiative telle que SteamOS, c’est à dire sortir un écosystème complet permettant aux client de voir un intérêt : on vous propose du jeu sur PC aussi confortable que sur console. Pour ça, on vous file un OS avec une belle interface, le contenu de notre catalogue, une manette, et des machines “certifiées”.

&nbsp;









kikoo26 a écrit :



Donc il suffirait d’avoir un OpenXL qui regroupe tout pour pouvoir concurrencer avec DirectX ?





Il existe SDL pour çà.



Open GL existe toujours y’a plein de cas où Vulkan ne sera pas intéressant face à openGL.


Donc, OpenGL (haut niveau) pourrait continuer à vivre malgré l’arrivée de Vulkan (bas niveau) sans que cette situation ne soit source de problème pour l’un comme pour l’autre. Et dans DirectX 12, c’est uniquement du bas niveau ou on pourra faire comme avant (haut niveau) ?


J’ai bon espoir aussi pour vulkan , éventuellement quitter windows ne me déplairais pas mais y a juste un truc qui me chiffonne , déjà que AMD peine avec ses drivers crimson sous directX , ça va donner quoi si il leur faut gérer les deux sous windows (no troll) , parce que bon les annonces en fanfare d’AMd me laisse de glace désormais et vu le peu de com qu’ils ont avec les devs (le couac avec bethesda et le patch 1.3 pour le CFX laisse des traces et montre combien tout est à refaire en com chez amd)



Pour linux quid des drivers de base pour la carte gfx vu que vulkan ce n’est que la 3d…

Parce que bon dans l’état actuel c’est pas joyeux chez mister RED leur driver officiel



Bref y a du boulot encore mais ça avance bien


Pas tout a fait ça, Vulkan et OpenGL sont deux API qui permettent d’utiliser la carte graphique. Les applications utilisant Vulkan ne passent plus du tout par OpenGL, au contraient elle permettent de faire des actions de plus bas niveau.

&nbsp;







DahoodG4 a écrit :



OpenGL n.existe plus sous sa vieille numérotation, il est renommé et remplacé par vulkan.&nbsp;



Il est prévu que OpenGL continue d’exister, car si certains jeux ont intérêt d’aller au plus bas niveau, ce n’est pas le cas que la majorité des application 3D pour qui la complexité de la tache n’en vaut pas la peine.









Vengeful-frog a écrit :



Donc, OpenGL (haut niveau) pourrait continuer à vivre malgré l’arrivée de Vulkan (bas niveau) sans que cette situation ne soit source de problème pour l’un comme pour l’autre. Et dans DirectX 12, c’est uniquement du bas niveau ou on pourra faire comme avant (haut niveau) ?







D’après ce que j’en ai compris, OpenGL représente quand même une source de coût non négligeable pour les constructeurs de GPU car sa complexité rends l’optimisation difficile et coûteuse. Sans compter les x versions de l’API qu’il faut gérer et supporter.



Mais OpenGL étant plus simple à utiliser, cette API pourrait rester en usage pour tout ce qui n’a pas besoin de performances ou de contrôle. On peut imaginer que OpenGL pourrait devenir à terme une simple bibliothèque construite sur la base de Vulkan.



Et des gens se posaient déjà cette question il y a 16 ans, et la réponse était déjà la même.





&nbsp;Posted 13 September 2000 - 09:10 PM&nbsp;&nbsp;&nbsp;&nbsp;



&nbsp;Check out SDL (www.libsdl.org).&nbsp;

&nbsp;

&nbsp;SDL is basically the same sort of functionality as you find in DirectX (Sound, Networking, Input, Surface Drawing, etc), but portable (uses DirectX under Windows, other technologies under other platforms (Linux, MacOS, BeOS). I find the interface is often much nicer to work with than DirectX, even if you are going to only deploy on Windows.&nbsp;



&nbsp;&nbsp;http://www.gamedev.net/topic/25493-alternative-to-directinput/&nbsp;&nbs…


Tu feras comme RED, tu passeras de rouge à vert. :p








Winston67 a écrit :



J’ai bon espoir aussi pour vulkan , éventuellement quitter windows ne me déplairais pas mais y a juste un truc qui me chiffonne , déjà que AMD peine avec ses drivers crimson sous directX , ça va donner quoi si il leur faut gérer les deux sous windows (no troll) , parce que bon les annonces en fanfare d’AMd me laisse de glace désormais et vu le peu de com qu’ils ont avec les devs (le couac avec bethesda et le patch 1.3 pour le CFX laisse des traces et montre combien tout est à refaire en com chez amd)



Pour linux quid des drivers de base pour la carte gfx vu que vulkan ce n’est que la 3d…

Parce que bon dans l’état actuel c’est pas joyeux chez mister RED leur driver officiel



Bref y a du boulot encore mais ça avance bien







Justement, Vulkan sera beaucoup plus facile à gérer (et surtout à optimiser) pour les constructeurs de GPU que les API traditionnelles tout en permettant des gains de performances.



Ce n’est d’ailleurs pas pour rien que c’est AMD qui est à l’origine de Vulkan. C’est un bon moyen de contrecarrer les gros moyens de nVidia dans le développement des drivers.





Pour linux quid des drivers de base pour la carte gfx vu que vulkan ce n’est que la 3d…





L’accélération graphique tends à utiliser de plus en plus les API 3D.









sr17 a écrit :



Justement, Vulkan sera beaucoup plus facile à gérer (et surtout à optimiser) pour les constructeurs de GPU que les API traditionnelles tout en permettant des gains de performances.



Ce n’est d’ailleurs pas pour rien que c’est AMD qui est à l’origine de Vulkan. C’est un bon moyen de contrecarrer les gros moyens de nVidia dans le développement des drivers.







Je croyais que c’était uniquement parce qu’AMD n’arrivait plus à suivre en termes de perf et que donc il fallait optimiser les programmes toujours plus. <img data-src=" />









Vengeful-frog a écrit :



Je croyais que c’était uniquement parce qu’AMD n’arrivait plus à suivre en termes de perf et que donc il fallait optimiser les programmes toujours plus. <img data-src=" />






OpenGL est devenu un fourre tout qui aboutit finalement à un bouzzin très complexe (je plains les dev de drivers openGL). Avec vulkan c'est pas bien compliqué, tu écris ce que tu veux dans la ram du GPU et tu en fais ce que tu veux directement sur GPU. Le boulot d'optimisation repose maintenant entièrement sur le programmeur et non la qualité des drivers...&nbsp;d'où la cohabitation certaine avec OpenGL








Vengeful-frog a écrit :



Je croyais que c’était uniquement parce qu’AMD n’arrivait plus à suivre en termes de perf et que donc il fallait optimiser les programmes toujours plus. <img data-src=" />







En fait, les drivers conditionnent pour partie les performances d’une carte graphique. Et plus les API sont complexes, plus cela demande de gros moyens pour les optimiser.



Mais ce n’est pas le seul problème. Malgré leur degré d’optimisation, cet empilement de couche graphique de haut niveau devenait un goulet d’étranglement pour les performances.



Donc au final, AMD a fait d’une pierre deux coup : faire avancer les performances d’une manière générale et diminuer le coût de production d’un driver performant.









bobdu87 a écrit :



OpenGL est devenu un fourre tout qui aboutit finalement à un bouzzin très complexe (je plains les dev de drivers openGL). Avec vulkan c’est pas bien compliqué, tu écris ce que tu veux dans la ram du GPU et tu en fais ce que tu veux directement sur GPU. Le boulot d’optimisation repose maintenant entièrement sur le programmeur et non la qualité des drivers… d’où la cohabitation certaine avec OpenGL







D’ailleurs, cela permettra effectivement aux programmeurs d’optimiser mieux et plus facilement. Parce que pour un programmeur qui veut tirer des performances, les API de haut niveau font ch*.



Avec Vulkan, on a vraiment l’impression de coller mieux au fonctionnement des GPU.









sr17 a écrit :



D’ailleurs, cela permettra effectivement aux programmeurs d’optimiser mieux et plus facilement. Parce que pour un programmeur qui veut tirer des performances, les API de haut niveau font ch*.



Avec Vulkan, on a vraiment l’impression de coller mieux au fonctionnement des GPU.







Est-ce que ca veut dire que le développeur pourrait lui même revoir (implémenter) l’algo d’un appel OpenGL par exemple ?



@bobdu87

@sr17



Please don’t feed the trolls! <img data-src=" />



Ou plutôt merci. Je croyais vraiment que la motivation principale d’AMD était de réduire la nécessité de cartes 3D plus puissantes parce que la société connaît des difficultés pour suivre ses concurrents.


AMD a toujours fait des cartes bien foutu , bien plus que son concurrent (demi troll) , c’est juste les drivers et la com qui sont à la ramasse et quand les jeux n’utilisent pas des technos du géant vert



peut on espérer la fin du un jeu AAA , un driver ?








CryoGen a écrit :



Est-ce que ca veut dire que le développeur pourrait lui même revoir (implémenter) l’algo d’un appel OpenGL par exemple ?





Le but c’est surtout de ne pas avoir besoin de ses appels… plus besoin binding par exemple…



C’est pas si simple que ça. NV a une avance depuis la 980. Mais c’est surtout que NV est très présent dans la recherche alors qu’AMD s’est laissé aller en perdant&nbsp;Natalya Tatarchuk.&nbsp;

Et oui logiquement c’est la fin un jeu un drivers…


De toute façon, les rumeurs d’abandon du kernel Windows par Microsoft se font de plus en plus insistantes. Oui, Microsoft réfléchit à passer sous Linux, ce n’est pas un blague. La logique est même intéressante.


c’est cet aspect qui va m’faire chier, J’ai bien l’intention de résister au passage de Win10 jusqu’en 2020, enfin je finirais par faire un dualboot








CryoGen a écrit :



Est-ce que ca veut dire que le développeur pourrait lui même revoir (implémenter) l’algo d’un appel OpenGL par exemple ?





Certains devs des pilotes libres sur Linux (ici un dev Intel) commencent déjà à y réfléchir :

[Mesa-dev] Gallium Vulkan state tracker?



Nah! Ils l’auraient déjà fait s’ils le pouvaient. Ce n’est pas ça qui sent mauvais.


J’aime beaucoup la SDL, d’ailleurs je code avec ! Mais la partie son est (à mon désespoir) assez à la ramasse avec un lag énorme…



Sinon pour la gestion des entrées, et la création de la fenetre/du contexte de rendu, plus quelques petits outils multi plateforme, c’est tip top :)

&nbsp;


En gros les devs qui développent les moteurs de jeux type Unreal Engine, CryEngine ou les devs vraiment bon techniquement géreront eux même la mémoire via Vulkan/Direct3D12.



Les plus petites équipes préférant que ça soit l’OS qui gère la mémoire via une couche d’abstraction supplémentaire (donc plus haut niveau (plus simple) et moins performant ) continueront d’utiliser OpenGL ou Direct3D11.3








moi1392 a écrit :



J’aime beaucoup la SDL, d’ailleurs je code avec ! Mais la partie son est (à mon désespoir) assez à la ramasse avec un lag énorme…



Sinon pour la gestion des entrées, et la création de la fenetre/du contexte de rendu, plus quelques petits outils multi plateforme, c’est tip top :)







J’ai déjà vu ce problème. Si tu compile la SDL toi même, suivant les options de compilation et les bibliothèques présentes, ça peut donner ce genre de souci. Je ne me souviens plus précisément pourquoi, mais je crois me rappeler que suivant les bibliothèques présentes à la phase de configuration de la source SDL, le son ne passe pas par la même api. Et s’il manque les bonnes bibliothèques à la compilation de la SDL, ça active probablement une sorte de “fallback” pourri.



Bon, au moins ça te donne une piste à creuser.