Journal Mantle: une nouvelle API graphique pour remplacer OpenGL

Post√©¬†par¬† (site web personnel) . Licence CC¬†By‚ÄĎSA.
√Čtiquettes¬†:
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¬† (site web personnel) . √Č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
      

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # Non (bis)

    Post√©¬†par¬† (site web personnel) . √Č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¬† . √Č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¬† (site web personnel) . √Č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 20 ans !

        • [^] # Re: Non (bis)

          Post√©¬†par¬† (site web personnel) . √Č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¬† . √Č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 20 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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.