Journal GPUOpen

Posté par . Licence CC by-sa
Tags :
25
26
jan.
2016

AMD sort GPUOpen, il semblerait que leur volonté serait de permettre d'aller plus bas dans les couches de la carte graphique que ce que les APIs classiquent permettent. Je ne sais pas trop ce que cela signifie en détail mais ils ont déjà sorti 3 projets en C++ sur leur github, un outil de maillage, un analyseur de code (noyau OpenCL et OpenGL shaders) et un analyseur de performances DirectX 12 (cela nous concerne un peu moins). Peut être des gens ici ont une idée plus précise de ce qu'il veulent faire, en tout cas la démarche est plutôt positive.

  • # Version rapide

    Posté par . Évalué à 10.

    AMD essaye d'attirer de nouveau développer et utilisateur vers leur plateforme.

    Et un des moyens c'est d'avoir un développement plus ouvert.
    Ils ont aussi du se séparer de beaucoup d'employé, donc ils doivent manquer de monde pour développer les outils, libs, etc utile aux développeurs.

    Passer ses outils en open source peut permettre d'augmenté le capital de la société au près des devs, et de leur permettre d'avoir des meilleurs outils que s'ils les développait seul.

    En tout cas c'est une société qui fait beaucoup d'effort pour amélioré les choses (HSA, Freesync, Mantle/Vulkan), même si c'est en parti par contrainte (s'ils veulent survivre).
    Donc j'espère que tout ses efforts porterons leurs fruits avant qu'ils soient mort ou revendu.

    • [^] # Re: Version rapide

      Posté par . Évalué à 3.

      Un des points bloquants pour ce qui est d'attirer des gens est la performance des puces vendues. Un autre est qu'il faudra du temps pour que leur pile logicielle atteigne la maturité de celle de NVidia (au boulot, on code la compatibilité HSA de Numba… pour l'instant, ça secoue pas mal).

      AMD a racheté ATI il y a dix ans, mais ce n'est que très récemment qu'ils ont commencé à pousser le concept d'architecture hétérogène (HSA). Je me demande pourquoi.

      • [^] # Re: Version rapide

        Posté par . Évalué à -7.

        Le problème c'est surtout la propagande et l'ignorance.

        Par exemple sur Windows le préjugé sur leur pile logiciel est archi faux depuis crimson.
        Sur Linux le nouveau amdgpu promet de faire de même une fois qu'il sera mâture (ils ont d'ailleurs pour but long terme de partager le même driver que sur Windows)
        Tu parles de HSA mais est-ce que nvidia le supporte seulement ? Primo ce n'est pas encore mâture, deuxièmement c'est une immense révolution. Nvidia n'innove pas.
        Vulkan et direct x 12 sont créé par le source code de mantle D'AMD.
        Toute les mémoires vidéos sont créés par AMD. Avec AMD pas besoin de payer 100 euros pour avoir un adaptative V sync…
        Et les cartes AMD sont bien plus puissante sur la durée que celles d'nvidia car ils ne font pas d'obscolescence. Et elles ont toujours été plus puissante, c'est juste que les apis ne les exploitaient pas bien (pas d'async compute)

        "ce n'est que très récemment qu'ils ont commencé à pousser le concept d'architecture hétérogène (HSA). Je me demande pourquoi." dire cela prouve bien ton ignorance, regarde les changelogs entre les différents apus sur Wikipedia, tu verras qu'à chaque générations ils rendaient le système plus hétérogène. HSA n'est aujourd'hui possible que grâce à ces travaux long terme. Et leur prochaine génération d'apus aura un successeur du pci afin de diminuer les latences pour permettre au gpu d'utiliser une mémoire unifié (HBM) et ils prévoient aussi de mettre des processeurs dans la mémoire.
        Et surtout AMD est moral et ouvert, ils sont altruistes tandis que Nvidia fait des pratiques anti competitive et se fout de ses propres consommateurs.
        Heureusement nvidia n'a aucun avenir et cessera enfin de nuire à l'humanité en 2017

        • [^] # Re: Version rapide

          Posté par . Évalué à 7.

          Tu parles de HSA mais est-ce que nvidia le supporte seulement ?

          NVidia a CUDA, qui est un cadre logiciel stable, éprouvé et massivement adopté pour faire du GPGPU.
          La pile HSA de AMD est très jeune…

          Et les cartes AMD sont bien plus puissante sur la durée que celles d'nvidia car ils ne font pas d'obscolescence.

          Les gens qui font du GPGPU veulent un niveau maximal de performance par slot PCI-Express, par kilowatt ou par dollar. Pour l'obsolescence, je ne sais même pas ce que tu prétends comparer : quasi-personne n'utilise HSA pour faire du GPGPU, les cartes seraient supportées 20 ans que ça ne changerait rien…

          Et surtout AMD est moral et ouvert, ils sont altruistes

          D'ailleurs, si tu téléphones aux actionnaires d'AMD, ils t'envoient des caisses de Champagne et se dévouent pour débugger ton code gratos, et pendant ce temps-là la PDG d'AMD te fait cuire des macarons au saumon fumé pour te faire patienter.

          • [^] # Re: Version rapide

            Posté par . Évalué à 0. Dernière modification le 28/01/16 à 19:08.

            Je ne connais pas tout les détail de CUDA, mais comparer HSA a CUDA ne me semble pas très pertinent.
            AMD a OpenCL qui serais un équivant de CUDA, et les performance GPGPU des cartes AMD sont reconnus depuis quelques temps.

            La pile HSA c'est quand même l'étape suivante, ça doit améliorer le mélange de calcul CPU et GPU et facilité l'utilisation du GPU pour les développeurs.

            AMD n'est surement pas altruistes et pas exempt de reproche, mais il me semble qu'il ont une politique beaucoup plus ouverte et respectueuse des utilisateurs.
            Et une chose est sur ils sont à l'origine ou pousse de nombreuses évolutions de façon ouverte (Mantle qui a donné Direct3D 12 et Vulkan, HSA, HBM, Freesync, ).

          • [^] # Re: Version rapide

            Posté par . Évalué à -7.

            Désolé mais encore une fois tu parle sans savoir, tu devrais vérifier tes connaissances avant de les affirmer.

            Primo tu omets de dire que CUDA est propriétaire et Nvidia only.
            Et surtout tu compare HSA et CUDA or c'est incomparable, c'est comme si tu comparais html 5 + JavaScript vs html 1.
            AMD et Intel ont depuis longtemps un concurrent libre à CUDA, c'est openCL. Il est plus complet que CUDA.
            Et AMD a de bien meilleure performance en computing que Nvidia, ce n'est pas pour rien que tout les mineurs de bitcoin sont sous AMD.
            Et CUDA est voué à mourir, les logiciels grand public ne peuvent être qu'openCL e.g (libreoffice, Gimp, photoshop, blender, servo (le moteur de rendu successeur de gecko), civilisation 5, etc)
            HSA quand à lui est encore une innovation libre qui va mille fois plus loin en permettant des nouvelles possibilités comme avoir une mémoire unifié, utiliser mieux le cpu et réduire drastiquement la latence de création de tampon vram et ram des gpus, ce qui va étendre les possibilités de programabilite des gpus.
            Il va aussi énormément augmenter l'autonomie.

            Enfin, "D'ailleurs, si tu téléphones aux actionnaires d'AMD, ils t'envoient des caisses de Champagne et se dévouent pour débugger ton code gratos, et pendant ce temps-là la PDG d'AMD te fait cuire des macarons au saumon fumé pour te faire patienter." ceci est une merveilleuse et pathétique technique sophiste.
            Plat, vide d'arguments.
            AMD mène une politique altruiste, partage tout, rend tout libre. Tu es juste ignorant.
            Et des actionnaires AMD n'en a plus beaucoup mais j'en fais partie.

            • [^] # Re: Version rapide

              Posté par . Évalué à 2. Dernière modification le 28/01/16 à 22:27.

              Bon, j'hésite à répondre vu que j'ai l'impression de lire un troll mal dégrossi ("AMD mène une politique altruiste"… "Tu es juste ignorant"… Ok).

              CUDA est propriétaire et Nvidia only.

              Les utilisateurs s'en foutent, vu que NVidia est le constructeur dominant dans le monde du GPGPU : ils choisissent le matériel qui leur fournit les meilleurs perfs, pas le logiciel le plus libre.

              AMD et Intel ont depuis longtemps un concurrent libre à CUDA, c'est openCL. Il est plus complet que CUDA.

              Il est peut-être "plus complet" (c'est à démontrer), mais quasiment pas utilisé dans le monde du calcul scientifique… Il faudrait peut-être se demander pourquoi au lieu de s'enorgueillir d'une pile logicielle que personne n'utilise.

              • [^] # Re: Version rapide

                Posté par . Évalué à 2.

                Bon, j'hésite à répondre vu que j'ai l'impression de lire un troll mal dégrossi ("AMD mène une politique altruiste"… "Tu es juste ignorant"… Ok).

                Il est juste suuuuuuuuuper jeune. J’espère.

                Depending on the time of day, the French go either way.

      • [^] # Re: Version rapide

        Posté par (page perso) . Évalué à 2.

        AMD a racheté ATI il y a dix ans, mais ce n'est que très récemment qu'ils ont commencé à pousser le concept d'architecture hétérogène (HSA).

        Ils poussent dans cette direction depuis l’acquisition d’ATI, mais ça a pris du retard. cf. https://fr.wikipedia.org/wiki/AMD_Fusion#APU

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

  • # Gameworks

    Posté par . Évalué à 8.

    Gpuopen est surtout une réponse à gameworks de nvidia (qui est propriétaire et qui baissent volontairement les perfs sur du AMD)
    Gpuopen à l'instar de gameworks sont des bundle de librarys où les développeurs peuvent piocher et les implémenter dans leur jeux. Elles ont pour but d'améliorer la beauté des effets visuels (exemple tressfx)
    Cependant gpuopen tend à être plus que cela en y incluant liquid VR (un puissant sdk pour développer pour la réalité virtuelle), fireray qui est un logiciel de raytracing, et un nombre énorme de kernels OpenCL. L'on y trouve aussi leur ISA, bref c'est un peu la gaverne d'Ali baba en Stallman édition.

    Aussi, ils viennent en parallèle d'annoncer leur projet opencompute, visant à "révolutionner" les possibilités des gpus en matière de computing via notamment leur initiative boltzmann qui a pour but de transpiler les logiciels CUDA en openCL/SYCL. Ils parlent aussi de multi gpu par peer to peer oO pour le HPC j'imagine !

    http://phoronix.com/scan.php?page=news_item&px=Radeon-Open-Compute

    J'espère que vous serez nombreux à contribuer à cet élan d'altruisme de la part D'AMD !

    • [^] # Re: Gameworks

      Posté par (page perso) . Évalué à -5.

      Je n'ai pas tout compris dans ce commentaire, remplacer les anglicismes par des termes en français faciliterait la lecture.

      • [^] # Re: Gameworks

        Posté par . Évalué à 10.

        Marrant venant d'un gars dont le pseudo est NumOpen ;-)

    • [^] # Re: Gameworks

      Posté par . Évalué à 2.

      Est ce que tu aurais des sources sur les outils Gameworks qui baisserais volontairement les performances sur AMD ?

      Étant donnée les différences d'architecture, ça ne serai pas étonnais que certaine optimisation très poussé pour Nvidia soit contre productive sur AMD, mais ce n'est pas ce que je comprend dans le volontairement.

      • [^] # Re: Gameworks

        Posté par . Évalué à 10.

        Nvidia a tendance à travailler en amont avec les gros studios de jeux vidéo pour leur faire intégrer des technologies qui leur sont propres, mais non obligatoires. Exemple avec les jeux Batman qui ont toujours intégré PhysX ou dernièrement avec The Witcher 3 et Hairworks. Ces technologies sont faites pour tourner sur du matériel Nvidia, et comme les sources ne sont pas ouvertes, l'intégration sur AMD est soit impossible (PhysX) soit moins performante (Hairworks). Ces technologies sont optionnelles, donc difficile d'accuser Nvidia de plomber la concurrence. Le problème c'est juste leur manque d'ouverture.

        Après il y a quelques perles comme Crysis 2 qui fait calculer au GPU un océan non visible à l'écran, pour plomber les performances des cartes AMD qui avaient du mal à l'époque avec la Tesselation : http://forums.anandtech.com/showpost.php?p=32144022&postcount=12

        • [^] # Re: Gameworks

          Posté par . Évalué à 5.

          Et qu'est-ce qui empêchait AMD d'aller voir CD Project, développeur de The Witcher 3, comme l'a fait NVIDIA, pour optimiser le jeu avec leurs cartes, plutôt que d'aller pleurnicher une fois le jeu sorti ? NVIDIA avait annoncé depuis longtemps qu'ils implémenteraient leur techno dans ce jeu, tout le monde était au courant, les démos techniques circulaient sur le web au moins un an avant la sortie du jeu.
          Le discours du gentil AMD face au méchant NVIDIA masque à mon avis une triste réalité. Quand bien même leur matériel serait bon, la partie logicielle est la ramasse. J'ai longtemps privilégié AMD/ATI pour les GPU, parce qu'ils faisaient un pas vers le LL, c'était une démarche militante. Mais en tant que joueur, j'étais de toute façon contraint d'utiliser les pilotes propriétaires. Mon expérience était que leurs pilotes avaient plusieurs mois de retard sur les sorties du noyau Linux et sur Xorg (parce que calées sur les sorties d'Ubuntu si ma mémoire est bonne), avec des performances très en retrait par rapport à celles sous Windows. Depuis que je suis passé sur des GPU NVIDIA, je n'ai jamais eu ce genre de problèmes.
          Alors quand bien même AMD semble faire plus pour le libre que NVIDIA, au moins ce dernier est capable de fournir une expérience utilisateur satisfaisante. Mon raisonnement est le suivant : si ça pose un problème éthique d'installer un pilote propriétaire, alors il suffit de prendre un processeur Intel avec GPU intégré, ça fonctionne très bien, y compris pour les jeux qui ne sont pas trop exigeants graphiquement. Si c'est pour faire du jeu "gourmand", autant choisir ce qui fonctionne le mieux, dans la mesure où l'installation d'un pilote propriétaire est un passage (presque) obligé. Sous cet angle, mon bilan est que NVIDIA fait bien plus qu'AMD pour faire de Linux un OS "prêt pour le desktop".

          Bien que OpenGPU soit une bonne initiative, je reste quand même dubitatif. AMD donne l'impression de lancer tous les ans des initiatives prometteuses qui doivent "tout révolutionner" mais qui, sans réel suivi (dernièrement Mantle, OpenWorks), tombent dans l'oubli. J'ai juste envie de leur dire : commencez par fournir un bon driver, et si vous en êtes pas capables, libérez le votre, des gens compétents sauront quoi en faire, ça sera rendre un bien meilleur service à la communauté des utilisateurs de Linux que vos projets actuels, même libres, sans lendemains.

      • [^] # Re: Gameworks

        Posté par . Évalué à -6.

        Désolé pour le retard, en fait gameworks utilisent volontairement absurdement la tesselation.
        Non seulement pour des tâches de compute ils utilisent la tesselation, mais en plus au lieu de l'utiliser en x8 ou x16 ils font du x128… Ça n'a aucune différence visuelle mais détruit les performances sur des gpu AMD. Pourtant AMD a de très bonne performance en tesselation (C'est d'ailleurs eux qui en ont inventé le concept) mais ils n'avaient pas prévu qu'elle serait utilisé à des niveaux absurdes.
        Source : https://youtu.be/O7fA_JC_R5s
        Oh et ils prostituent des developpers pour faire charger des objets immense comme des océans qui ne sont pas affichés à l'écran dans le seul but de nuire à AMD.
        Nvidia comme dirait linus, fuck you !
        Ce sont des connards ammoraux qui se trompent de finalité, heureusement en 2017 les apus polaris +zen vont les tuer une bonne fois pour toute.
        Oh et pour aller plus loin :
        https://youtu.be/ZcF36_qMd8M

        • [^] # Re: Gameworks

          Posté par . Évalué à 1.

          Ok merci pour les liens.
          J'avais entendu parler d'agissement pas très faire play de la part d'NVidia sans avoir de source.

          Mais je savais pourquoi je voulais plutôt du AMD que du NVidia dans mes ordinateurs.

        • [^] # Re: Gameworks

          Posté par . Évalué à 2.

          Merci pour cette info édifiante, et vraiment pitoyable de la part d'NVIDIA (et des développeurs du jeu surtout en fait…).

          Ceci dit, qu'est ce qui empêche AMD de faire un profil pour détecter cette dégradation volontaire de performance et ainsi la désactiver ? Rien. Donc qu'est ce qu'ils foutent ?
          Pour rejoindre un peu ce qu'à dit "Pif le Chien" plus haut dans les commentaires, AMD fait du bon matos mais niveau support et marketing ce sont des zéros, ils restent là à pleurnicher et voir leurs ventes diminuer petit à petit. Faut vraiment qu'ils changent de stratégie et qu'ils se sortent les doigts du luc.

          • [^] # Re: Gameworks

            Posté par . Évalué à -7.

            "Ceci dit, qu'est ce qui empêche AMD de faire un profil pour détecter cette dégradation volontaire de performance et ainsi la désactiver ?"
            Un profil pour détecter les océans absurdes et trucs du genre ?
            Le driver n'a pas ce pouvoir, un driver ne peut pas refuser de charger spécifiquement des shaders. Et quand bien même ce serai possible, le code source est fermé donc ce serai pas facile.

            Quand à la tesselation absurde de gameworks, ils donnent une option pour forcer la tesselation à être x4/x8/x16 etc. Mais ils laissent cette liberté aux joueurs. Je suis d'accord qu'ils devraient bloquer par default le +x16, cependant je pense qu'ils ne le font pas afin de faire le revers de la médaille à Nvidia. Dans 6 mois ils sortent leur toute nouvelle architecture qui est attendu comme ayant de bien meilleur perf en tesselation. Il faut savoir que nvidia perd aussi beaucoup de fps avec gameworks.

            "AMD fait du bon matos mais niveau support et marketing ce sont des zéros, ils restent là à pleurnicher et voir leurs ventes diminuer petit à petit. Faut vraiment qu'ils changent de stratégie et qu'ils se sortent les doigts du luc."
            Le problème c'est que les gens sont désinformés car il y a une propagande massive pro nvidia sur le Web. C'est principalement dû au fait que Nvidia offre "gratuitement" ses cartes au médias alors que AMD non….
            AMD a de bien meilleur drivers sur Windows que nvidia depuis omega, et encore mieux depuis Crimson. Sur Linux c'est une autre histoire, cependant leur nouveau driver amdgpu qui est full opensource à pour but de partager son code avec Windows. Il n'est juste pas encore mâture.
            AMD developpe bien plus la partie logiciel que nvidia, le truc c'est qu'ils le font dans l'intérêt de tous. Par exemple ils ont créé Vulkan et direct x 12 en donnant le devs et le code source de mantle.
            Ils développent les standards de demain (freesync, HSA, HBM, opencl, etc)
            Et depuis gpuopen, ils veulent encore plus intensifier cela, et crois moi que ça va être utilisé car c'est opensource et crossconsoles.
            http://www.xda-developers.com/robert-hallock-gpuopen-is-amds-long-term-open-source-strategy/
            Les gens disent que AMD va faire faillite hahaha quelle bonne blague ! Ils sont les seuls à avoir un avenir avec leurs apus polaris +hbm+zen.

            • [^] # Re: Gameworks

              Posté par . Évalué à 3.

              Un profil pour détecter les océans absurdes et trucs du genre ?
              Le driver n'a pas ce pouvoir, un driver ne peut pas refuser de charger spécifiquement des shaders. Et quand bien même ce serai possible, le code source est fermé donc ce serai pas facile.

              Bien sûr que si c'est possible, le driver fait tout ce qu'il veut ! C'est lui qui lit de code source OpenGL, qui le transforme et qui le compile en code machine (ISA).
              Détecter un programme spécifique, Mesa le fait (par exemple pour contourner des bugs de programmation GLSL dans les benchmarks Unigine). Alors ensuite détecter les shaders pour les transformer arbitrairement, y'a aucun soucis. J'imagine que détecter une tesselation 128x ça doit pas être bien compliqué.

              C'est principalement dû au fait que Nvidia offre "gratuitement" ses cartes au médias alors que AMD non….

              Et qu'attends AMD pour faire pareil ?
              Voilà c'est ça… ils sont nuls en marketing, CQFD.

Suivre le flux des commentaires

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