Nous sommes Vendredi !
http://www.bit-tech.net/news/gaming/2011/03/11/carmack-directx-better-opengl/1
Speaking to bit-tech for a forthcoming Custom PCfeature about the future of OpenGL in PC gaming, Carmack said 'I actually think that Direct3D is a rather better API today.' He also added that 'Microsoft had the courage to continue making significant incompatible changes to improve the API, while OpenGL has been held back by compatibility concerns. Direct3D handles multi-threading better, and newer versions manage state better.'
Lors d'un entretien pour un article à paraître dans CustomPC à propos du futur d'OpenGL dans les jeux PC, Carmack dit 'En fait je pense que Direct3D est un meilleur API aujourd'hui'. Il a aussi ajouté 'Microsoft a eu le courage de continuer à faire des changements significatifs, même au prix de la compatibilité, pour améliorer l'API alors qu'OpenGL a été ralenti par des inquiétudes sur la compatibilité. Direct3D gère mieux le multi-threading, et les versions récentes gèrent mieux le contexte."
'The actual innovation in graphics has definitely been driven by Microsoft in the last ten years or so,' explained AMD's GPU worldwide developer relations manager, Richard Huddy. 'OpenGL has largely been tracking that, rather than coming up with new methods. The geometry shader, for example, which came in with Vista and DirectX 10, is wholly Microsoft's invention in the first place.'
'Les innovations présentes dans le monde graphique ont clairement été poussées par Microsoft ces dix dernières années environ.' a expliqué Richard Huddy, manager des relations développeurs GPU au niveau mondial d'AMD. 'OpenGL a en grande partie suivi cela, plutôt qu'apporter de nouvelles techniques. Les geometry shaders par exemple, qui sont apparus avec Vista et DirectX, sont purement une invention de Microsoft au départ.'
À vos stylos, prêt ? Partez !!
# et en français ?
Posté par BAud (site web personnel) . Évalué à 1.
Je te laisse proposer une traduction en français des 2 / 5 paragraphes de ton journal (les accents je peux les ajouter).
[^] # Re: et en français ?
Posté par pasBill pasGates . Évalué à 2.
Speaking to bit-tech for a forthcoming Custom PCfeature about the future of OpenGL in PC gaming, Carmack said 'I actually think that Direct3D is a rather better API today.' He also added that 'Microsoft had the courage to continue making significant incompatible changes to improve the API, while OpenGL has been held back by compatibility concerns. Direct3D handles multi-threading better, and newer versions manage state better.'
Lors d'une interview pour un article a paraitre dans CustomPC a propos du futur d'OpenGL dans les jeux PC, Carmack dit 'En fait je pense que Direct3D est un meilleur API aujourd'hui'. Il ajouta aussi 'Microsoft a eu le courage de continuer a faire des changements significatifs, meme au prix de la compatibilite, pour ameliorer l'API alors qu'OpenGL a ete ralenti par des inquietudes sur la compatibilite. Direct3D gere mieux le multi-threading, et les versions recents gerent mieux le contexte."
'The actual innovation in graphics has definitely been driven by Microsoft in the last ten years or so,' explained AMD's GPU worldwide developer relations manager, Richard Huddy. 'OpenGL has largely been tracking that, rather than coming up with new methods. The geometry shader, for example, which came in with Vista and DirectX 10, is wholly Microsoft's invention in the first place.'
'Les innovations presents dans le monde graphique ont clairement ete poussees par Microsoft ces dix dernieres annees environ.' expliqua Richard Huddy, manager des relations developpeur GPU au niveau mondial d'AMD. 'OpenGL a en grande partie suivi cela, plutot qu'amener de nouvelles techniques. Les geometry shaders par exemple, qui sont apparus avec Vista et DirectX, sont purement une invention de Microsoft au depart.'
[^] # Re: et en français ?
Posté par BAud (site web personnel) . Évalué à 3.
merci, je me suis permis quelques adaptations et mise en forme :)
# Bah
Posté par yellowiscool . Évalué à 6.
C'est fort possible que Direct3D soit meilleur sur un plan technique.
Si je devais apprendre Direct3D ou OpenGL, je serais plus tenté pour Direct3D. Je ne connais rien aux deux, mais je trouve l'API OpenAL (son) merdique, et j'aime bien C# (avec mono évidemment).
Malheureusement, Direct3D n'est pas disponible sur Linux, et je ne sais même pas si c'est ouvert.
Après, la course aux types de shaders, je pense que l'on en a un peu rien à faire ici. KWin n'est toujours pas capable de gérer ses trois polygones par exemple…
Envoyé depuis mon lapin.
[^] # Re: Bah
Posté par Smarter . Évalué à 4.
Pour OpenAL, y'a Alure qui facilite le boulot: http://kcat.strangesoft.net/alure.html
[^] # Re: Bah
Posté par yellowiscool . Évalué à 1.
Je note, je note.
Pour mon projet actuel, le langage java est imposé.
Pour lire un son vorbis ou wave dans un espace 3D, j'ai donc :
J'aime les choses simple et claires.
Envoyé depuis mon lapin.
[^] # Re: Bah
Posté par Paf . Évalué à 1.
Si je veux faire simple, j'utilise http://jmonkeyengine.com/
[^] # Re: Bah
Posté par DLFP est mort . Évalué à 5.
Malheureusement, Direct3D n'est pas disponible sur Linux
Pas si sûr ;-)
http://cgit.freedesktop.org/mesa/mesa/commit/?id=92617aeac109481258f0c3863d09c1b8903d438b
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Bah
Posté par Gabin . Évalué à -2.
Si, il n'y a pas de support Direct3D.
Peut-être, je dis bien "peut-être" un projet en cours/future qui a 20ans à rattrapper, mais pas de support actuellement.
Les Linuxiens qui voient dans 3 lignes d'implémentation un support d'une quelconque techno, m'exaspèrent...
[^] # Re: Bah
Posté par DLFP est mort . Évalué à 1.
Qu'est-ce que tu ne comprends pas dans « Pas si sûr ;-) » ?
Par ailleurs, il y a 20 ans, Direct3D n'existait même pas.
Encore un pauvre troll qui vit dans un monde imaginaire.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Bah
Posté par Gabin . Évalué à -1.
Pas si sûr?
Si c'est certains, il n'y a pas de support Direct3D! On n'aura même pas un niveau équivalent à Mesa avant 5 ans au moins et encore, Mesa est basé sur un standard ouvert et on a pourtant du mal.
Tu peux prendre exemple sur Flash, afin d'apprécier la galère que c'est. Et pourtant t'as des linuxiens qui osent vendre du Gnash comme tu le prétends avec ton "pas si sûr".
Tiens, rajoute Mono à la liste. :)
# Journal: Direct3D vs OpenGL
Posté par Dellara . Évalué à -8.
Bof!
# Still works fine
Posté par drakmaniso . Évalué à 10.
À noter que plus bas dans l'article, Carmack explique qu'ils (ID Software) continuent d'utiliser OpenGL, parce qu'il n'y aurait pas (ou très peu) de gain de performance pour l'utilisateur final. Et comme tous leurs outils sont basés sur OpenGL, l'effort serait disproportionné.
Après, ce n'est pas une nouvelle que Microsoft a su réinventer avec succès son API 3D, pendant qu'OpenGL s'endormait tranquillement sur ses lauriers. Sommeil qui a frisé le coma, mais le Khronos Group a in extremis réussi à remettre le standard sur pied. Pas au point d'être à nouveau le meneur de jeu (et je ne suis pas sûr que cela puisse être possible), mais il reste une alternative viable.
Certes, l'API est d'un abord un peu rêche, mais il s'agit d'un outil bas niveau, qui est généralement très vite encapsulé. Il y a des problèmes autrement plus critiques dans la couche graphique des systèmes libres : l'état des drivers, par exemple ; ou bien la bloatitude du serveur X, pour rester dans l'esprit du vendredi.
[^] # Re: Still works fine
Posté par DLFP est mort . Évalué à 7.
Je trouve ironique que l'on loue d'un côté Microsoft pour avoir osé casser la compatibilité entre versions (et de mémoire, ils l'ont fait beaucoup avec DirectX) mais on critique Linux (entre autres) pour le faire.
Dans les deux cas, je trouve que c'est une bonne chose…
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Still works fine
Posté par pasBill pasGates . Évalué à 5.
C'est pas similaire.
Plusieurs versions de DirectX peuvent coexister sur le systeme, et c'est ce qu'il se passe. Sur les nouvelles releases de Windows, les anciennes versions de DirectX sont toujours la, et les nouvelles sont la aussi.
Un jeu pour XP, il tourne toujours sous Vista ou Win7. La difference etant qu'un jeu pour DirectX 10 ou 11 ne tournera pas sur XP
[^] # Re: Still works fine
Posté par Olivier (site web personnel) . Évalué à 2.
Les applications XP tournent tellement bien sous Seven, que Microsoft s'est cru obligé d'intégrer un Windows XP dans Seven, que celui-ci fait tourner via le virtualisateur maison...
En fait non, c'est juste histoire de gaspiller de la place sur le disque dur de l'utilisateur ? ;)
[^] # Re: Still works fine
Posté par pasBill pasGates . Évalué à 4.
Tu prends plus de 95% des softs, ils tournent sous Seven.
Ca laisse <5%, et MS propose une solution pour ceux la aussi.
Alors oui, les applications XP elles tournent pour leur enorme majorite tres bien sous Seven. Tu remarqueras d'ailleurs qu'aucune des versions 'non-entreprise' de Seven n'offrent cette virtualisation de XP, et personne ne s'en plaint.
[^] # Re: Still works fine
Posté par Grunt . Évalué à 7.
J'ai entendu dire que les applis qui ne fonctionne que sous XP n'avaient pas été codées en suivant les recommandations de Microsoft.
C'est possible aussi de faire du caca pareil sous Linux, hein.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Still works fine
Posté par pasBill pasGates . Évalué à 0.
Tu penses ? Visiblement tu n'ecrivais pas du code multithread au moment ou Linux a bascule de LinuxThreads a NPTL, ca a cause un vrai merdier pour plein de softs du fait des changements niveau design.
Et c'etait pas du caca hein, c'etait en suivant tout a fait normalement les APIs de LinuxThreads. Ils ont decide de casser la compat, et aujourd'hui ben il n'y a plus de LinuxThreads sur RHE 5 par exemple, et tu l'as dans le fion si tu veux faire tourner un ancien soft.
[^] # Re: Still works fine
Posté par Croconux . Évalué à 10.
La difference etant qu'un jeu pour DirectX 10 ou 11 ne tournera pas sur XP
Pour DirectX 10 c'est en partie faux. Microsoft a voulu réserver DX10 à Vista pour pousser les gens à mettre à jour leur OS. Dans la pratique, le blocage est juste un test dans le code. A l'époque, certains avaient proposé un patch pour faire sauter le blocage. Bilan, DX10 s'installait parfaitement sous XP et les jeux l'utilisant tournaient très bien (voire mieux que sous Vista, la lourdeur de l'OS en moins).
[^] # Re: Still works fine
Posté par Dorian . Évalué à 3.
Ça m'a l'air vrai : http://www.techmixer.com/install-directx-10-on-xp-with-directx10-rc2-pre-fix-3/
« En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll
# Tentative de troll ?
Posté par Ph Husson (site web personnel) . Évalué à -1.
Si cette tentative de troll prend, on sera tombé vraiment bien bas ...
Je pense pas qu'il y ait grand monde ici qui soit capable de répondre quoique ce soit là dessus.
[^] # Re: Tentative de troll ?
Posté par pasBill pasGates . Évalué à 2.
Eh ben si c'est pas triste ca, et moi, je vais faire quoi de mon week-end alors si ce troll demarre pas ?!?!
[^] # Re: Tentative de troll ?
Posté par pasScott pasForstall . Évalué à -4.
Je reviens de best buy, yavait un block de queue pour avoir un ipad 2 (ou plutot, pour s'entendre dire qu'ils ont deja tout vendu), j'ose pas imaginer le zoo que vont etre les apple store ce week end, tu te sens pas d'attaque pour troller la dessus?
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Tentative de troll ?
Posté par Arthur Geek (site web personnel) . Évalué à 4.
Essayer de commencer LFS?
Prochainement, je vous proposerai peut-être un commentaire constructif.
# Meilleure interface de développement, pas forcément meilleure 3D
Posté par Jehan (site web personnel, Mastodon) . Évalué à 9.
Bonjour,
je ne fais pas de 3D, mais je suis développeur. Et donc de ce que je comprends des termes employés, notez tout de même que Carmack ne semble pas critiquer la qualité finale d'OpenGL, mais son API seulement, ce qui pour nous programmeurs peut être synonyme de "simplicité d'utilisation". Pour exprimer cela simplement, voici une analyse du discours:
imaginez que pour dessiner un cube de côté l, une bonne API a une fonction
cube(l)alors qu'une moins bonne aurait la fonctionmake_a_regular_hexahedron(d)où d est la diagonale et non le côté. C'est chiant à développer car le nom de la fonction est plus long et mal choisi (un regular hexahedron est un cube, le nom n'est pas clair). Aussi bien que l'on sache sache calculer sans problème le côté en fonction de la diagonale et vis-versa, "en général" les gens vont vouloir dessiner un cube dont il connaisse le côté, non la diagonale. Donc la seconde fonction demandera la plupart du temps une ligne de calcul supplémentaire dans le code: paramètre mal choisi.C'est cela que l'on appelle une mauvaise API (Interface!) en général.
De même quand il parle de compatibilité, il entend donc une pratique courante. Plus tard, on se rend compte que notre fonction
make_a_regular_hexahedronest vraiment chiante à utiliser. On aimerait bien changer le nom et le type de paramètre. Mais voilà, plein de logiciels l'utilisent et si on change cela, ça va "casser" la compatibilité ascendante => les développeurs devront revoir leur code et changer tous les endroits où ils créaient un cube avant s'ils veulent utiliser la nouvelle API.C'est quelque chose que les bonnes APIs refusent de faire de manière générale sauf en passant une version majeure où ils se permettent de casser plein de choses. C'est un choix accepté, en particulier dans le logiciel Libre où ce serait très dur de suivre les évolutions de toutes les librairies et on essaie de se fier aux numéros de version.
Cela confirme assez. Il dit bien que c'est mieux géré (donc plus simple à utiliser ou mettre en œuvre), pas que c'est plus efficace.
Maintenant quand il parle de nouvelles fonctionnalités, cela implique surtout que l'API Direct3D a intégré des facilités dans son interface. Supposons qu'aucune des API ne savait faire des boules. Puis notre bonne API se dit: tiens, je vais intégrer un algorithme pour faire une boule et j'encapsule ça dans une fonction que j'appelerai
ball(r). On peut maintenant faire des boules en une ligne de code. De son côté la mauvaise API n'a pas la fonction encore. Cela ne signifie pas que les développeurs ne peuvent pas faire de boule. Simplement ils sont obligés de calculer eux même ses limites, puis les remplir (avec d'autres types d'objets que l'API sait faire). C'est donc chiant. C'est en gros, ce qu'ils disent dans l'article là:Enfin tout cela est confirmé par:
où Carmack explique que maintenant ils utilisent OpenGL et que s'ils passaient à DirectX ça ferait beaucoup de boulot (même si ce dernier est visiblement plus facile à utiliser, leur base de code depuis les années doit être énorme), pour au final peu de bénéfice. Les bénéfices évidents avec une meilleure API: plus facile à maintenir (débugguer, etc.). Mais comme ils ont déjà une base très solide, ils n'y touchent sûrement plus autant qu'avant. Donc ce bénéfice est au final minime comparé au travail colossal de tout changer pour Direct3D. Quant à l'utilisateur final, il n'y verra probablement aucune différence car les deux APIs sont aussi performantes ou proches à mon avis. En effet si cela impliquait vraiment une différence pour l'utilisateur (plus fluide et/ou plus beau), alors ce serait vraiment un énorme bénéfice, surtout pour le domaine du shoot 3d, fer de lance de cette entreprise où le graphisme règne en maître. Si ça ne l'est pas, c'est que la seule différence est probablement pour le développement.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Meilleure interface de développement, pas forcément meilleure 3D
Posté par Shuba . Évalué à 2.
Désolé mais tu ne peux pas affirmer que l'on peut contourner l'absence d'un certain type de shader. Les shader représentent la capacité de progerammer certaines parties du pipeline de la carte graphique, et si tu n'en disposes pas, la seule chose que tu puisses faire pour les remplacer, c'est coder leur effet sur le CPU, ce qui va vraiment impacter tes performances. En l'occurence là, les geometry shaders permettent de re-tesseler un mesh à la volée, ie d'augmenter de façon contrôlée et performante le niveau de détails. Sans ça tu es obligé de stocker/charger/envoyer à la CG des meshs bien plus gros (et vu qu'un des bottlenecks typique c'est le transfert de données entre la mémoirex hoost et celle de la CG, bah tu perds vraiment en perfs pour la même qualité visuelle.
Et quand on parle de pouvoir implémenter quelquechose via les extensions, généralement ça veut dire que ça va pas passer dans toutes les cartes graphiques. Alors c'est très cool si tu développes en interne, parce que tu sais exactement quelles extensions tu peux utiliser, mais pour distribuer, bah tu peux pas te rendre incompatible avec une trop grande partie du marché.
[^] # Re: Meilleure interface de développement, pas forcément meilleure 3D
Posté par windu.2b . Évalué à 10.
Pourquoi ne pas tout simplement proposer, dans une nouvelle version de l'API, la fonction
cube(l), qui se contenterait d'appeler la fonctionmake_a_regular_hexahedron(d), après avoir calculé la diagonale ? On a ainsi une compatibilité avec l'existant (qui continuera d'utilisermake_a_regular_hexahedron(d)) tout en proposant une meilleure API.[^] # Re: Meilleure interface de développement, pas forcément meilleure 3D
Posté par Victor . Évalué à 3.
Oui dans ce cas là ça marche, mais dans d'autres cas, l'API est plus complexe et utilise un ensemble de fonction et de structures de données qui sont peut-être utiles en interne.
Et donc maintenir l'ancienne API ferait beaucoup de boulot et de conversion vers la nouvelle structure interne.
Ou un truc comme ça... :)
[^] # Re: Meilleure interface de développement, pas forcément meilleure 3D
Posté par Jehan (site web personnel, Mastodon) . Évalué à 4.
Oui tout à fait. Mon exemple était simpliste à l'extrême pour être le plus explicite possible.
En fait, windu2b, ce que tu proposes est souvent fait entre versions mineures. Dans ce genre de cas, les développeurs vont définir une nouvelle fonction avec une meilleure interface et vont flagguer l'ancienne comme "dépréciée", ce qui (si le langage le permet) va en général générer des warnings à la compilation sans pour autant provoquer de vraie erreur.
Mais parfois c'est plus compliqué. Comme kaouete le dit, il peut y avoir des problèmes de "structures internes". De manière générale, les problèmes compliqués concernent l'architecture globale de l'API qui est trop complexe. Quand on s'en aperçoit après coup, cela implique que le problème n'est pas juste de changer une ou deux fonctions, mais qu'il faudrait changer l'API complète plus en profondeur (plus ou moins). C'est donc compliqué quand le problème vient des choix de "design" originel. Parfois vous ne pouvez même pas imaginer les choix étranges d'architectures de certaines librairies/programmes! Pour OpenGL en particulier, je ne sais pas, ceci dit.
Ensuite on peut presque toujours faire des fonctions qui appellent d'autres (encapsulation) pour avoir une interface plus agréable. On appelle cela une "abstraction" (on prend quelque chose de concret, par exemple "allumer un pixel à l'écran" pour en faire un concept plus abstrait comme "dessiner un point", donc plus facile à appréhender par l'esprit humain). Mais parfois on veut se limiter pour des raisons de performances. En effet à chaque fois qu'on appelle une fonction, l'ordinateur va la chercher dans la mémoire. Ensuite quand la fonction finit, on doit rechercher la fonction appelante et lui donner la réponse. Tous ces "allers et retours" en mémoire prennent du temps. On appelle cela l'overhead. C'est particulièrement important pour les APIs de bas niveau qu'on veut les plus optimisées possibles (en général on se "relâche" en montant les niveaux, ce qui se voit par le fait que les API bas niveaux sont souvent très concrêtes mais très optimisées alors que le haut niveau est très abstrait avec beaucoup d'overhead). Donc si on se met à faire massivement ce genre de choses, c'est probablement comme on disait qu'il y a un problème dans l'architecture et que c'est à ce niveau qu'il faudrait revoir l'API.
Enfin pour répondre à Shuba plus haut. C'est vrai que comme OpenGL/DirectX sont fait pour s'interfacer avec du matériel, j'imagine que certaines choses seront limitées si l'API (donc le matériel) ne définit pas certaines fonctionalités. Ensuite en ce qui concerne les shaders, l'article cite le fait que malgré qu'il n'y avait pas ça dans OpenGL à une époque, cela avait ajouté par extension avant que ce soit dans l'API. En outre, ça ne semble pas gêner Carmack plus que cela, et il ne parle pas de différence de performance. Donc cet exemple me semblait pertinent. Ensuite comme je disais, je ne connais pas le sujet de la 3D en particulier. Et tu as sans doute raison.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Meilleure interface de développement, pas forcément meilleure 3D
Posté par Ph Husson (site web personnel) . Évalué à 6.
Et merde, je vais me contredire (cf poste plus haut), mais si on parle effectivement d'API, il est évident que Direct3D et OpenGL ont des objectifs différents (bon euh ok, MS/Khronos.).
Le plus simple pour s'en convaincre est de voir le passage d'OpenGL ES 1 à OpenGL ES 2 qui doit être l'un des changements les plus raide en une release majeure (cf http://wiki.maemo.org/Image:Opengl.svg )
OpenGL ES 1 était à 100% en dur, ie pas de shader, ie le gpu pas programmable, mais avec des primitives très haut niveau genre faire un polyèdre OpenGL ES 2 vire tout ça, et passe au 100% programmable, tout se fait uniquement par shader, on a plus de fonctions ne serait-ce que pour faire de carré ! (je caricature peut être un peu, je connais quand même très mal ce monde :D) Il me semble qu'avec ça (et d'ailleurs OpenGL 4 suit la même direction à ma connaissance, mais garde quand même une certaine rétrocompatibilité), c'est un changement total de politique, où l'OpenGL devient un truc de très bas niveau, qui est inutilisable en soit, mais qui a besoin d'un toolkit. Est-ce un inconvénient ? Franchement aucune idée, en attendant, Martin Grässlin (mainteneur (ou codeur très actif ?) de kwin), a décidé de recoder ce morceau de kwin avec OpenGL ES plutôt qu'OpenGL, alors qu'il n'a aucune vocation à partir sur de l'embarqué ! (moi ça m'arrange après, mais c'est une autre histoire.) Juste qu'il trouve ça plus propre, et maintenant il a un magnifique (ok en vrai j'en ai aucune idée) toolkit, pour lequel aucune notion d'OpenGL n'est nécessaire pour pouvoir coder de nouveaux objets !
Ainsi, paradoxalement (par rapport à leur degré d'ouverture), Direct3D a l'air de plutôt viser les petites productions, alors qu'OpenGL les grosses qui ont les moyens de se refaire un toolkit. Bon je dis "grosses", mais si un gus seul dans son garage pour kwin a réussi à faire quelque chose, c'est peut être pas si compliqué que ça en fait.
[^] # Re: Meilleure interface de développement, pas forcément meilleure 3D
Posté par drakmaniso . É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.
[^] # Re: Meilleure interface de développement, pas forcément meilleure 3D
Posté par psychoslave__ (site web personnel) . Évalué à 2.
Bah l'innovation c'est une part importante sans doute, mais ça fait pas tout.
Déjà tu as la question de la portabilité.
Après on peut lancé des plans sur la comète, vu la tendance tout web, WebGL est un solide argument en faveur d'OpenGL.
[^] # Re: Meilleure interface de développement, pas forcément meilleure 3D
Posté par Prae . Évalué à 2.
J'allais créer un autre thread pour répondre à PBPG, mais finalement, je vais compléter ton commentaire.
Ce que tu évoques est exact.
Pour avoir suivi les guégères OpenGL/Direct3D, et notamment l'opinion de Carmack sur ce sujet, PBPG a vu ce qu'il a voulu voir.
En gros, Carmack dit que Direct3D est mieux, mais par rapport à ses propres sous-versions. Déjà à l'époque, il évoquait le fait que les premières versions de Direct3D était une vraie merde. Mais que depuis le 9, il a trouvé que Microsoft avait fait beaucoup de progrès.
Pour d'autres programmeurs, la différence entre OpenGL et Direct3D est ce que tu évoques: OpenGL se sont des primitives, Direct3D ce sont des primitives+des fonctions à la con pour tout faire. Bosser en Direct3D, c'est simple et rapide, mais les perfs s'en ressentent (sauf si tu bosses que sur les primitives), bosser avec OpenGL c'est la galère mais gage de rapidité.
Concernant les shaders & co, Carmack a raison (et PBPG aussi): Microsoft a fait comme Mozilla dans le domaine de la 3D: il a poussé au cul OpenGL qui se faisait vieillissant, c'est pas pour rien que ce dernier a pas mal bougé ces dernières années.
Direct3D et OpenGL, c'est bien d'avoir de la compétitivité dans ce domaine. (et ca risque d'être drôle avec l'arrivé de webGL ...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.