Journal Mantle: une nouvelle API graphique pour remplacer OpenGL

Posté par (page perso) . Licence CC by-sa
Tags :
27
26
sept.
2013

AMD vient de présenter une nouvelle API graphique, Mantle, dont le but est de remplacer OpenGL (ainsi que DirectX et diverses API sur le marché de niche des OS Microsoft et sur console). Plus bas niveau, elle permettrait d'obtenir de meilleures performances au prix d'un plus grand effort de développement.

Dans un premier temps spécifique aux GPU de la marque, le développement serait ouvert et permettrait aux constructeurs concurrents d'implémenter leurs propres versions.

Cette annonce arrive un jour trop tôt, mais on s'ennuyait un peu avec Wayland vs Mir.

source

  • # non

    Posté par . Évalué à 8.

    DirectX, c'est un ensemble qui gère la 3D, mais aussi le son, les inputs, le réseau, le décodage vidéo…

    De ce que je comprends, mantle a vocation uniquement direct3D

    • [^] # Re: non

      Posté par . Évalué à 5.

      Il ne reste plus vraiment que Direct3D qui soit encore utilisé dans DirectX. Presque tout le reste a été déprécié et remplacé par des bibliothèques externes (XInput, XAudio 2, XNA Math, etc…).

  • # Mouais

    Posté par . Évalué à 1.

    Qu'ils fassent déjà des drivers (même proprio … même sous windows) moins pourris avant de vouloir parler de performance ….

    • [^] # Re: Mouais

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

      Si j'ai bien compris, leur idée est de faire faire aux développeurs une partie du boulot aujourd'hui dévolu au driver.

      D'après une source anonyme, le code Mantle pourrait ressembler à ça:

      mov ax,0013h
      int 10h
      

      http://devnewton.bci.im

  • # Non (bis)

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

    dont le but est de remplacer OpenGL (ainsi que DirectX)

    Pas du tout. D'être complémentaire.
    OpenGL et direct3D (et non DirectX comme tu dis, DirectX ne contenant pas que Direct3D et je n'ai pas vu Mantle gérer des manète de jeu ou du réseau) pour du code commun, Mantle pour du spécifique constructeur (ou plus, suivant les envies certes).
    Et comme tu dis, "plus bas niveau", encore plus complémentaire.
    Rien de nouveau, AMD ne fait que rattraper nVidia, et rien de nouveau par rapport à il y a 15 ans non plus.

    Une analyse un peu meilleure :
    AMD Mantle, le retour du Glide ? (oui, glide… Ca ne me rajeunit pas)

    • [^] # Re: Non (bis)

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

      Glide a permis en son temps une percée rapide d'une révolution technologique, par une inclusion de tout le nécessaire dans le binaire.
      Mantle sera peut-être la percée qui va lancer un remplaçant d'OpenGL : le paradigme des cartes graphiques a trop évolué depuis son lancement pour qu'il ne soit pas gavé de contournements qui font perdre en performance, non?

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Non (bis)

      Posté par . Évalué à 10.

      Ouai, enfin, quand tu dis complémentaire, ça veut quand même dire qu'AMD pousse pour que les dévs aient 2 implémentations pour la même chose (ou alors une exclu sur le matos supporté!)

      Au lieu de dire que "ça ne remplace pas Direct3D/OpenGL, c'est complémentaire", je peux écrire "ça ne remplace pas Direct3D/OpenGL, c'est exclusif à AMD".

      Je suppose que s'il s'agissait juste de changer les couches basses sous OpenGL, AMD ne se serait pas emmerdé à faire une nouvelle API incompatible avec le reste du monde, ne serait-ce que pour embarquer les dévs plus facilement (ou alors ça fait partie de la stratégie: vu que les dévs devront faire le boulot pour les consoles, ils passeront peut-être moins de temps à optimiser pour OpenGL/Direct3D, et sur PC, les puces nVidia et Intel passeront pour produits inférieurs).

      On peut donc supposer qu'AMD fera de moins en moins d'effort pour que les pilotes marchent bien avec Direct3D/OpenGL (s'ils en faisaient beaucoup avant…) et mettent tout sur leur nouvelle API.

      Si nVidia et Intel font la même chose, on assistera de facto au remplacement d'OpenGL… par une multiplication des API! Un grand pas en arrière, quoi!

      • [^] # Re: Non (bis)

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

        Ouai, enfin, quand tu dis complémentaire, ça veut quand même dire qu'AMD pousse pour que les dévs aient 2 implémentations pour la même chose (ou alors une exclu sur le matos supporté!)

        Oui, c'est horribe, 2 implémentation, salaud d'ARM qui fait pas comme Intel.
        La, on parle de lange C versus assembleur, il y a le haut niveau "standard" et le bas niveau par CPU ou GPU, ça a toujours existé et figure-toi que même ton Linux a des parties qui sont faites avec 2 (voir 100) implémentations.

        Si nVidia et Intel font la même chose, on assistera de facto au remplacement d'OpenGL… par une multiplication des API! Un grand pas en arrière, quoi!

        Le fait d'avoir ARM dans la course aux CPU face à x86 a tué le C?

        Réfléchit de nouveau à la chose en pensant OpenGL = C et et Mantle = Assembleur (on pourrai monter d'un cran et parler de Python sur Windows et Linux, Linux c'est des API non Windows utilisé par 90% des gens, quel retour en arrière plutôt que d'être comaptible avec les API Windows etc), tu verras qu'il n'y a pas de pas en arrière comme tu le décris, ça a toujorus existé, ça dit juste "si tu est spécifique ça ira plus vite choisis où tu mets la barre".

        Ce n'est pas un pas en arrière, c'est laisser le choix au développeur du niveaa d'omptimisation (contre du temps) qu'il veut. OpenGL et Direct3D restent.
        Il faut arrêter de mettre en conurrence OpenGL et Mantle, c'est comme vouloir mettre en concurrence C et l'assembleur, ça n'a pas de sens! Relisez bien l'annonce…

        • [^] # Re: Non (bis)

          Posté par . Évalué à 9.

          ARM n'a pas tué le C, mais ARM n'a demandé à personne de coder ses applications en Assembleur! Les compilateurs C, après patches, font toujours très bien le boulot.

          AMD demande aux développeurs de s'occuper de Mantle et pas OpenGL: meilleures perfs au prix d'une complexité légèrement plus grande (ou pour reprendre la comparaison: "venez coder chez moi en Assembleur").

          Non, il ne faut pas comparer, ce n'est pas au même niveau, mais à la fin, soit tu développes pour Mantle en ajoutant ta couche à toi au-dessus, soit tu développes pour OpenGL. Si le dév doit choisir, c'est que quelque part, c'est encore comparable!

          Tu es le premier à râler contre la multitude de "Linux" en disant qu'il n'y a pas d'abstraction commune (le LSB étant plutôt un échec de ce côté).
          Sans OpenGL ici, pas d'abstraction non plus: il faudra bien une version Mantle et une version OpenGL (et/ou Direct3D d'ailleurs).

          Alors encore une fois: soit AMD se fout un peu du monde et un patch permettra d'utiliser Mantle avec OpenGL sans problème, soit AMD s'éloigne d'OpenGL. C'est très différent d'ARM et du C!
          Si une nouvelle couche d'abstraction permet de se mettre au-dessus de Mantle, PhysX et je ne sais quoi, ok, mais si ça part dans tous les sens, tu fais quoi à la fin? D'ici 5ans, OpenGL sera devenu aussi bon que l'accélération 3D logicielle aujourd'hui?

      • [^] # Re: Non (bis)

        Posté par . Évalué à 7.

        La situation me semble pourtant limpide : les joueurs consoles (PS4, XB1) et la moitié des joueurs PC utiliseront à court terme des puces graphiques AMD.

        Sur console, les développeurs prendront l'API qui permet d'offrir les meilleurs performances. Tant qu'à faire, ils reprendront probablement ce code optimisé pour les versions PC des jeux. Tant pis pour les possesseurs de puces d'autres constructeurs (Intel, Nvidia).

        Ainsi AMD rentabilise son partenariat avec Microsoft et Sony.

        BeOS le faisait il y a 15 ans !

        • [^] # Re: Non (bis)

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

          les joueurs consoles (PS4, XB1) et la moitié des joueurs PC utiliseront à court terme des puces graphiques AMD.

          Tout comme le PC desktop sont majoritairement sous x86.
          N'empèche, Linux, et plein d'autres logiciels, sont codés en C, C++, Python et pas x86…

          Je n'arrive toujours pas à comprendre comment vous arrivez à vos conclusions…

          • [^] # Re: Non (bis)

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

            N'empèche, Linux, et plein d'autres logiciels, sont codés en C, C++, Python et pas x86…

            Ça n'empêche pas que ce soit optimiser pour x86 et ARM et pas pour les autres processeurs. Par exemple, Firefox ne compile le JS en assembleur Alpha mais en x86. Chromium n'est carrément pas disponible sur autre chose que x86(_64), le noyau Linux a des parties en assembleur pour certains processeurs, et pour les autres, c'est un mode dégradé, plus lent.

            Ça montre bien que les optimisations ne sont faites que pour ce qui est populaire.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Non (bis)

      Posté par . Évalué à 3.

      Je ne suis pas un expert du sujet, mais est-ce que ce n'était pas justement le rôle de Gallium3D de proposer une API un peu plus bas niveau que OpenGL (précisément comme base pour écrire des drivers) ? Du coup, comment leur nouvelle API se positionne t-elle par rapport à Gallium ? (concurrente ? complémentaire ?)

  • # Je préfère une API plus propre

    Posté par . Évalué à 5.

    comme par exemple ATI CIF, une API 3D qui récurre ton pipeline 3D ! http://gona.mactar.hu/ATI_3D_CIF/

    BeOS le faisait il y a 15 ans !

  • # \o/ the seventy show

    Posté par . Évalué à 2.

    On dirait vraiment que l'on revient dans le passe avec des programmes qui vont devenir de plus en plus incompatible suivant le matos. Genial non?

Suivre le flux des commentaires

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