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.
Non, encore une fois c'est faux. Toutes les cartes nvidia depuis la première geforce n'ont pas de quoi gérer les hints dont tu parles, les hint en question n'existent plus et ne servent à rien. Source : je suis le fondateur de nouveau donc je connais le hard nvidia un peu. Et si tu ne me crois pas les specs des cartes nvidia qu'on a RE sont bien au chaud dans un fichier xml : http://nouveau.cvs.sourceforge.net/viewvc/nouveau/renouveau/(...)
Tu verras que seules les TNT ont les fameux hints.
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.
Non. Des instances séparées de libGL sont utilisées pour chaque appli OpenGL que tu lances. Source : je suis dev X.Org et mesa.
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.
Non c'est faux. Tu peux très bien utiliser LD_PRELOAD si tu veux un autre implémentation de GL (par exemple du mesa soft dans une certaine appli au lieu d'un driver DRI).
Source : t'as qu'à essayer LD_PRELOAD=/path/to/mesa/libGL.so ./monappli et tu auras du rendu soft. Tout ça sans "recharger ton X.Org"
OpenGL possède de base des mécanismes pour faire en software ce qu'il ne sait pas faire en Hardware.
Non, OpenGL est une spec, et une spec n'a pas de mécanismes pour faire des trucs en software. Source : va voir sur opengl.org et tu verras que c'est une spec.
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.
Non, Quake 1/2 n'a jamais utilisé aucun truc en espace de couleur YUV. Source : lis le code source de quake 1/2. C'est tout du RGB.
Idem si on charge les textures avec autre chose que du GL_SMOOTH.
Non, GL_SMOOTH ne s'applique pas aux textures. Source : la doc OpenGL qui explique que GL_SMOOTH s'applique a l'interpolation des couleurs sur les facettes et non pas l'interpolation des textures.
- 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.
Non, tu n'as pas à valider la texture, tu n'as pas à explicitement la décompresser (fait par la carte), ni à la transformer en texels 2D (ça veut rien dire), ni à corriger la perspective (c'est fait tout seul). Source : les docs OpenGL.
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.
Enfin bref, encore une fois, j'ai montré point par point que tu dis n'importe quoi et que tu dénigres OpenGL sans fondement. Tu as lu 3 keywords OpenGL et tu crois connaître l'API. Encore une fois, c'est ça le gros problème d'OpenGL, le fait que les gens mal renseignés parlent en mal du bouzin mais écoutent le marketting à microsoft. Et le sens critique dans tout ça il est où ? On dirait une bande de moutons...
Bêêêêêêêêêeee
PS: alors, le fait que Direct3D ait des shaders séparés comme OpenGL, pourri ou pas pourri du coup ? Si c'est pourri dans OpenGL, c'est pourri dans Direct3D non ?
[^] # Re: C'est bien son truc... Sauf que c'est faux.
Posté par Stephane Marchesin . En réponse au journal Une analyse des librairies graphiques par un développeur de jeux vidéos. Évalué à 10.
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.
Non, encore une fois c'est faux. Toutes les cartes nvidia depuis la première geforce n'ont pas de quoi gérer les hints dont tu parles, les hint en question n'existent plus et ne servent à rien. Source : je suis le fondateur de nouveau donc je connais le hard nvidia un peu. Et si tu ne me crois pas les specs des cartes nvidia qu'on a RE sont bien au chaud dans un fichier xml : http://nouveau.cvs.sourceforge.net/viewvc/nouveau/renouveau/(...)
Tu verras que seules les TNT ont les fameux hints.
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.
Non. Des instances séparées de libGL sont utilisées pour chaque appli OpenGL que tu lances. Source : je suis dev X.Org et mesa.
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.
Non c'est faux. Tu peux très bien utiliser LD_PRELOAD si tu veux un autre implémentation de GL (par exemple du mesa soft dans une certaine appli au lieu d'un driver DRI).
Source : t'as qu'à essayer LD_PRELOAD=/path/to/mesa/libGL.so ./monappli et tu auras du rendu soft. Tout ça sans "recharger ton X.Org"
OpenGL possède de base des mécanismes pour faire en software ce qu'il ne sait pas faire en Hardware.
Non, OpenGL est une spec, et une spec n'a pas de mécanismes pour faire des trucs en software. Source : va voir sur opengl.org et tu verras que c'est une spec.
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.
Non, Quake 1/2 n'a jamais utilisé aucun truc en espace de couleur YUV. Source : lis le code source de quake 1/2. C'est tout du RGB.
Idem si on charge les textures avec autre chose que du GL_SMOOTH.
Non, GL_SMOOTH ne s'applique pas aux textures. Source : la doc OpenGL qui explique que GL_SMOOTH s'applique a l'interpolation des couleurs sur les facettes et non pas l'interpolation des textures.
- 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.
Non, tu n'as pas à valider la texture, tu n'as pas à explicitement la décompresser (fait par la carte), ni à la transformer en texels 2D (ça veut rien dire), ni à corriger la perspective (c'est fait tout seul). Source : les docs OpenGL.
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.
Oh si parlons-en. En OpenGL l'anisotropique s'active en 1 ligne : glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_MAX_ANISOTROPY_EXT, 8.0);
Source : http://www.opengl.org/registry/specs/EXT/texture_filter_anis(...)
Enfin bref, encore une fois, j'ai montré point par point que tu dis n'importe quoi et que tu dénigres OpenGL sans fondement. Tu as lu 3 keywords OpenGL et tu crois connaître l'API. Encore une fois, c'est ça le gros problème d'OpenGL, le fait que les gens mal renseignés parlent en mal du bouzin mais écoutent le marketting à microsoft. Et le sens critique dans tout ça il est où ? On dirait une bande de moutons...
Bêêêêêêêêêeee
PS: alors, le fait que Direct3D ait des shaders séparés comme OpenGL, pourri ou pas pourri du coup ? Si c'est pourri dans OpenGL, c'est pourri dans Direct3D non ?