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

Commentaires (51)

noraj

Il y a 8 ans

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

StPierre2

Quelle est la différence ?

anonyme_d8d16f2d9a93e5695ed8811784ba3645

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.

NSACloudBackup

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

mononokehime

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…

 

anonyme_92fcfbdd6cc3f0397af3a985adab6b1b

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

MuadJC

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

fullsun

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

Avisance

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

edit : grilled.

chris.tophe

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.

CryoGen Abonné

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

Hugues1337

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

Firefly' Abonné

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.

Zelfir

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

DahoodG4

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

kikoo26 Abonné

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 ?

Charly32 Abonné

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

kikoo26 a écrit :

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

Il existe SDL pour çà.

Tr4ks Abonné

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

anonyme_b5c672786a220f949b54c73e43986bc6

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

Uther Abonné

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.
 

DahoodG4 a écrit :

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

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.

sr17

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.

doom_Oo7

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

 Posted 13 September 2000 - 09:10 PM    

 Check out SDL (www.libsdl.org). 
 
 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. 

  http://www.gamedev.net/topic/25493-alternative-to-directinput/ &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. " />

bobdu87

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

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

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 Natalya Tatarchuk. 
Et oui logiquement c’est la fin un jeu un drivers…

synclinal Abonné

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.

Elwyns

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

Nel

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.

moi1392

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

arno53

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.

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

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

Tiens, en parlant de ça :

Règlement sur la cyber-résilience : les instances européennes en passe de conclure un accord

Cyber résilience 2.0

AGI, GPAI, modèles de fondation… de quoi on parle ?

B.I.A Bia

Des chercheurs ont élaboré une technique d’extraction des données d’entrainement de ChatGPT

Toxique de répétition

Sommaire de l'article

Introduction

Règlement sur la cyber-résilience : les instances européennes en passe de conclure un accord

AGI, GPAI, modèles de fondation… de quoi on parle ?

#LeBrief : logiciels libres scientifiques, fermeture de compte Google, « fabriquer » des femmes pour l’inclusion

Des chercheurs ont élaboré une technique d’extraction des données d’entrainement de ChatGPT

Devenir expert en sécurité informatique en 3 clics

ownCloud : faille béante dans les déploiements conteneurisés utilisant graphapi

Amazon re:invent : SoC Graviton4 (Arm), instance R8g et Trainium2 pour l’IA

Guéguerre des polices dans le cyber (OFAC et ComCyberMi)

#LeBrief : faille 0-day dans Chrome, smartphones à Hong Kong, 25 ans de la Dreamcast

OVHcloud Summit 2023 : SecNumCloud, IA et Local Zones

Transparence, discriminations : les questions soulevées par l’algorithme de la CAF

Plainte contre l’alternative paiement ou publicité comportementale de Meta

Économie de la donnée et services de cloud : l’Arcep renforce ses troupes

Plus de 60 % des demandes de suppression reçues par Google émanent de Russie

La Commission européenne et Google proposent deux bases de données de fact-checks

#LeBrief : des fichiers Google Drive disparaissent, FreeBSD 14, caméras camouflées, OnePlus 12

Le poing Dev – round 6

Produits dangereux sur le web : nouvelles obligations en vue pour les marketplaces

Usages et frugalité : quelle place pour les IA dans la société de demain ?

La NASA établit une liaison laser à 16 millions de km, les essais continuent

Semi-conducteurs : un important accord entre l’Europe et l’Inde

#LeBrief : PS5 Slim en France, Valeo porte plainte contre NVIDIA, pertes publicitaires X/Twitter

651e édition des LIDD : Liens Intelligents Du Dimanche

#Flock, le grand remplacement par les intelligences artificielles

Quoi de neuf à la rédac’ #9 : LeBrief 2.0, ligne édito, dossiers de fond

Encapsulation de clés et chiffrement d’enveloppes

Empreintes digitales : les capteurs Windows Hello loin d’être exemplaires

#LeBrief : succès du test d’Ariane 6, réparer plutôt que remplacer, Broadcom finalise le rachat de VMware

Apple ne paierait que peu de royalties à Arm pour ses puces

Des logiciels libres scientifiques français à l’honneur

Pourquoi inclure des femmes si on peut les fabriquer ?

Google commencera son ménage dans les comptes non utilisés le 1er décembre

Commentaires (51)