Bof, je suis moyennement d'accord avec toi sur le fond, et pas du tout sur certains points techniques. Par exemple :
La première chose que l'on fait quand on écrit un programme OpenGL est de définir quelle sera la qualité du rendu, en d'autres termes quelle précision de calcul on veut. Cette option va de GL_Default jusqu'à GL_Nicest.
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).
OpenGL gère l'ensemble du pipeline de rendu graphique de la carte vidéo. Ce qui est très bien pour un rendu de précision, mais qui pose un véritable problème dans le cadre d'un PC de bureau. Si vous lancez une application OpenGL, elle va mettre la main sur tout un pipeline de rendu. Donc si vous lancez une seconde application OpenGL, soit vous avez une carte graphique professionnelle avec Autant de pipeline que nécessaire, soit la seconde application ne sera pas accélérée 3D et passera en mode pur soft. Sous Direct3D il est tout à fait possible d'accélerer simultanément plusieurs rendus, car c'est le système et non l'appli qui fait le dispatch des traitements. C'est pour celà que sous Vista et 7 tant que l'on a pas désactivé Aero, les performances OpenGL sont assez limitée. Bon Microsoft a sorti un patch qui fait que si l'appli OpenGL passe en plein écran aero va faire dodo et on a des perfs correctes, mais en fenétré c'est une catastrophe.
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, on se ferait massacrer. Après si c'est la merde sous Vista c'est la faute de Microsoft et c'est tout, pas besoin d'accuser OpenGL. OpenGL ce n'est pas une grosse main qui attrape ta carte video et qui après ne veut pas la rendre :)
Seulement il s'agissait de Mini-Drivers, c'est à dire de pilote conçus pour faire tourner Quake 2 et rien d'autre. Pas un vrai support OpenGL.
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.
Et puis OpenGL 1.3 est sorti. Et là les fabriquants de cartes graphique sont éclatés de rire et se sont tournés vers Directx7 qui était beaucoup plus raisonnable en terme de puissance demandé pour un résultat correct. C'est un petit nouveau : NVidia qui est venu mettre la pagaille dans tout çà, en annonçant coup sur coup le support du transform and Lightning sur Directx7 et le support complet d'openGL 1.3 (Bon complet du tronc principal de l'ARB, toutes les extensions officielles n'étant pas supportée). La geforce va se vendre comme des petits pains. Et les autres constructeurs corrigent leur copie pour utiliser à fond OpenGL 1.3.
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. A côté de ça microsoft a introduit DirectX 7 comme une révolution et tout le monde a trouvé géniale l'idée du Transform and lighting. Et ça m'amène au point principal que je veux soulever : c'est le marketting qui fait que DirectX/Direct3D gagne, et c'est tout.
OpenGL 3.0 qui devait corriger le tir et devenir un direct3D Killer prend un an de retard sans pratiquement aucune communication du groupe Khronos. Finalement loin de la refonte attendue qui aurait permis de rendre OpenGL utile dans uen optique de jeu, c'est une suite logique d'OpenGL 2.0 qui sort avec ses archaisme et ses shaders séparés. La puissance de calcul nécessaire pour faire de l'OpenGL 3.x en hardware, et la complexité de programmation clouent définitvement OpenGL au sol. Son apotre Carmack prend sa retraite et pouf.
Concrètement, tu voudrais quels changements dans OpenGL ? Par exemple tu critiques les shaders séparés, mais Direct3D 10 et OpenGL 3.0 ont tous les deux des shaders séparés. Donc d'après ton critère, Direct3D 10 est aussi nul que OpenGL ? D'ailleurs les APIs sont très proches, ayant pratiqué les 2 je trouve qu'on passe de l'un à l'autre sans souci.
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. Alors certes cet article est partisan, mais mettons un peu les choses en perspective et comparons-le au marketting fait pour Direct3D. Je pense que tout le monde est d'accord pour dire qu'il y a encore quelques ordres de grandeur de différence :)
[^] # 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.
La première chose que l'on fait quand on écrit un programme OpenGL est de définir quelle sera la qualité du rendu, en d'autres termes quelle précision de calcul on veut. Cette option va de GL_Default jusqu'à GL_Nicest.
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).
OpenGL gère l'ensemble du pipeline de rendu graphique de la carte vidéo. Ce qui est très bien pour un rendu de précision, mais qui pose un véritable problème dans le cadre d'un PC de bureau. Si vous lancez une application OpenGL, elle va mettre la main sur tout un pipeline de rendu. Donc si vous lancez une seconde application OpenGL, soit vous avez une carte graphique professionnelle avec Autant de pipeline que nécessaire, soit la seconde application ne sera pas accélérée 3D et passera en mode pur soft. Sous Direct3D il est tout à fait possible d'accélerer simultanément plusieurs rendus, car c'est le système et non l'appli qui fait le dispatch des traitements. C'est pour celà que sous Vista et 7 tant que l'on a pas désactivé Aero, les performances OpenGL sont assez limitée. Bon Microsoft a sorti un patch qui fait que si l'appli OpenGL passe en plein écran aero va faire dodo et on a des perfs correctes, mais en fenétré c'est une catastrophe.
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, on se ferait massacrer. Après si c'est la merde sous Vista c'est la faute de Microsoft et c'est tout, pas besoin d'accuser OpenGL. OpenGL ce n'est pas une grosse main qui attrape ta carte video et qui après ne veut pas la rendre :)
Seulement il s'agissait de Mini-Drivers, c'est à dire de pilote conçus pour faire tourner Quake 2 et rien d'autre. Pas un vrai support OpenGL.
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.
Et puis OpenGL 1.3 est sorti. Et là les fabriquants de cartes graphique sont éclatés de rire et se sont tournés vers Directx7 qui était beaucoup plus raisonnable en terme de puissance demandé pour un résultat correct. C'est un petit nouveau : NVidia qui est venu mettre la pagaille dans tout çà, en annonçant coup sur coup le support du transform and Lightning sur Directx7 et le support complet d'openGL 1.3 (Bon complet du tronc principal de l'ARB, toutes les extensions officielles n'étant pas supportée). La geforce va se vendre comme des petits pains. Et les autres constructeurs corrigent leur copie pour utiliser à fond OpenGL 1.3.
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. A côté de ça microsoft a introduit DirectX 7 comme une révolution et tout le monde a trouvé géniale l'idée du Transform and lighting. Et ça m'amène au point principal que je veux soulever : c'est le marketting qui fait que DirectX/Direct3D gagne, et c'est tout.
OpenGL 3.0 qui devait corriger le tir et devenir un direct3D Killer prend un an de retard sans pratiquement aucune communication du groupe Khronos. Finalement loin de la refonte attendue qui aurait permis de rendre OpenGL utile dans uen optique de jeu, c'est une suite logique d'OpenGL 2.0 qui sort avec ses archaisme et ses shaders séparés. La puissance de calcul nécessaire pour faire de l'OpenGL 3.x en hardware, et la complexité de programmation clouent définitvement OpenGL au sol. Son apotre Carmack prend sa retraite et pouf.
Concrètement, tu voudrais quels changements dans OpenGL ? Par exemple tu critiques les shaders séparés, mais Direct3D 10 et OpenGL 3.0 ont tous les deux des shaders séparés. Donc d'après ton critère, Direct3D 10 est aussi nul que OpenGL ? D'ailleurs les APIs sont très proches, ayant pratiqué les 2 je trouve qu'on passe de l'un à l'autre sans souci.
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. Alors certes cet article est partisan, mais mettons un peu les choses en perspective et comparons-le au marketting fait pour Direct3D. Je pense que tout le monde est d'accord pour dire qu'il y a encore quelques ordres de grandeur de différence :)