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:
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
# 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 (site web personnel) . Ă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.