Le SIGGRAPH (célèbre conférence américaine annuelle sur l'infographie et la programmation graphique) qui vient de se dérouler du 7 au 9 août dernier à Los Angeles a été l'occasion de quelques annonces intéressant le monde du logiciel libre, s'agissant des API OpenGL / OpenGL ES et de leur support par les systèmes GNU/Linux.
Sommaire
- Khronos annonce les sorties d'OpenGL 4.3 et OpenGL ES 3.0, lesquelles se dotent enfin d'un format libre de compression des textures
- OpenGL 3.1 bientôt dans Mesa
- OpenGL ES 3.0 dans Mesa début 2013
Khronos annonce les sorties d'OpenGL 4.3 et OpenGL ES 3.0, lesquelles se dotent enfin d'un format libre de compression des textures
Le Khronos Group, l'organisme chargé de standardiser notamment OpenGL (la spécification libre pour programmer des animations 3D temps réel qui seront ensuite accélérées par le processeur graphique) et OpenGL ES (la version d'OpenGL adaptée aux appareils mobiles) annonce la sortie respectivement des versions 4.3 et 3.0 de ces spécifications, et surtout disponibilité d'un format de compression de textures libre de droits (ETC, offert par Ericsson) capable de concurrencer le S3TC, actuel standard de fait soumis à redevance et inclus dans DirectX (schématiquement : l'équivalent d'OpenGL non-libre et réservé à l'écosystème Microsoft Windows).
Une bonne nouvelle n'arrivant jamais seule, le successeur libre de droits de l'ETC et du S3TC est également présenté ; il s'agit de l'ASTC, issu des travaux conjoints de ARM Holdings et Nvidia.
Rappelons qu'actuellement Mesa, l'implémentation libre d'OpenGL pour systèmes GNU/Linux et cousins :
- plafonne à la version 3.0 d'OpenGL ;
- ne prend pas en charge par défaut le format S3TC pour des questions de brevets dans la mesure où certains pays reconnaissent la possibilité de tels brevets (une bibliothèque logicielle ad hoc doit donc être installée par l'utilisateur).
Tout ceci témoigne du fait que les acteurs du monde mobile (où le système Windows n'est pas dominant) avaient désespérément besoin de s'entendre sur un format libre et unique de compression des textures (l'espace de stockage limité de ces appareils ainsi que la nécessité de bénéficier d'une prise en charge au niveau matériel de la compression des textures impliquent d'éviter de devoir stocker une même texture dans différents formats…). Reste à savoir si cela suffira pour se débarrasser du format non-libre S3TC, déjà bien implémenté (vous vous souvenez de la compétition H264 vs VP8/WebM ?).
OpenGL 3.1 bientôt dans Mesa
L'implémentation de la version 3.1 d'OpenGL dans Mesa pourrait être finalisée prochainement (dans Mesa 9.0, en septembre ?) grâce aux efforts de l'Intel OSTC (Open-Source Technology Center).
La récente collaboration de Valve Corporation avec les fabricants de processeurs graphiques — dont Intel — en vue du portage du client Steam et du jeu (non-libre) « Left 4 Dead 2 » sur systèmes GNU/Linux aurait-elle à voir avec ces efforts redoublés ?
OpenGL ES 3.0 dans Mesa début 2013
De manière tout à fait surprenante, la version 3.0 d'OpenGL ES qui vient tout juste d'être officialisée devrait avoir son implémentation libre dès le 1er trimestre 2013 (février ?) dans Mesa, toujours suite aux efforts de l'Intel OSTC.
Les premières puces à en profiter devraient être les HD Graphics d'Intel présentes dans les actuels processeurs Sandy Bridge et Ivy Bridge (soit respectivement les HD 2000/3000 et 2500/4000). En effet, on sait qu'Intel n'apprécie guère de voir le marché des appareils mobiles (où OpenGL ES est la norme) dominé par les architectures ARM concurrentes de l'architecture x86 qu'il promeut, et qu'il prévoit une offensive début 2013 sous la forme d'un SoC répondant au nom de code « Valley View », soit un processeur graphique de même génération que celui équipant les derniers processeurs Ivy Bridge, couplé à un processeur Atom (à noter également à ce sujet que, parallèlement, Intel travaille à porter Android 4.1 « Jelly Bean » pour ses processeurs Atom).
Nous terminons cette dépêche par une triste nouvelle : Eugeni Dodonov, employé enthousiaste chez Intel au sein de l'OSTC depuis moins d'un an, est décédé accidentellement le mois dernier à l'âge de 31 ans. Sincères condoléances à sa famille, ses amis et ses collègues.
# OpenGL ES
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Ou pas. Si je me souviens bien, OpenGL est assez limité et utilise des extensions, prises en charge ou non par les cartes graphiques, pour tout ce qui sort de la spécification de base. Résultat, le programmeur ne sait pas trop ce qui pourra être fait ou non parmi tout ce qu'il code.
OpenGL ES est effectivement né pour les appareils mobiles. Il me semble qu'il s'agit d'une liste de fonctions à prendre en charge, ce qui répondait à un besoin absolument pas spécifique aux appareils mobiles. Du coup, on se retrouve avec des logiciels qui n'ont rien à voir avec la mobilité, qui utilisent OpenGL ES…
[^] # Re: OpenGL ES
Posté par Bruno Ethvignot (site web personnel) . Évalué à 3.
Par exemple le code de Wayland, qui n'est pas dédié à l'embarqué, utilise OpenGL ES.
[^] # Re: OpenGL ES
Posté par ariasuni . Évalué à 3.
Kwin peut utiliser OpenGL ES également, et il paraît que ça donne de meilleures performances. En gros c'est un OpenGL castré pour l'embraqué, et il semble que ça soit plus rapide…
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: OpenGL ES
Posté par moi1392 . Évalué à 10.
Castré n'est pas vraiment le mot, OpenGL ES est sensé contenir une unique version des fonctionnalités de base pour avoir un rendu 3D, en gros les plus performantes et les plus proches de la carte graphique.
L'intérêt pour l'embarqué et qu'on supprime énormément de code utilisé pour maintenir la compatibilité avec les fonctionnalités "habituelles" d'OpenGL (en gros, OpenGL < 3)
Donc ça fait moins de code, mois d'espace disque et d'espace mémoire utilisé, et en bonus, on force les utilisateurs à utiliser une API plus proche du matériel qui, à priori, est plus performante.
En simplifiant, OpenGL = OpenGL ES + fonctionnalités supplémentaires dépréciées (fixed pipe, direct mode, display lists, …) + des fonctions utilitaires en plus.
[^] # Re: OpenGL ES
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Ça confirme et précise ce que je pensais : OpenGL était assez bordélique et variable selon les cartes graphiques. Ça devait déjà poser problème sur les ordinateurs de bureau, ça en posait encore plus pour les appareils mobiles, donc on a créé OpenGL ES pour simplifier et organiser, et bien évidemment ça n'intéresse pas que les mobiles mais bel et bien tout le monde.
[^] # Re: OpenGL ES
Posté par moi1392 . Évalué à 9.
Le problème d'OpenGL est que les très vielles fonctions sont toujours supportées, ça fait beaucoup de code dans les pilotes, car plus rien de tout ça n'est cablé directement dans les puces graphiques, et du coup ça augmente de beaucoup l'emprunte mémoire de la libGL (de plusieurs Mo, y'a qu'à voir la libGL de nvidia ou amd), pour de l'embarqué, c'est complètement redhibitoire.
En plus, y'a régulièrement des bugs et des soucis de performances liés aux anciennes fonctionnalités (je m'en tape de temps en temps au boulot)
À vérifier tout de même, mais il me semble que du code OpenGL ES est 100% compatible OpenGL, sauf la partie connexion avec le système de fenêtres.
Dans le cas de X11, c'est glX qui fait ça. Pour OpenGL ES, c'est EGL, et c'est sensé être une couche d'abstraction unique pour toutes les plateformes.
Pour faire la même chose avec OpenGL, il y a OpenGL 3 core (à partir d'OGL 3.1) qui déprécie toutes les vielles fonctionnalités des entêtes avec le défine qui va bien.
Donc le mieux je dirais c'est soit de coder en OpenGL ES si on vise aussi l'embarqué, soit en OGL3 Core si on est exclusif au desktop.
[^] # Re: OpenGL ES
Posté par Narishma Jahar . Évalué à 3.
OpenGL ES 3.0 sera un sous-ensemble de OpenGL 4.3.
Les précédentes versions n'étaient pas 100% compatibles avec OpenGL.
[^] # Re: OpenGL ES
Posté par glisse . Évalué à 10.
Non opengl n'est pas bordelique, tu crees un context opengl tu demandes la version gl et tu sais exactement ce qui est disponible. La meme chose se passe avec opengles. Il n'y a aucune difference de ce point de vue.
L'avantage d'opengles est du cote des drivers, opengles ne s'encombre pas de tout un tas d'aspect qu'opengl continue de supporter, ca rend l'ecriture de driver bien plus simple et plus efficace sans reellement impacter les utilisateurs car de toute maniere ces fonctions opengl sont rarement utilise (hors mis le vieux mode de rendu direct).
[^] # Re: OpenGL ES
Posté par maeln . Évalué à 10.
Effectivement, OpenGL permet ( et c'était un de ce grand argument contre DirectX ) à l’implémentation de proposer ces propres extension. Toutefois, il est facile de dissocié les extensions officielles du standard préfixé GL_EXT et le standard lui même préfixé GL_ARB des extensions constructeur préfixé GL_NV, GL_AMD, GL_ATI, … Sachant qu'une carte Nvidia peut très bien supporté des extensions GL_ATI et vice-versa.
Cela a notamment permis, il me semble, un support de la Tesselation avec OpenGL bien avant DirectX grâce à une extension constructeur.
Le développeur peut aussi facilement vérifier si une extension est disponible sur la machine client en utilisant glew avec par exemple la fonction :
# Libre de droits?
Posté par etenil . Évalué à 4.
Je ne comprend pas vraiment le sens de "libre de droit" ici. J'ai bien trouvé la licence du kit de dévelopement de ETC, qui ne ressemble pas à une licence libre, mais rien sur le format lui-même ou les brevets qui pourraient s'y appliquer.
Pourrais tu expliquer le sens de la formule fourre-tout "libre de droits" dans le cas présent?
[^] # Re: Libre de droits?
Posté par antistress (site web personnel) . Évalué à 4.
Ericsson autorise l'implémentation d'ETC sans demander de royalties (dans les pays reconnaissant les brevets logiciels). L'implémentation pourra alors être libre (au sens du droit d'auteur cette fois) ou pas.
[^] # Re: Libre de droits?
Posté par Thomas Debesse (site web personnel) . Évalué à 10.
L'expression « libre de droit » n'a pas grand chose avec le libre, c'est une mauvaise traduction de « royalty-free », où « droit » est une mauvaise traduction de « royalty » malheureusement courante en langue française. Une œuvre n'a pas de droit, c'est l'auteur qui a le droit d'obliger, l'œuvre est donc accompagnée d'obligations qui peuvent être exprimées sous forme de redevance.
L'expression « sans redevance » est plus juste mais moins usitée.
Cependant, pour un format, ce n'est pas forcément nécessaire qu'il soit libre, s'il est ouvert et sans redevance, ça permet déjà de faire des logiciels libres !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Libre de droits?
Posté par antistress (site web personnel) . Évalué à 5.
oui, "sans redevance" serait moins équivoque :-)
# OpenGL 4
Posté par ariasuni . Évalué à 3.
Si ça existe depuis quelques temps déjà, pourquoi on est toujours à OpenGL 3 ? La faute aux constucteurs de carte graphiques ?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: OpenGL 4
Posté par maeln . Évalué à 3.
On en est même pas à OpenGL 3.x pour la plupart des moteurs graphiques, malheureusement OpenGL 2.x prédomine encore.
Et oui, la faute incombe en partie au constructeur, notamment Intel puisque la plupart de ces drivers ne supporte absolument pas OpenGL 3.x et difficilement OpenGL 2.1. AMD/ATI et Nvidia implémente, maintenant, rapidement les dernières spécifications d'OpenGL ( à peine la 4.3 était sortie que Nidia proposait déjà des drivers béta la supportant ), mais j'ai entendu dire que leurs implémentations d'OpenGL était pourrie dans le passé.
Sinon, la faute incombe aussi au vieillissement du materiel, les veilles CG et une bonne partie des Chipset Graphique s'étant arrêté à OpenGL 2.
[^] # Re: OpenGL 4
Posté par alpha_one_x86 (site web personnel) . Évalué à 6. Dernière modification le 13 août 2012 à 12:40.
Fautes en partie aux drivers libres, car même quand les doc du hardware sont dispo (amd, intel), les devs qualifiés sont assez rare pour avancer rapidement sur les drivers libres.
J'ai 3 ati radeon HD (4000 - 6000), toutes en OpenGL2 max (OpenGL4 supporté), et certaine ne supporte le multi-écran que avec les drivers proprio.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: OpenGL 4
Posté par claudex . Évalué à 4.
Bizarre, je vois 3.0 sur RadeonFeature pour les Evergreen (hd 6000).
« 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: OpenGL 4
Posté par Guillaum (site web personnel) . Évalué à 10.
AMD est en gl 4.2, on attend le driver 4.3, mais la sortie de GL 4.3 datant d'une semaine, j'estime cela une attente pour l'instant correcte.
Nvidia est en GL 4.3, Rien à dire.
Intel est en GL 4.1 ou 4.0 sous windows exclusivement, GL 3.0 sous linux. Maintenant il faut aussi voir que jusqu'à cet été (sortie des HD4000 d'intel), la plupart des cartes graphiques du marché (ie: intel) ne supportaient pas la tesselation matériel, donc pas besoin de GL >= 4.0.
Pas la moindre idée pour les constructeurs mobiles.
AMD et Nvidia sont à jour, intel n'est pas pressé car ils ne visent pas le même marché (ie: les gamers du dimanche ont des drivers GL 4 pour windows pour faire tourner les jeux GL… en fait non, il n'y a pas de jeux GL… Sous linux, plateforme sur laquelle il n'y a pas de jeu, direct X où GL, on s'en cogne, GL 3.0 est suffisant pour le Desktop, et les rares personnes qui voudraient des drivers GL 4 pour cartes intel, je n'en connais pas à part moi (qui aimerait tester mes algos de recherche même quand je suis en balade avec mon ordinateur portable)
Donc globalement la faute au constructeur, mais bon, ici le constructeur qui est le plus à la traîne, c'est celui qui fait du libre, donc c'est peut-être en grande partie aussi la faute au stack libre qui traîne un peu.
Maintenant il faut aussi voir que les versions de GL correspondent aussi à un support matériel particulier.
Par exemple, entre gl 4.0 et 3.3, c'est le support de la tesselation. GL 4.2 apporte le support des atomics et GL 4.3 apporte le support du compute shader (une sorte de cuda/opencl mieux intégré à GL)
Maintenant pour un développeur qui n'a pas besoin de cela, il peut facilement vivre en GL 3.3. (3.3 nettoie beaucoup de choses, et coder du GL 3.2 c'est l'horreur, surtout pour écrire les shaders). Il peut faire la même chose en GL 3.2 et si il ne se sert pas du geometry shader, il supportera GL 3.1/3.0.
De plus la plupart des dev de jeu utilisent toujours un vieux GL avec les extensions qui vont bien, ainsi il est possible d'avoir accès à l'api gl 4.0 sur une carte qui date un peu, mais certaines fonctionnalités seront lente ou indisponible. Si je ne me trompe pas je crois que doom 3 est exclusivement écrit en GL 1.0 + extensions.
Donc ce qui manque pour que cela bouge c'est à mon sens plus de produit tout public gl 4.3 (en fait des produits qui utilisent VRAIMENT les fonctionnalités de GL 4.3, mais qui n'ont pas besoin d'une carte graphique puissante) et ces produits cela va étre des jeux. Et c'est là que cela devient intéressant, parce que les jeux mobile c'est justement ce qui monte et dans ce domaine GL ES est presque incontournable. Mais GL ES ne couvre pas beaucoup de fonctionnalités "Desktop only" fournie par GL (il faut que je relise la spec pour ne pas dire de connerie, mais il n'y a pas de compute shader, pas de tesellation, pas d'atomic et pas de geometry)
[^] # Re: OpenGL 4
Posté par deasy . Évalué à 2.
Il n'y a qu'idsoftware et Starbreeze/Tigon Studios qui utilisent OpenGL pour les jeux sur Windows.
Pour les "gros" studios.
Il y a sans doute une part d'indépendants qui l'utilisent également.
[^] # Re: OpenGL 4
Posté par maeln . Évalué à 6.
Blizzard l'utilise aussi pour ses jeux. Le moteur supporte aussi D3D sous Windows mais il est possible de forcer oGL.
[^] # Re: OpenGL 4
Posté par Narann (site web personnel) . Évalué à 0.
Si je ne dis pas de bêtises, OpenGL4 implique une gestion hardware des flottant 64bits. Un matos conçu pour OpenGL3 n'est donc pas nécessairement compatible avec de l'OpenGL4.
[^] # Re: OpenGL 4
Posté par mickabouille . Évalué à 5.
Je pense que comme c'est une spec, ça dit juste ce qui doit être supporté, pas comment.
Dire "support hardware", c'est un détail d'implémentation, pas une spécification.
Mesa a longtemps implémenté OpenGL sans aucun support hardware.
Dire dans la spec que le support hard des flottants 64 bit est requis veut dire pas d'implémentations soft (comme softpipe ou llvmpipe).
Mais je peux me tromper.
[^] # Re: OpenGL 4
Posté par Guillaum (site web personnel) . Évalué à 3.
Non, tu as raison (si je ne me trompe pas).
GL n'impose RIEN quand au support materiel, GL ne fait que proposer une API qui pourra optionnelement etre accelerée par le hardware.
Ici sur une carte Nvidia haut de gamme, les float 64 bits sont plus lent que les 32, mais cela va.
Sur ma carte AMD entrée de gamme, ils ont beau etre suportés (ie: cela marche), les performances sont 100x plus lentes que pour les float 32bits.
[^] # Re: OpenGL 4
Posté par deasy . Évalué à 1. Dernière modification le 14 août 2012 à 18:23.
Le support pleine vitesse pour le 64bits ne se fait que sur le haut de gamme sur la série 7xxx(79xx donc).
Il faut regarder avant d'acheter pour ce besoin précis.
[^] # Re: OpenGL 4
Posté par deasy . Évalué à 1.
http://en.wikipedia.org/wiki/Comparison_of_AMD_graphics_processing_units
[^] # Re: OpenGL 4
Posté par antistress (site web personnel) . Évalué à 10.
OpenGL 3.0 est arrivé récemment dans Mesa : implémenté par Intel à partir du moment où il y avait intérêt = à partir du moment où ses processeurs le supportaient (Sandy Bridge).
OpenGL 3.1 suit pour la même raison, de même OpenGL ES 3.0.
Nvidia n'investit pas dans l'architecture logicielle graphique libre de Linux, et AMD n'y met que des moyens modestes. Ces deux là supportent certainement les dernières versions d'OpenGL avec leurs drivers proprio (à vérifier).
Intel de son côté propose uniquement des drivers libres pour ses chips maison donc l'architecture logicielle graphique libre de Linux progresse au rythme d'Intel en gros…
# DX != D3D
Posté par Artefact2 (site web personnel) . Évalué à 6.
s/DirectX/Direct3D/
[^] # Re: DX != D3D
Posté par antistress (site web personnel) . Évalué à 9.
d'où le « schématiquement »; je voyais pas l'intérêt de développer ce point ;-)
[^] # Re: DX != D3D
Posté par coïn . Évalué à 8.
schématiquement ou pas, la précision est importante.
DirectX est un ensemble de technologie (les plus connues : Direct3D, DirectDraw, DirectMusic, DirectPlay, DirectSound mais il y en a d'autres http://en.wikipedia.org/wiki/DirectX#Components ) et OpenGl est l'équivalent uniquement de Direct3D.
Bien évidement, il existe des bibliothèques libres à opposer à chaque composant DirectX, chacun à différents stades de maturités, niveau de finition.
# API après ?
Posté par pseudovalide . Évalué à 2.
Les spécifications, les drivers, oui d'accord, mais on programme comment ?
Je veux dire, ma carte implémente opengl 4.1, en dure quoi, dans son microcode j'imagine.
Mais moi, bidouilleur amateur, j'accède comment à ses merveilles ? Glut.h ? Mais glut, c'est opengl 1.2 non ?
Et puis faut faire du C, beurk, vade retro.
J'avais trouvé l'API Lumen pour Ada.
[^] # Re: API après ?
Posté par Meku (site web personnel) . Évalué à 4.
La spécification te donne la liste des fonctions C qui doivent être disponibles par une implémentation OpenGL. Si tu veux utiliser un autre langage, il faut faire des bindings sur l'API en C.
GLUT n'est pas OpenGL, c'est une bibliothèque utilitaire qui sert notamment à instancier des fenêtres avec un contexte OpenGL et gérer les inputs. La bibliothèque GLUT originelle n'est plus maintenue depuis longtemps et n'est pas totalement libre (il me semble qu'on n'a pas le droit de redistribuer les modifications), mais une implémentation libre, freeglut, réimplémente son API et apporte des fonctionnalités supplémentaires.
[^] # Re: API après ?
Posté par Olivier Serve (site web personnel) . Évalué à 3.
Une carte n'implémente pas OpenGL (ni DirectX d'ailleurs) directement. Elle ne fait qu'apporter un support matériel adapté à ces API. Ce sont les pilotes voire une couche au-dessus (Mesa, libGL proprio…) qui proposent l'API OpenGL.
J'avais joué un peu avec OpenGL en suivant les tutoriels présents sur http://nehe.gamedev.net/
[^] # Re: API après ?
Posté par pseudovalide . Évalué à 1.
bon en même temps, entre "implémenter" et "apporter un support matériel",
la différence est pas formidable…
[^] # Re: API après ?
Posté par Olivier Serve (site web personnel) . Évalué à 2.
Ce que je voulais dire, c'est que les fonctions D3D/OpenGL ne sont pas câblées sur la carte. Ni même dans un microcode.
Tout comme l'algorithme zip (par exemple) n'est pas câblé dans les processeurs.
[^] # Re: API après ?
Posté par maeln . Évalué à 8.
Je déconseille ces tutoriels : Ils utilisent OpenGL 2.x qui est largement obsolète. Pour apprendre à utiliser OpenGL 3.x je conseille Le tutoriel de Jason L. McKesson ou Le wikibook, y'a aussi open.gl mais je ne sais pas ce qu'il vaut.
[^] # Re: API après ?
Posté par Olivier Serve (site web personnel) . Évalué à 3.
Ah, merci beaucoup pour ces liens.
# OpenGL sous Linux plus rapide que Direct3D sous Windows
Posté par Krunch (site web personnel) . Évalué à 3.
http://blogs.valvesoftware.com/linux/faster-zombies/
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: OpenGL sous Linux plus rapide que Direct3D sous Windows
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 3.
Comparer les performances entre un système 32bit et un autre 64bit, c'est un peu prendre les lecteurs pour des melons.
# Tout savoir sur ETC2
Posté par antistress (site web personnel) . Évalué à 3.
ETC2 Texture Compression Looks Good For OpenGL
Par ailleurs : ETC2 Texture Compression For Intel Is Happening
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.