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.
Tu me dis trois réponses plus bas que OpenGL est une spec pas une implementation.(Ce qui est parfaitement exact par ailleurs). Or l'interpretation ou non des HINTS peut être fait en hard directement en mettant le bon regsitre à la bonne valeur. En hard indirectement en activant ou en coupant certaines fonctions via d'autres registres ou encore en soft dans le pilote avec des bidouilles qui impliquent plus ou moins var pas du tout des interventions dans le hard.
Maintenant en ce qui concerne les TNT. Je me fous de savoir qu'il y ait un registre GL_HINT dans la carte et que les geforce ne possèdent pas de registre similaire. Quand la TNT est sortie on était au tout début de l'OpenGL , et le pilote de base windows était pur soft. J'ignore complètement si la TNT gérait correctement les HINTS ou pas.
Par contre je peu te dire que la Quadro sortie quelques années après, qui était une super Geforce, elle les gérait de façon tout à fait correcte. Même si il n'y a pas de registres dédiés dans le hard. Ca devait se régler à coup de paramétrage du T&L ou autres gruikeries soft+hard mais là j'ai pas le code des pilotes de l'époque.
Par contre je peux te dire que les HINTS ca comptait pas mal, et à ma connaissance ca compte toujours pas mal dans le monde professionnel. Dans le dernier bouquin papier que j'ai acheté, le Red Book 2004 OpenGL 1.4 page 243 sur le GL_FOG_HINT il est écrit que le GL_Nicest fait un calcul par pixel et que le GL_FASTEST fait un rendu par vertex. Ca change pas mal le rendu pour les pros.
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.
Peut être me suis-je mal exprimé sur celle là, parceque j'ai une autre réponse qui va dans le même sens plus haut. La question est : combien de surfaces de rendu OpenGL distinctes (i.e chacune avec son paramétrage et éventuellement sa ) je peux gérer en même temps sur une carte grand public. Et de façon générale combien de surfaces de rendus accélérées 3D je peux gérer simultanément, chacune avec ses propres composantes. Bien que la carte grand public n'est jamais été mon fort, des gros balèzes de Beyond3D répondaient assez souvent "une seule" à cette question.
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"
J'ai essayé des trucs comme çà avec des drivers proprios et libres sur des cartes ATI et ca c'est jamais vraiment bien passé. Ca venait peut être d'ATI ou de mes configs. Là je ne peux rien affirmer il faut que je trouve le temps et que je reteste complètement.
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.
Il y a des pages entières de la spec qui concernent le "software callback", comment il peut être géré par les implémenteurs et comment avoir une path software fallback est une bonne idée au cas ou on viendrait à manquer de ressources, comment gérer les buffers et les OUT OF BOUNDS quand on est amené à faire un software fallback. Comment doubler certaines infos en cas de possibilité de software fallback etc.
J'imagine que ca ne compte pas....
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.
C'est exactement ce que je dis. Quake2 n'utilisait que du RGB, c'était même pas la peine d'essayer d'utiliser un autre espace de couleur si on voulait de l'acceleration sur les cartes de salon. On repassait en soft direct.
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.
GL_SMOOTH quand il est utilisé dans le cadre de glShadeModel déclenche un rendu de type Gouraud shading pour peu que l'on ait les bon vertex aux bons endroits. C'est très pratique même sur les textures quand ca se mélange à des infos d'éclairage. Par exemple http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=07 qui est très basique et old school, mais qui met bien en exergue entre GL_SMOOTH et GL_FLAT même sur un objet texturé.
Et bien à l'époque Quake2 Avec les pilotes OpenGL de merde qu'on se trimballait à la maison, GL_FLAT + chargement d'une texture => retour en mode soft.
Non, tu n'as pas à valider la texture
Ah bon ? La fonction glGetTexLevelParameteriv est morte ? On fait quoi on part du principe que la texture est forcément compressée comme il faut, qu'elle va tenir en mémoire et que le proxy va accepter son format sans broncher ?
tu n'as pas à explicitement la décompresser (fait par la carte)
Tu sais quoi tu n'as pas non plus explicitement à venir chez l'utilisateur pour tracer tes triangles, c'est aussi fait par la carte. Mais il faut expliquer à la carte en question que c'est une texture compressée, il faut la mettre dans un buffer avec les bons paramètres et si il y a proxy il faut être gentil avec lui aussi. C'est un peu ce que j'apelle "décompresser" la texture.
ni à la transformer en texels 2D (ça veut rien dire)
Je t'accorde l'horrible abus de langage. Mais bon à un moment ou un autre il va bien falloir recouvrir un ensemble de polygones avec une succession de textures, éventuellement shadés. Car c'est bien le shading qui va casser les piedstant au niveau vertex pour le polygone sous-jacent, qu'au niveau pixel pour la texture elle même.
Oh si parlons-en. En OpenGL l'anisotropique s'active en 1 ligne : glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_MAX_ANISOTROPY_EXT, 8.0)
Oui, une fois que tu as sorti tes mipmaps, que tu as choisis ceux que tu voulais et que tu les a appliqués comme il faut. Ce qui prend une page.
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.
J'ai peur qu'il ne te faille recommencer depuis le début.
[^] # 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.
Tu me dis trois réponses plus bas que OpenGL est une spec pas une implementation.(Ce qui est parfaitement exact par ailleurs). Or l'interpretation ou non des HINTS peut être fait en hard directement en mettant le bon regsitre à la bonne valeur. En hard indirectement en activant ou en coupant certaines fonctions via d'autres registres ou encore en soft dans le pilote avec des bidouilles qui impliquent plus ou moins var pas du tout des interventions dans le hard.
Maintenant en ce qui concerne les TNT. Je me fous de savoir qu'il y ait un registre GL_HINT dans la carte et que les geforce ne possèdent pas de registre similaire. Quand la TNT est sortie on était au tout début de l'OpenGL , et le pilote de base windows était pur soft. J'ignore complètement si la TNT gérait correctement les HINTS ou pas.
Par contre je peu te dire que la Quadro sortie quelques années après, qui était une super Geforce, elle les gérait de façon tout à fait correcte. Même si il n'y a pas de registres dédiés dans le hard. Ca devait se régler à coup de paramétrage du T&L ou autres gruikeries soft+hard mais là j'ai pas le code des pilotes de l'époque.
Par contre je peux te dire que les HINTS ca comptait pas mal, et à ma connaissance ca compte toujours pas mal dans le monde professionnel. Dans le dernier bouquin papier que j'ai acheté, le Red Book 2004 OpenGL 1.4 page 243 sur le GL_FOG_HINT il est écrit que le GL_Nicest fait un calcul par pixel et que le GL_FASTEST fait un rendu par vertex. Ca change pas mal le rendu pour les pros.
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.
Peut être me suis-je mal exprimé sur celle là, parceque j'ai une autre réponse qui va dans le même sens plus haut. La question est : combien de surfaces de rendu OpenGL distinctes (i.e chacune avec son paramétrage et éventuellement sa ) je peux gérer en même temps sur une carte grand public. Et de façon générale combien de surfaces de rendus accélérées 3D je peux gérer simultanément, chacune avec ses propres composantes. Bien que la carte grand public n'est jamais été mon fort, des gros balèzes de Beyond3D répondaient assez souvent "une seule" à cette question.
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"
J'ai essayé des trucs comme çà avec des drivers proprios et libres sur des cartes ATI et ca c'est jamais vraiment bien passé. Ca venait peut être d'ATI ou de mes configs. Là je ne peux rien affirmer il faut que je trouve le temps et que je reteste complètement.
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.
Il y a des pages entières de la spec qui concernent le "software callback", comment il peut être géré par les implémenteurs et comment avoir une path software fallback est une bonne idée au cas ou on viendrait à manquer de ressources, comment gérer les buffers et les OUT OF BOUNDS quand on est amené à faire un software fallback. Comment doubler certaines infos en cas de possibilité de software fallback etc.
J'imagine que ca ne compte pas....
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.
C'est exactement ce que je dis. Quake2 n'utilisait que du RGB, c'était même pas la peine d'essayer d'utiliser un autre espace de couleur si on voulait de l'acceleration sur les cartes de salon. On repassait en soft direct.
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.
GL_SMOOTH quand il est utilisé dans le cadre de glShadeModel déclenche un rendu de type Gouraud shading pour peu que l'on ait les bon vertex aux bons endroits. C'est très pratique même sur les textures quand ca se mélange à des infos d'éclairage. Par exemple http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=07 qui est très basique et old school, mais qui met bien en exergue entre GL_SMOOTH et GL_FLAT même sur un objet texturé.
Et bien à l'époque Quake2 Avec les pilotes OpenGL de merde qu'on se trimballait à la maison, GL_FLAT + chargement d'une texture => retour en mode soft.
Non, tu n'as pas à valider la texture
Ah bon ? La fonction glGetTexLevelParameteriv est morte ? On fait quoi on part du principe que la texture est forcément compressée comme il faut, qu'elle va tenir en mémoire et que le proxy va accepter son format sans broncher ?
tu n'as pas à explicitement la décompresser (fait par la carte)
Tu sais quoi tu n'as pas non plus explicitement à venir chez l'utilisateur pour tracer tes triangles, c'est aussi fait par la carte. Mais il faut expliquer à la carte en question que c'est une texture compressée, il faut la mettre dans un buffer avec les bons paramètres et si il y a proxy il faut être gentil avec lui aussi. C'est un peu ce que j'apelle "décompresser" la texture.
ni à la transformer en texels 2D (ça veut rien dire)
Je t'accorde l'horrible abus de langage. Mais bon à un moment ou un autre il va bien falloir recouvrir un ensemble de polygones avec une succession de textures, éventuellement shadés. Car c'est bien le shading qui va casser les piedstant au niveau vertex pour le polygone sous-jacent, qu'au niveau pixel pour la texture elle même.
Oh si parlons-en. En OpenGL l'anisotropique s'active en 1 ligne : glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_MAX_ANISOTROPY_EXT, 8.0)
Oui, une fois que tu as sorti tes mipmaps, que tu as choisis ceux que tu voulais et que tu les a appliqués comme il faut. Ce qui prend une page.
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.
J'ai peur qu'il ne te faille recommencer depuis le début.