Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

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

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

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

Le 19 février 2016 à 14h45

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.

Commentaires (49)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

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 :)

 

votre avatar

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

votre avatar







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.



votre avatar







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=" />


votre avatar







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

votre avatar







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.


votre avatar







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.


votre avatar







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 ?


votre avatar

@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.

votre avatar

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


votre avatar

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

votre avatar







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…


votre avatar

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…

votre avatar

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.

votre avatar

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

votre avatar







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?


votre avatar

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

votre avatar

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

votre avatar







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.


votre avatar







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.


votre avatar

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

votre avatar

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

votre avatar







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 ?


votre avatar







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;


votre avatar







kikoo26 a écrit :



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





Il existe SDL pour çà.


votre avatar

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

votre avatar

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) ?

votre avatar

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

votre avatar

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.


votre avatar







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.


votre avatar

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…

votre avatar

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

votre avatar







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.


votre avatar

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 ^^.

votre avatar

Quelle est la différence ?

votre avatar

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

votre avatar

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)

votre avatar

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.

votre avatar







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”.


votre avatar

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…



&nbsp;

votre avatar

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

votre avatar







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?


votre avatar

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

votre avatar

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

votre avatar

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



edit : grilled.

votre avatar

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

votre avatar







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.


votre avatar







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=" />


votre avatar

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

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

Fermer