Non c'est faux, ces hints sont optionnels, et en plus au moins 90% des drivers ne les implémentent pas. Et pour cause, le hardware video n'a plus de fonctionnalité pour réaliser ces hints (pour référence le dernier hardware nvidia à implementer ces hints c'est la TNT/TNT2, les générations suivantes ont l'équivalent de GL_NICEST et c'est tout).
Trois petites choses :
Quand la TNT est est sortie, on ne parlait pas vraiment d'OpenGL hardware sur Windows pour Nvidia. Le pilote de base OpenGL sous windows 95 était pur soft.
Et kes drivers qui existait à l'époque s'installait à coup de copie de DLL et d'édition de base de registre.
Les hints sont essentiels dans la plupart des applis professionnelles. Car le rendu diffère vraiment d'un cas à l'autre.
Les denière générations de Cartes 3D sur lesquelles j'ai bossé chez NVidia (à savoir les 8000) font un peu ce qu'elles veulent et ignorent les hints. Certains rendus sont fait en GL_Nicest, les autres sont fait en ce qu'on peut. Et tant pis si il y a des Z aliasing ou des déformations à la con parceque le pilote fait des arrondis un peu cavalier. Certes il s'agit de cartes de desktop, donc ce n'est pas grave techniquement. Mais d'un autre coté ca oblige à tester son rendu carte par carte pour savoir sil il est propre ou pas.
Encore une fois c'est faux. Avoir plusieurs applications OpenGL avec l'acceleration, on y arrive sous X.Org (avec compositing et tout le bordem) et aucune des instances ne tourne en soft. Tu imagines sinon ? Tu tournes compiz (== 1 appli OpenGL) et après tu n'as plus d'accélération 3D
L'architecture Xorg fait que toutes les applis utilisent la même instance avec le composting. L'avantage est que plusieurs applis peuvent faire de l'OpenGL en même temps, l'inconvennient est que toutes les applis sont impactées si il y a un problème. Par exemple si tu charges une vidéo en mode texture dans une appli, tout le monde morfle.
Autre inconvennient tu ne peux pas charger des pilotes spécifiques à ton appli. C'est le même tarif pour tout le monde. Si tu veux faire de l'accéleré Hardware pour un pré-rendu et ensuite du Mesa pour un rendu correct techniquement, tu es bon pour recharger ton Xorg entre les deux.
Si tu parles de drivers miniport, ce n'est pas fait pour quake2. En fait miniport est une couche simplifiée entre OpenGL et le driver windows qui permet de faire un driver OpenGL plus facilement, et laisser miniport implémenter les trucs un peu tordus de manière générique en logiciel. Si tu regardes les cartes de l'époque, elles ne pouvaient pas accélerer tout OpenGL, donc elles auraient de toute façon du implémenter ces fameux fallback en logiciel. Pour résumer, les trucs que miniport faisait en logiciel, tu ne les avais pas dans direct3D.
OpenGL possède de base des mécanismes pour faire en software ce qu'il ne sait pas faire en Hardware. Les mini ports vont plus loin, ils permettent de faire en rendu hardware certaines fonctions OpenGL sous certaines conditions, mais de retomber en rendu soft si la même fonction est appelée dans d'autres conditions. Historiquement les certaines fonctions en question étaient celles utilisées par Quake 2 et les certaines conditions celles de Quake 2. Déjà toutes les fonctions qui n'utilisaient pas GL_RGB mais un autre espace de couleur (au hasard YUV pour plaquer des vidéo) repassaient en soft immédiatement. Alors que les cartes de l'époque (TNT2, ATI Xpert, Millenium G100, Millenium G200 etc.) savaient convertir le YUV en RGB en Hard.
Idem si on charge les textures avec autre chose que du GL_SMOOTH.
Ah voilà un exemple intéressant, celui du transform and lightning. Les applications qui étaient écrites en OpenGL 1.0 (ou plus) ont pu exploiter le transform and lighting sans avoir besoin de recompilation/modification d'aucun genre.
Oui OpenGL supportait le T&L depuis longtemps. Mais pas les pilotes de carte graphique (ni les cartes graphiques d'ailleurs). OpenGL gère tout le pipeline de rendu, donc forcément le T&L aussi. Mais il faudra attendre que la Geforce sorte et qu'elle décide de faire un pilote OpenGL 1.3 pour que l'on ait un semblant de T&L OpenGL sous windows. Sous Linux/Unix/autre il faudra attendre 2002, soit la FireGL d'ATI pour avoir un semblant de support T&L sur Radeon 9000. Alors que les shaders sont déjà en train de remplacer le système T&L.
Concrètement, tu voudrais quels changements dans OpenGL
Comme tout le monde ou presque :
- Une vraie rupture de compatibilité, ou à défaut un hint qui permette de dire si l'on veut utiliser les fonctions OpenGL en mode 3.0 ou en mode deprecated. celà permettrait de faire un grand ménage dans tout un tas de fonctions qui ne sont plus utilisées par personne aujourd'hui. C'était la principale promesse d'OpenGL 3.0.
Un exemple tout con : plaquer une texture S3TC/DXTC sur un cube demande une page complète de code, pour charger la texture, la valider, la binder, la décompresser, la transformer en texels 2D, l'appliquer, corriger la perspective, la lisser et enfin l'afficher. Et là je parle même pas de charger plusieurs résolutions de textures pour faire du filtering aniso. En DirectX 8+ ca ne prend que quelques lignes.
- Les shaders OpenGL sont surpuissant. On peu les rentrer à n'importe quel niveau du traitement de rendu pour les repasser dans la moulinette, seulement c'est horriblement complexe. En DirectX il y a pleins de méthode pour réintégrer facilement des shaders au étapes de tesselations ou d'illumanitions pour les vertex, et aux étapes de mapping et d'illumination pour les pixels. Certes c'est plus limité, mais d'un autre coté c'est aussi nettement plus simple à mettre en place. Les ponts Direct3D <-> Shaders tout pret sont plus nombreux en DirectX.
- Les hints OpenGL sont gentils, mais il y en a un peu trop, un peu trop souvent. En Direct3D on décide une fois pour toute ce que l'on veut appliquer comme méthode ou pas. Et normalement c'est bon. En OpenGL il est théoriquement possible de faire de l'aniso pointu sur une texture tout en faisant un plaquage à l'arrache sur une autre texture du même objet. Il serait bon que l'on puisse définir une table des sélections par défaut et que l'on ait pas à repasser 122 000 arguments à chaque fonction de rendu ou de chargement de modèle.
Encore une fois j'ai l'impression que OpenGL a surtout un problème de communication (au point que même les geeks de linuxfr le renient) en face de la machine de communication de Microsoft.
Le DirectX qui a explosé et qui a placé Microsoft en tête des API de jeux vidéos c'est le 5.0. A l'époque tous les gamers avaient des cartes 3DFX, Le dieu du Jeu Vidéo (Carmack) bossait exclusivement en OpenGL et la bibliothèque de rendu finale (msvcrt.dll) était bugguée jusqu'à la moelle. En plus en 1999/2000 toutes les cartes gamers possédaient un OpenGL 1.2 complet et un OpenGL 1.3 bien avancé.
Malgré tout ces défauts DirectX a gagné haut la main, face à Glide et face à OpenGL. C'est pas juste un problème de com, c'est un problème de COM (quel humour). Utiliser OpenGL de façon propre, efficace et sans casser windows était un casse tête sans nom. DirectX plus limité était aussi plus simple et raccourcissait grandement les temps de dev. Par la suite OpenGL a loupé coche sur coche (filtering avancé, compression de texture, antialiasing, shaders tout celà existe sous OpenGL mais est assez complexe a mettre en place) alors que DirectX s'étoffait.
Aujourd'hui OpenGL est toujours aussi complexe à mettre en place, alors que DirectX a su évolué et combler ses lacunes tout en restant assez simple. Bien entendu aucun jeu vidéo professionnel du devant de la scène (les jeux microtruc c'est moins sur) n'utilise les fonctions DirectX brut de décoffrage. Mais DirectX permet d'avoir très vite un truc qui marche complètement. Quand on sait que le temps de dev d'un jeu est de deux à trois ans et qu'il y a un changement majeur de méthodes de programmation tous les 18 mois, c'est pratique.
[^] # Re: C'est bien son truc... Sauf que c'est faux.
Posté par Jerome Herman . En réponse au journal Une analyse des librairies graphiques par un développeur de jeux vidéos. Évalué à 2.
Trois petites choses :
Quand la TNT est est sortie, on ne parlait pas vraiment d'OpenGL hardware sur Windows pour Nvidia. Le pilote de base OpenGL sous windows 95 était pur soft.
Et kes drivers qui existait à l'époque s'installait à coup de copie de DLL et d'édition de base de registre.
Les hints sont essentiels dans la plupart des applis professionnelles. Car le rendu diffère vraiment d'un cas à l'autre.
Les denière générations de Cartes 3D sur lesquelles j'ai bossé chez NVidia (à savoir les 8000) font un peu ce qu'elles veulent et ignorent les hints. Certains rendus sont fait en GL_Nicest, les autres sont fait en ce qu'on peut. Et tant pis si il y a des Z aliasing ou des déformations à la con parceque le pilote fait des arrondis un peu cavalier. Certes il s'agit de cartes de desktop, donc ce n'est pas grave techniquement. Mais d'un autre coté ca oblige à tester son rendu carte par carte pour savoir sil il est propre ou pas.
Encore une fois c'est faux. Avoir plusieurs applications OpenGL avec l'acceleration, on y arrive sous X.Org (avec compositing et tout le bordem) et aucune des instances ne tourne en soft. Tu imagines sinon ? Tu tournes compiz (== 1 appli OpenGL) et après tu n'as plus d'accélération 3D
L'architecture Xorg fait que toutes les applis utilisent la même instance avec le composting. L'avantage est que plusieurs applis peuvent faire de l'OpenGL en même temps, l'inconvennient est que toutes les applis sont impactées si il y a un problème. Par exemple si tu charges une vidéo en mode texture dans une appli, tout le monde morfle.
Autre inconvennient tu ne peux pas charger des pilotes spécifiques à ton appli. C'est le même tarif pour tout le monde. Si tu veux faire de l'accéleré Hardware pour un pré-rendu et ensuite du Mesa pour un rendu correct techniquement, tu es bon pour recharger ton Xorg entre les deux.
Si tu parles de drivers miniport, ce n'est pas fait pour quake2. En fait miniport est une couche simplifiée entre OpenGL et le driver windows qui permet de faire un driver OpenGL plus facilement, et laisser miniport implémenter les trucs un peu tordus de manière générique en logiciel. Si tu regardes les cartes de l'époque, elles ne pouvaient pas accélerer tout OpenGL, donc elles auraient de toute façon du implémenter ces fameux fallback en logiciel. Pour résumer, les trucs que miniport faisait en logiciel, tu ne les avais pas dans direct3D.
OpenGL possède de base des mécanismes pour faire en software ce qu'il ne sait pas faire en Hardware. Les mini ports vont plus loin, ils permettent de faire en rendu hardware certaines fonctions OpenGL sous certaines conditions, mais de retomber en rendu soft si la même fonction est appelée dans d'autres conditions. Historiquement les certaines fonctions en question étaient celles utilisées par Quake 2 et les certaines conditions celles de Quake 2. Déjà toutes les fonctions qui n'utilisaient pas GL_RGB mais un autre espace de couleur (au hasard YUV pour plaquer des vidéo) repassaient en soft immédiatement. Alors que les cartes de l'époque (TNT2, ATI Xpert, Millenium G100, Millenium G200 etc.) savaient convertir le YUV en RGB en Hard.
Idem si on charge les textures avec autre chose que du GL_SMOOTH.
Ah voilà un exemple intéressant, celui du transform and lightning. Les applications qui étaient écrites en OpenGL 1.0 (ou plus) ont pu exploiter le transform and lighting sans avoir besoin de recompilation/modification d'aucun genre.
Oui OpenGL supportait le T&L depuis longtemps. Mais pas les pilotes de carte graphique (ni les cartes graphiques d'ailleurs). OpenGL gère tout le pipeline de rendu, donc forcément le T&L aussi. Mais il faudra attendre que la Geforce sorte et qu'elle décide de faire un pilote OpenGL 1.3 pour que l'on ait un semblant de T&L OpenGL sous windows. Sous Linux/Unix/autre il faudra attendre 2002, soit la FireGL d'ATI pour avoir un semblant de support T&L sur Radeon 9000. Alors que les shaders sont déjà en train de remplacer le système T&L.
Concrètement, tu voudrais quels changements dans OpenGL
Comme tout le monde ou presque :
- Une vraie rupture de compatibilité, ou à défaut un hint qui permette de dire si l'on veut utiliser les fonctions OpenGL en mode 3.0 ou en mode deprecated. celà permettrait de faire un grand ménage dans tout un tas de fonctions qui ne sont plus utilisées par personne aujourd'hui. C'était la principale promesse d'OpenGL 3.0.
Un exemple tout con : plaquer une texture S3TC/DXTC sur un cube demande une page complète de code, pour charger la texture, la valider, la binder, la décompresser, la transformer en texels 2D, l'appliquer, corriger la perspective, la lisser et enfin l'afficher. Et là je parle même pas de charger plusieurs résolutions de textures pour faire du filtering aniso. En DirectX 8+ ca ne prend que quelques lignes.
- Les shaders OpenGL sont surpuissant. On peu les rentrer à n'importe quel niveau du traitement de rendu pour les repasser dans la moulinette, seulement c'est horriblement complexe. En DirectX il y a pleins de méthode pour réintégrer facilement des shaders au étapes de tesselations ou d'illumanitions pour les vertex, et aux étapes de mapping et d'illumination pour les pixels. Certes c'est plus limité, mais d'un autre coté c'est aussi nettement plus simple à mettre en place. Les ponts Direct3D <-> Shaders tout pret sont plus nombreux en DirectX.
- Les hints OpenGL sont gentils, mais il y en a un peu trop, un peu trop souvent. En Direct3D on décide une fois pour toute ce que l'on veut appliquer comme méthode ou pas. Et normalement c'est bon. En OpenGL il est théoriquement possible de faire de l'aniso pointu sur une texture tout en faisant un plaquage à l'arrache sur une autre texture du même objet. Il serait bon que l'on puisse définir une table des sélections par défaut et que l'on ait pas à repasser 122 000 arguments à chaque fonction de rendu ou de chargement de modèle.
Encore une fois j'ai l'impression que OpenGL a surtout un problème de communication (au point que même les geeks de linuxfr le renient) en face de la machine de communication de Microsoft.
Le DirectX qui a explosé et qui a placé Microsoft en tête des API de jeux vidéos c'est le 5.0. A l'époque tous les gamers avaient des cartes 3DFX, Le dieu du Jeu Vidéo (Carmack) bossait exclusivement en OpenGL et la bibliothèque de rendu finale (msvcrt.dll) était bugguée jusqu'à la moelle. En plus en 1999/2000 toutes les cartes gamers possédaient un OpenGL 1.2 complet et un OpenGL 1.3 bien avancé.
Malgré tout ces défauts DirectX a gagné haut la main, face à Glide et face à OpenGL. C'est pas juste un problème de com, c'est un problème de COM (quel humour). Utiliser OpenGL de façon propre, efficace et sans casser windows était un casse tête sans nom. DirectX plus limité était aussi plus simple et raccourcissait grandement les temps de dev. Par la suite OpenGL a loupé coche sur coche (filtering avancé, compression de texture, antialiasing, shaders tout celà existe sous OpenGL mais est assez complexe a mettre en place) alors que DirectX s'étoffait.
Aujourd'hui OpenGL est toujours aussi complexe à mettre en place, alors que DirectX a su évolué et combler ses lacunes tout en restant assez simple. Bien entendu aucun jeu vidéo professionnel du devant de la scène (les jeux microtruc c'est moins sur) n'utilise les fonctions DirectX brut de décoffrage. Mais DirectX permet d'avoir très vite un truc qui marche complètement. Quand on sait que le temps de dev d'un jeu est de deux à trois ans et qu'il y a un changement majeur de méthodes de programmation tous les 18 mois, c'est pratique.