Journal Nvidia ouvre son SDK GameWorks

Posté par  . Licence CC By‑SA.
Étiquettes :
7
15
mar.
2016

Selon un article de jeuxvideo.com, Nvidia ouvrirait le SDK GameWorks :

« GameWorks consiste en une boite à outils destinée aux développeurs de jeu vidéo, et qui doit leur permettre d’intégrer à leur production des effets graphiques plus réalistes et / ou plus efficaces dans leur manière d’utiliser les ressources GPU ».

(…)

« Enfin, on notera que la bibliothèque PhysX s’est renforcée de deux nouvelles extensions, baptisées PhysX GRB et PhysX Flow. Par ailleurs, les codes sources de certains effets GameWorks vont bénéficier d’une diffusion ouverte via GitHub : ce sera le cas des technologies Volumetric Lighting, FaceWorks, HairWorks, HBAO+ et WaveWorks ».

Vu l'impact négatif de ces options sur les performances, et ce pour un gain visuelle négligeable, cela ne devrait cependant pas être d'une grande utilité dans l'immédiat, mais cela pourrait le devenir avec les prochaines générations de cartes graphiques gravées en 14nm (Pascal pour Nvidia et Polaris pour AMD), annoncées pour être beaucoup plus puissantes, et attendues dans les mois à venir (théoriquement mi-2016 pour Nvidia et 2017 pour AMD).

  • # Correction

    Posté par  . Évalué à 1.

    « gain visuel* »

  • # la backdoor est toujours là

    Posté par  (site web personnel) . Évalué à 9.

    Nvidia ouvre son SDK GameWorks

    Pas vraiment, quand je lis :

    Par ailleurs, les codes sources de certains effets GameWorks vont bénéficier d’une diffusion ouverte via GitHub

    Tant que le SDK n’est pas intégralement libre, je comprends que nVidia conserve toujours le pouvoir d’insérer du code dégradant les performances lorsqu’exécuté sur le matériel de ses concurrents, ou n’importe quoi d’autre de cet acabit, GameWorks restant la backdoor permettant à nVidia d’intégrer du code arbitraire directement dans la production des développeurs de jeu.

    Si l’ouverture n’est que partielle, le risque est toujours complet.

    ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: la backdoor est toujours là

      Posté par  . Évalué à 6.

      GameWorks restant la backdoor permettant à nVidia d’intégrer du code arbitraire directement dans la production des développeurs de jeu.

      Ils n’ont pas besoin de ça. Les drivers Windows des développeurs de GPU sont bourrés de réécritures de shaders pour les gros jeux; ils détectent à la volée un jeu (AAA) et remplacent les shaders des devs(!!) par une version plus performante sur leurs GPUs.

      C’est cet mascarade qui a amené la plupart des éditeurs (OS, moteurs, jeux…) et vendeurs de GPU à convaincre Khronos de faire un API bien plus complexe (Vulkan) permettant de mieux exploiter les GPUs modernes sans une connaissance ultra-poussée des paramètres de chaque GPU.

      • [^] # Re: la backdoor est toujours là

        Posté par  . Évalué à 3.

        Ils n’ont pas besoin de ça. Les drivers Windows des développeurs de GPU sont bourrés de réécritures de shaders pour les gros jeux; ils détectent à la volée un jeu (AAA) et remplacent les shaders des devs(!!) par une version plus performante sur leurs GPUs.
        C’est cet mascarade qui a amené la plupart des éditeurs (OS, moteurs, jeux…) et vendeurs de GPU à convaincre Khronos de faire un API bien plus complexe (Vulkan) permettant de mieux exploiter les GPUs modernes sans une connaissance ultra-poussée des paramètres de chaque GPU.

        ta as des sources de ce que tu avances ? Je suis preneur d'une information plus détaillée sur le sujet.

        • [^] # Re: la backdoor est toujours là

          Posté par  . Évalué à 8.

          • [^] # Re: la backdoor est toujours là

            Posté par  (site web personnel) . Évalué à 5.

            Excellent ! Merci pour la lecture.

            Dommage que ce texte ai déjà un an, pensez-vous (ceux qui lisent DLFP) que ça aurait tout de même sa place sur LinuxFr aujourd’hui ? Ce texte répond à plein de question sur l’état actuel des pilotes et API graphiques et si ça ne parle pas directement de Linux, on comprend plein de choses qui ont une incidence directe sur l’état des pilotes graphiques sous Linux et sur le pourquoi du comment des chamboulements que l’on vit en ce moment (Vulkan etc.). Si ce texte était d’hier, j’aurai déjà demandé à l’auteur la permission de le republier en français sous CC-By SA ici sur LinuxFR, on manque de ressources de ce type en Français. Et je me sens capable de le traduire.

            Sinon je pourrais essayer de synthétiser plusieurs textes, celui-ci de lui, et d’autres textes que l’on peut tirer petit à petit des liens qu’il donne (profitant de l’exception de citation ;-) ), mais je me sens déjà dépassé par une telle tâche. Traduire ce texte serait déjà largement suffisant et est déjà un excellent point d’entrée, mais il a un an, mais il me semble tellement d’actualité…

            ce commentaire est sous licence cc by 4 et précédentes

          • [^] # Re: la backdoor est toujours là

            Posté par  . Évalué à 1.

            Je ne suis pas expert de ces questions, donc je vais peut être utiliser des termes imprécis, désolé par avance.

            Je comprends que la raison des hacks introduits dans les drivers est en premier lieu de régler des bugs causés par le non respect des API par les développeurs de jeux, ça n'a rien à voir avec le sujet de départ : l'introduction de technologies améliorant le rendu propres à chaque fabricant (AMD a les siennes aussi, il y avait eu même type de scandale avec l'introduction de TressFx dans Tomb Raider 2013 que pour The Witcher 3 avec Gameworks)
            Ces technologies ont un but marketing évident, pour vendre du matériel qui rend tel ou tel jeu plus beau selon le GPU, mais de là à crier au complot comme le font certains… Ces technologies spécifiques sont systématiquement désactivables dans les options graphiques des jeux. À moins qu'il y ait une affaire de corruption, pour le développeur de jeu, quel bénéfice tirerait-il à rendre son jeu volontairement moins rapide sur un matériel donné ? Je ne vois pas bien.

            Le gars mentionne ensuite des hacks qui ont pour seul but d'améliorer les perfs des jeux, ce qui est le cas des remplacements des shaders. Où est le mal ?

            Par contre, c'est certain, on gagnerait à ce que toutes ces technologies soient intégrées dans les api standards et disponibles pour n'importe quelle marque de matériel, mais je crois que c'est le chemin vers lequel on s'oriente avec les libérations successives de OpenGPU par AMD et maintenant NVIDIA, non ?

    • [^] # Re: la backdoor est toujours là

      Posté par  . Évalué à 7.

      que nvidia optimise son SDK pour ces cartes je le comprends (qu'il est pas envie de tester/optimiser leur code sur des cartes concurrentes), par contre que Nvidia fasse l'inverse, c'est a dire rajouter sciemment du code pour que le résultats soient ralenties sur les cartes concurrentes j'y crois moins, y a trop de risque de perte d'image de la marque si l'info fuite.

      • [^] # Re: la backdoor est toujours là

        Posté par  . Évalué à 2.

        1) Nvidia s'en branle complètement de son image

        2) Ils ne seraient pas les premiers à faire ça, Intel a fait pareil.

        *splash!*

        • [^] # Re: la backdoor est toujours là

          Posté par  . Évalué à 3.

          2) Ils ne seraient pas les premiers à faire ça, Intel a fait pareil.

          Ref needed :)

          Je dis pas que c'est faux, je demande juste à que les propos soient un minimum sourcé quand il s'agit de balancer comme ça gratuitement sur certains nom de marque/société connues.

  • # AMD Roadmap

    Posté par  . Évalué à 1.

    Les GPU Polaris doivent sortir au troisième trimestre 2016 et non 2017.
    C'est la génération de GPU Vega qui doit sortir début 2017.

    Cf http://www.hardware.fr/news/14545/gdc-amd-devoile-roadmap-gpu-polaris-vega-navi.html

    Par contre Polaris serait plutôt du milieu entré de gamme, et il faudrait attendre 2017 avec Vega pour voir arrivé du (très ?) haut de gamme chez AMD.

    • [^] # Re: AMD Roadmap

      Posté par  . Évalué à 0. Dernière modification le 16 mars 2016 à 13:11.

      Je me suis probablement mal exprimé, mais je parle justement de la génération de GPU 14nm bien plus puissante que celle actuelle, celle qui va éventuellement justifier un remplacement de matériel (DisplayPort 1.3, performances en 4K, réduction de 60% (Nvidia) à 150% (AMD) de la consommation, etc.). Et comme tu le précises, AMD n'est attendu sur ce créneau qu'en 2017, tandis que Nvidia sortirait son jeu dès le milieu de cette année.

      Cela dit, personnellement, j'imagine mal Nvidia sortir le grand jeu dès cette année, ça n'aurait commercialement et technologiquement aucun intérêt pour eux, ils ont seulement besoin de sortir une carte qui fasse oublier le camouflet que vient de subir Maxwell avec DirectX12 (comparatif plus exhaustif), je m'attends donc à un GPU sur un [demi|quart] de die (28nm>14nm), 10~15% plus performant qu'une GTX 980 Ti pour la moitié de la consommation, et un prix au niveau de la GTX 980 actuelle. Et je les vois plutôt sortir l'artillerie lourde en 2017, avec un GPU sur un die pleine taille pour contrer l'offre AMD. Ce ne sont là que de pures hypothèses personnelles, évidemment.

      • [^] # Re: AMD Roadmap

        Posté par  . Évalué à 1.

        Je pense que le journal mériterais d'être mis à jour,
        car la on comprend que Polaris la prochaine génération de GPU AMD (et première gravé en 14nm) n'arrivera qu'en 2017.

  • # Catalyst est mort !! Vive AMD !!!

    Posté par  . Évalué à -3.

    http://phoronix.com/vr.php?view=22929

    Le nouveau driver opensource amdgpu est en train de dépasser en performance le driver propriétaire catalyst :)

    Aussi, l'implémentation Vulkan devrait être partagé entre Linux et Windows et devenir opensource.

  • # Gain visuel

    Posté par  . Évalué à 1.

    Vu l'impact négatif de ces options sur les performances, et ce pour un gain visuelle négligeable
    

    L'impact visuel est quand même loin d'être négligeable pour les jeux qui utilisent ces technologies. Sur The Witcher 3, HairWorks est un vrai plus pour le réalisme des montres, bien que la consommation en ressources soit, je suis d'accord, importante. De même pour la gestion de la physique via PhysX qui permet à l'environnement de gagner en réalisme (explosions, mouvement des tissus, etc.) Idem pour les autres effets.

    Exemple pour HairWorks :
    https://www.youtube.com/watch?v=Q3yJog3tsgI

    PhysX
    https://www.youtube.com/watch?v=9q4yQbyur2c

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.