Dans la rubrique "OpenGL", tu peux cliquer sur "Drivers details" pour dérouler le tableau détaillé.
Toutes les cartes AMD GCN et RDNA prennent en charge OpenGL 4.6, et il me semble aussi que les plus anciennes TeraScale 2 et TeraScale 3 prennent aussi en charge OpenGL 4.6 (TeraScale 2 c’est l’année 2009).
quid des GPU intégrés, peuvent-ils le faire (je n'en doute pas, mais lesquels)
Tous les GPUs intégrés AMD (appelés APUs) proposent exactement les mêmes fonctionnalités que leurs homologues de bureau sur carte. La différence est le nombre de transistors et d’unités de calcul implémentées. C’est similaire à ce qui se passe du côté des CPUs, tu peux avoir un petit CPU Ryzen avec 6 cœurs ou un gros CPU ThreadRipper avec 64 cœurs, et tu peux avoir une petite puce ou une grosse puce graphique. Ce qui change est donc le nombre d’unités de calcul, la fréquence (et donc la consommation électrique), le type de mémoire vive et comment la mémoire est connectée (essentiellement une affaire de fréquence et de bande passante), le nombre de lignes PCI express (là encore de la bande passante) mais en terme de fonctionnalités c’est pareil. Pour une même génération, la différence entre une puce intégrée et une grosse carte graphique de chez AMD est uniquement la performance.
AMD a abandonné sa gamme mobile Imageon en 2009 en la revendant à Qualcomm dont le nom de la puce adreno et un anagramme de radeon en clin d’œil à leur origin... Donc depuis 2009 il n’y a plus de puce basse consommation AMD qui diffère techniquement des puces AMD haute performance.
Ces puces mobiles devenues "adreno" qui sont similaires à ta puce Mali (et qu’on retrouve aussi dans des SoC ARM) ne sont plus produites par AMD depuis 17 ans. Les puces adreno ont des limitations similaires aux puces Mali, mais ce ne sont pas des puces AMD. Tu peux prendre une puce AMD les yeux fermés et tu auras OpenGL 4.6.
mon "pc" actuel avec un rk3588 (Arm Mali) implémente la dernière version de Vulkan, mais OpenGL n'est qu'en version 3.1 parce que les fonctionnalités d'OpenGL 4.3, ou plus, ne sont pas fondues dans le silicone (c'est ce que je comprends).
Il est possible (je n’ai pas vérifié) que des fonctionnalités soient implémentable mais pas encore implémentées. Pour des raisons pragmatiques et pratiques, Mesa se focalise d’abord sur « le minimum vital » pour que la puce graphique soit utilisable, notamment par les environnements de bureau. Ça veut dire OpenGL 2.1 dès que possible et OpenGL 3.1 aussi vite. OpenGL 3.1 c’est la version de base de l’OpenGL actuel, en quelque sorte toutes les versions supplémentaires ne sont que des collections d’extensions par dessus. OpenGL 2.1 peut être vue comme une version immature mais très proche d’OpenGL 3.1, donc il est peu coûteux d’adapter un logiciel 3.1 pour 2.1. Mesa vise donc ces objectifs en premier. C’est ce qui permet aux distributions de fournir un bureau moderne fonctionnel. Il y a aussi OpenGL ES, mais tu vois l’idée, le but c’est de faire marcher les gestionnaires de connexion et environnements de bureau standards. Une fois que OpenGL 3.1 est implémenté on peut considérer que « le boulot est fait ».
Il est donc tout à fait possible que le Mali rk3588 soit capable de bien plus qu’OpenGL 3.1 mais que Mesa n’ai pas encore implémenté plus. Là encore si on regarde la page mesamatrix dans la colonne panfrost, on voit qu’une seule extension de OpenGL 3.2 est manquante (les geometry shaders), mais que toutes les extensions de 3.3 sont déjà implémentées. Donc dans l’hypothèse où les geometry shaders seraient implémentables, les jour où ils le sont Mesa passera directement de GL 3.1 à GL 3.3.
Comme je le disais, OpenGL 3.1+ sont surtout des extensions, une version n’est déclarée comme prise en charge que lorsque toutes les extensions de cette version sont prises en charge, mais la prise en charge de chaque extension est déclarée indépendamment. Il peut donc être possible de faire tourner un logiciel GL 4.3 sur un pilote qui n’annonce que 3.1 si en fait les seules extensions requises par le logiciel sont déjà implémentées. On peut voir encore sur mesamatrix que le pilote panfrost implémente déjà des extensions de GL 4.6. Donc si Blender ne tourne pas c’est que soi :
Blender ne s’embête pas à regarder la prise en charge extension par extension, ou que
Blender requiert une extension qui n’est pas implémentée, comme les geometry shaders
La seconde hypothèse est tout de même la plus probable.
Aussi les puces Mali comme la majorité des puces implémentées sur les SoC ARM sont des puces mobiles avec certaines limitations matérielles. Pour reprendre l’exemple des geometry shaders qui limitent ta puce graphique à GL 3.1, il est possible que:
la puce soit capable de geometry shaders mais que Mesa ne l’implémente pas encore, ou que
Mesa puisse émuler les geometry shaders au prix d’une performance moindre, ou que
il soit techniquement impossible d’implémenter les geometry shaders
Il y a des chances que la situation soit la seconde hypothèse. Si je ne me trompe pas les geometry shaders sont aussi optionnels dans Vulkan.
Je ne sais pas ce qui bloque exactement dans Blender, mais c’est probablement un truc du genre.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Intéressant merci
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche AMD mise tout sur RADV. Évalué à 4. Dernière modification le 13 avril 2026 à 12:13.
Bonjour, les GPU AMD prennent en charge OpenGL 4.6. Tu peux regarder sur mesamatrix:
Dans la rubrique "OpenGL", tu peux cliquer sur "Drivers details" pour dérouler le tableau détaillé.
Toutes les cartes AMD GCN et RDNA prennent en charge OpenGL 4.6, et il me semble aussi que les plus anciennes TeraScale 2 et TeraScale 3 prennent aussi en charge OpenGL 4.6 (TeraScale 2 c’est l’année 2009).
Tous les GPUs intégrés AMD (appelés APUs) proposent exactement les mêmes fonctionnalités que leurs homologues de bureau sur carte. La différence est le nombre de transistors et d’unités de calcul implémentées. C’est similaire à ce qui se passe du côté des CPUs, tu peux avoir un petit CPU Ryzen avec 6 cœurs ou un gros CPU ThreadRipper avec 64 cœurs, et tu peux avoir une petite puce ou une grosse puce graphique. Ce qui change est donc le nombre d’unités de calcul, la fréquence (et donc la consommation électrique), le type de mémoire vive et comment la mémoire est connectée (essentiellement une affaire de fréquence et de bande passante), le nombre de lignes PCI express (là encore de la bande passante) mais en terme de fonctionnalités c’est pareil. Pour une même génération, la différence entre une puce intégrée et une grosse carte graphique de chez AMD est uniquement la performance.
AMD a abandonné sa gamme mobile Imageon en 2009 en la revendant à Qualcomm dont le nom de la puce adreno et un anagramme de radeon en clin d’œil à leur origin... Donc depuis 2009 il n’y a plus de puce basse consommation AMD qui diffère techniquement des puces AMD haute performance.
Ces puces mobiles devenues "adreno" qui sont similaires à ta puce Mali (et qu’on retrouve aussi dans des SoC ARM) ne sont plus produites par AMD depuis 17 ans. Les puces adreno ont des limitations similaires aux puces Mali, mais ce ne sont pas des puces AMD. Tu peux prendre une puce AMD les yeux fermés et tu auras OpenGL 4.6.
Il est possible (je n’ai pas vérifié) que des fonctionnalités soient implémentable mais pas encore implémentées. Pour des raisons pragmatiques et pratiques, Mesa se focalise d’abord sur « le minimum vital » pour que la puce graphique soit utilisable, notamment par les environnements de bureau. Ça veut dire OpenGL 2.1 dès que possible et OpenGL 3.1 aussi vite. OpenGL 3.1 c’est la version de base de l’OpenGL actuel, en quelque sorte toutes les versions supplémentaires ne sont que des collections d’extensions par dessus. OpenGL 2.1 peut être vue comme une version immature mais très proche d’OpenGL 3.1, donc il est peu coûteux d’adapter un logiciel 3.1 pour 2.1. Mesa vise donc ces objectifs en premier. C’est ce qui permet aux distributions de fournir un bureau moderne fonctionnel. Il y a aussi OpenGL ES, mais tu vois l’idée, le but c’est de faire marcher les gestionnaires de connexion et environnements de bureau standards. Une fois que OpenGL 3.1 est implémenté on peut considérer que « le boulot est fait ».
Il est donc tout à fait possible que le Mali rk3588 soit capable de bien plus qu’OpenGL 3.1 mais que Mesa n’ai pas encore implémenté plus. Là encore si on regarde la page mesamatrix dans la colonne panfrost, on voit qu’une seule extension de OpenGL 3.2 est manquante (les geometry shaders), mais que toutes les extensions de 3.3 sont déjà implémentées. Donc dans l’hypothèse où les geometry shaders seraient implémentables, les jour où ils le sont Mesa passera directement de GL 3.1 à GL 3.3.
Comme je le disais, OpenGL 3.1+ sont surtout des extensions, une version n’est déclarée comme prise en charge que lorsque toutes les extensions de cette version sont prises en charge, mais la prise en charge de chaque extension est déclarée indépendamment. Il peut donc être possible de faire tourner un logiciel GL 4.3 sur un pilote qui n’annonce que 3.1 si en fait les seules extensions requises par le logiciel sont déjà implémentées. On peut voir encore sur mesamatrix que le pilote panfrost implémente déjà des extensions de GL 4.6. Donc si Blender ne tourne pas c’est que soi :
La seconde hypothèse est tout de même la plus probable.
Aussi les puces Mali comme la majorité des puces implémentées sur les SoC ARM sont des puces mobiles avec certaines limitations matérielles. Pour reprendre l’exemple des geometry shaders qui limitent ta puce graphique à GL 3.1, il est possible que:
Il y a des chances que la situation soit la seconde hypothèse. Si je ne me trompe pas les geometry shaders sont aussi optionnels dans Vulkan.
Je ne sais pas ce qui bloque exactement dans Blender, mais c’est probablement un truc du genre.
ce commentaire est sous licence cc by 4 et précédentes