D'abord, il ne faut pas oublier qu'il s'agit d'une bibliothèque dont le but est de donner accès à du matériel. Hors, le fonctionnement des cartes graphiques a subi une évolution majeure, postérieure au succès d'OpenGL. Il ne s'agit pas juste de nouvelles possibilités, c'est la façon d'aborder le problème qui a changé (on est passé d'un pipeline fixe à un pipeline presque entièrement programmable).
En fait, paradoxalement, cette évolution a entraîné la disparition de certaines fonctionnalités. Car ce qui était avant figé sur la carte est devenu programmable (via les fameux shaders). On s'est retrouvé avec une API proposant des fonctionnalités que le matériel n'offrait pas : il a donc fallu que les drivers simulent ces fonctionnalités de façon logicielle. Avec, dans la plupart des cas, une baisse de performance dramatique ; il n'est pas facile d'expliquer pourquoi, mais l'API reposait sur un certains nombre d'hypothèses quand aux algorithmes utilisés, hypothèses qui ne peuvent plus être vérifiées puisque ces algorithmes sont aujourd'hui définis par le programmeur.
C'est pour cela que tes exemples ne sont pas complètement pertinents : car même si OpenGL a toujours permis d'obtenir les mêmes résultats que Direct3D (c'est à dire calculer les mêmes images), il y a eu une période où l'API était tellement éloignée du matériel qu'il devenait difficile d'obtenir ces résultats avec des performances raisonnables.
Ensuite, l'autre aspect dont parle Carmack, c'est qu'OpenGL n'est plus le moteur de l'innovation en matière de 3D. C'est maintenant Microsoft qui joue ce rôle (ou du moins qui coordonne et standardise les innovations des différents acteurs). Le Khronos Group ne fait que suivre, et je ne pense pas que la tendance s'inverse.
[^] # Re: Meilleure interface de développement, pas forcément meilleure 3D
Posté par drakmaniso . En réponse au journal Direct3D vs OpenGL. Évalué à 5.
Ce n'est pas aussi simple.
D'abord, il ne faut pas oublier qu'il s'agit d'une bibliothèque dont le but est de donner accès à du matériel. Hors, le fonctionnement des cartes graphiques a subi une évolution majeure, postérieure au succès d'OpenGL. Il ne s'agit pas juste de nouvelles possibilités, c'est la façon d'aborder le problème qui a changé (on est passé d'un pipeline fixe à un pipeline presque entièrement programmable).
En fait, paradoxalement, cette évolution a entraîné la disparition de certaines fonctionnalités. Car ce qui était avant figé sur la carte est devenu programmable (via les fameux shaders). On s'est retrouvé avec une API proposant des fonctionnalités que le matériel n'offrait pas : il a donc fallu que les drivers simulent ces fonctionnalités de façon logicielle. Avec, dans la plupart des cas, une baisse de performance dramatique ; il n'est pas facile d'expliquer pourquoi, mais l'API reposait sur un certains nombre d'hypothèses quand aux algorithmes utilisés, hypothèses qui ne peuvent plus être vérifiées puisque ces algorithmes sont aujourd'hui définis par le programmeur.
C'est pour cela que tes exemples ne sont pas complètement pertinents : car même si OpenGL a toujours permis d'obtenir les mêmes résultats que Direct3D (c'est à dire calculer les mêmes images), il y a eu une période où l'API était tellement éloignée du matériel qu'il devenait difficile d'obtenir ces résultats avec des performances raisonnables.
Ensuite, l'autre aspect dont parle Carmack, c'est qu'OpenGL n'est plus le moteur de l'innovation en matière de 3D. C'est maintenant Microsoft qui joue ce rôle (ou du moins qui coordonne et standardise les innovations des différents acteurs). Le Khronos Group ne fait que suivre, et je ne pense pas que la tendance s'inverse.