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.
# non
Posté par coïn . É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 Narishma Jahar . É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 ChickenKiller . É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 devnewton 🍺 (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:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Non (bis)
Posté par Zenitram (site web personnel) . Évalué à 4.
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 Maclag . É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 Zenitram (site web personnel) . Évalué à -7.
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.
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 Maclag . É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 dinomasque . É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 Zenitram (site web personnel) . Évalué à -3.
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 claudex . Évalué à 6.
Ç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 karteum59 . É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 dinomasque . É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 Albert_ . É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?
[^] # Re: \o/ the seventy show
Posté par ʭ ☯ . Évalué à 4. Dernière modification le 26 septembre 2013 à 16:14.
As-tu le même point de vue sur 3Dnow!, SSE et AVX? Le but n'est pas de programmer seulement avec cette API, c'est de proposer un code optimisé quand cette API est disponible.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: \o/ the seventy show
Posté par Prosper . Évalué à 3.
Surtout qu'en plus AMD a pas seulement annoncé une API graphique mais aussi une nouvelle API son \o/
http://www.anandtech.com/show/7370/amd-announces-trueaudio-technology-for-upcoming-gpus
[^] # Re: \o/ the seventy show
Posté par Tobu . Évalué à 5.
AMD a déjà documenté les registres, le pilote ne devrait pas trainer: http://www.x.org/docs/AMD/AMD_HDA_verbs.pdf
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.