Étant donné que Microsoft est généralement un biais de Direct3D, une scène utilisant VBO in Direct3D sera-t-elle plus rapide que la même scène utilisant VBO à OpenGL, ou serait-ce la même chose depuis qu'il dépasse le pilote de la carte graphique? Merci
9 Réponses :
Ce serait généralement à peu près la même chose. Il y avait un temps que DirectX avait un avantage de vitesse distinct sur OpenGL, mais à des fins les plus pratiques, c'est une histoire ancienne.
> Le fait qu'il n'y ait pas eu de rendu de logiciel Fast OpenGL était plus un artefact de l'histoire que de la conception de l'API, même si nous avons des graphiques de jeu, les gens pensaient que c'était fondamentalement brisé, car il ne correspondait pas à nos notions de la manière dont les graphiques 3D devraient fonctionner . SGI a finalement publié un logiciel compétitif OpenGL Juste pour lutter contre le FU sortant de Redmond. chrishecker.com/opengl
Voir certaines questions connexes -
OpenGL encore mieux que Direct3D pour les non-jeux?
OpenGL ou Direct3D pour un Nouveau projet de jeu Windows? Ou quelque chose d'autre?
Microsoft est actuellement extrêmement biaisé vers Direct3D. De nombreuses cartes intégrées Intel bas de gamme ne sont pas expédiées avec des pilotes OpenGL par défaut ou si elles ne prennent en charge que les anciennes versions / spécifications de OpenGL comme 1.2 / 1.4. Si vous ciblez de telles machines (Intel dispose d'une part de marché graphique de 50%), il sera difficile de tirer parti des fonctionnalités les plus avancées telles que Shaders (qui est devenue disponible dans OpenGL 1.5). ATTENDU QUE, vous serez en mesure d'utiliser des shaders similaires dans Direct3D, en raison de la disponibilité de meilleurs pilotes pour ces cartes bas de gamme. Bien sûr, avec Direct3D ne fonctionne que sur Windows.
Si d'autre part, vous n'avez pas vraiment besoin d'utiliser des shaders, vous pouvez utiliser avec Direct3D ou OpenGL. Bien que je fasse tendance un peu plus à OpenGL. C'est une plate-forme croisée et tout le monde le supporte à part Microsoft. Certaines choses, telles que les lignes de dessin (de différentes largeurs) sont également beaucoup plus faciles à OpenGL. OpenGL a également un mode de cueille intégré qui est bien plus robuste que la cueillette de rayons (surtout si vous souhaitez choisir des points et des lignes).
Une troisième option consiste à utiliser une API abstraite ou un moteur existant pouvant rendre à la fois à OpenGL et à Direct3D.
Ne pas descendre, mais ce que les shaders avancés peuvent être écrits en D3D qui ne peuvent pas être écrits avec OGL? S'il vous plaît nommez un seul.
Désolé, je ne voulais pas dire qu'il ne peut pas être écrit dans OpenGL. Ce que je voulais dire, c'est que les pilotes par défaut que Microsoft Ships pour les cartes Intel ne prennent en charge que jusqu'à OpenGL 1.2 / 1.4, de sorte que vous ne pouvez pas utiliser les shaders avancés, bien qu'ils soient disponibles et que vous soyez pris en charge par la carte en utilisant les derniers pilotes.
@TATHAGATA: Votre réponse suggère très fortement que OpenGL n'est pas capable de "Shaders avancés". Il est tout à fait est capable de «avancé» et la plupart des fonctionnalités de shader apparaissent dans des extensions OpenGL, bien avant leur apparition à DirectX. Même le HLSL de DirectX a été dérivé de l'une des langues de shader utilisés dans OpenGL. (Que je pense était la CG de Nvidia, mais je pourrais me tromper.)
CG est une langue de shader «multi-plate-forme», qui compile les shaders D3D / GL. HLSL est entré avec DX9, il est très similaire à cg mais je ne sais pas qui venait d'abord.
Gardez à l'esprit que le GPU Intel qui ne fournit pas de pilotes OpenGL adéquats, vous ne pouvez pas vraiment exécuter directX efficacement.
@John: CG est venu en premier. Je sais que cela a été utilisé comme base pour le HLSL de Microsoft, et je pense que cela influencit également GLSL. Avant cela, GL a fourni des extensions à des programmes de shader plus bas niveau.
Vous pouvez l'essayer pour vous-même si vous le souhaitez. OGRE3D est une excellente bibliothèque 3D où, lorsque vous démarrez, vous pouvez choisir si vous souhaitez utiliser DirectX ou OpenGL. . Si je me souviens bien (c'était 3-4 ans que je l'ai utilisé), ils avaient un taux de trame et d'autres données même
En réalité, cela dépend vraiment du type de projet que vous faites.
Si vous souhaitez le porter sur une plate-forme différente - N'utilisez pas DirectX. Si vous souhaitez un contrôle total et une bibliothèque de développement rapide sur Windows, DirectX est la voie à suivre. Si vous trouvez un moteur graphique avec toutes les fonctionnalités dont vous avez besoin - utilisez-le. Il est plus facile que d'utiliser le bricolage DX ou OpenGL, surtout s'il prend en charge une chaîne d'outils (éditeur de niveau, importation de modèles à partir de modélisateurs 3D, ...).
Si vous voulez apprendre DX, optez pour DX ou SLIMDX. Si vous voulez apprendre OpenGL, allez pour OpenGL.
Soyez averti que GL Pilotes sur Windows sont généralement assez faciles et buggy. Les OEM font généralement très peu de travail avec GL Driver sous Windows. Juste assez pour que le dernier jeu d'identification fonctionne bien. Qui est une douleur si vous faites les choses différemment.
Ce que vous devriez faire est d'écrire une couche d'abstratrait entre les 2 et appliquer les deux extrémités arrière. Cela vous donne le meilleur des deux mondes. La stabilité de DirectX sous Windows et la plate-forme cross-ness de OpenGL. Cela vous donne également un avantage énorme d'être capable d'ajouter une nouvelle extrémité arrière de rendu si vous le souhaitez.
Il convient également de noter que X-Box et DirectX sont suffisamment différents pour signifier que vous auriez besoin d'une fin séparée pour les deux plates-formes que vous essayiez de toute façon une telle chose.
Personnellement, mon moteur prend en charge DX9, DX10, Open GL3, OpenGL ES2.1 et je suis beaucoup plus heureux d'avoir la couche d'abstraction :)
EDIT: selon les commentaires, je soulignerais que les pilotes NVIDIA sont les pilotes de Windows Opengl les moins flocons. À peu près, tous les autres fabricants ont des problèmes. Même Nvidia a beaucoup de problèmes. Beaucoup de temps, dans mon expérience, vous finissez par lutter contre un chauffeur où les choses "travaillent" "(TM) avec DirectX.
Je ne sais pas où vient votre notion de pilotes GL Buggy. Dans mon expérience, ils ne sont ni meilleurs ni pires que les pilotes Linux - du moins pour Nvidia, la majorité du code est la même chose de toute façon.
@eil, je pense que GoZ signifie comparé aux pilotes Windows / DirectX. Les chipsets particulièrement intel, ils revendiquent OpenGL2.1 mais celui de mon ordinateur portable ne peut même pas tirer correctement des lignes simples.
Utilisez le middleware. Ogre est bon si vous voulez quelque chose avec beaucoup de fonctionnalités (chargement de modèles 3D et d'animations, etc.). SDL est bon si vous voulez juste un wrapper simple.
En réponse à votre question actuelle, cela revient totalement aux pilotes. Et cela varie entre les fabricants. Ma compréhension est que, à l'heure actuelle, GL n'est pas bien soutenu par toutes les entreprises principales (Nvidia, ATI, Intel), qui est un gros problème.
Personnellement, j'utiliserais middleware, mais appuyer sur les tests / développer principalement pour D3D.
Je choisirais DirectX. Cela améliore et évolue rapidement, beaucoup plus rapidement que le comité OGL peut bouger. Extension de l'enfer quelqu'un?
Pour être juste, l'évolution de OpenGL a remporté beaucoup au cours des 2 dernières années environ. Ils sont beaucoup plus compétitifs aujourd'hui qu'avec probablement la dernière décennie.
@Jalf: ont-ils décidé pour la déception amère de la version 3.0?
performance-sage et supposant des pilotes GPU décents, il n'y a pas de différence globale.
Certaines opérations sont intrinsèquement plus rapides dans OpenGL qu'à DirectX9, bien que DX10 ait corrigé cela.
Mais une bonne règle de base lorsque vous travaillez avec du matériel externe, c'est que ce n'est pas l'API que vous utilisez qui détermine les performances .
Lors de la rédaction de code réseau, le goulot d'étranglement est l'adaptateur réseau, et peu importe si votre code de socket est écrit dans .NET, des prises unies Berkeley en C, ou peut-être utiliser une bibliothèque Python.
Lorsque vous écrivez le code pour utiliser le GPU, le GPU est le facteur limitant. La plus grande différence entre DirectX et OpenGL est que l'on pourrait nécessiter un appel de fonction ou deux de plus que l'autre pour atteindre certaines tâches - et le coût de performance de cela est à peu près inexistant. Ce qui se passe sur le GPU est le même dans les deux cas, car cela est déterminé par votre pilote GPU, et parce que OpenGL et DirectX tentent d'être aussi efficaces que possible.
Il existe des raisons valables de préférer l'API cependant.
DirectX a beaucoup mieux assistance à outils. Microsoft fait un très bon travail. Le débogage et l'optimisation du code DirectX sont beaucoup plus faciles avec des outils tels que PIX. Et Microsoft fournit également la bibliothèque d'assistrations D3DX qui fournit des implémentations efficaces de nombreuses fonctionnalités couramment utilisées.
OpenGL a l'avantage de ne pas lier à un système d'exploitation spécifique. DirectX9 ne fonctionne que sur Windows. DX10 et ci-dessus ne fonctionne que sur Vista et plus.
OpenGL fonctionne sur n'importe quel système d'exploitation où un pilote OpenGL a été écrit.
sur Windows, la situation est parfois un peu maladroite cependant. Windows elle-même ne dispose que d'anciens implémentations de OpenGL. (XP avec V1.1, je crois et Vista / 7 avec 1,5).
SO OpenGL Apps applications sur Windows s'appuie sur le fournisseur GPU pour fournir une mise en œuvre mise à jour avec leurs pilotes. ATI et Nvidia fournissent de très bonnes implémentations, donc ce n'est pas si un problème. Les pilotes OpenGL d'Intel sont généralement en retard, à la fois en qualité et dans des caractéristiques prises en charge.
Merci pour cela. La comparaison la plus utile du genre que j'ai lu ainsi à ce jour.
J'utilisais OpenGL, mais pour l'instant, je suis intéressé à explorer le monde de DirectX. La cause est la libération de DX11 qui termine la longue guerre prolongée sous Windows.
Le groupe Khronos a bientôt libéré OpenGL 4 pour se battre; Malheureusement, OGL4 a toujours une demi-quantité de nouvelles fonctionnalités manquantes ou retardées derrière; et certains d'entre eux sont essentiels pour créer un cadre 3D flexible.
Quelque chose à penser: OpenGL 3.3 / 3.2 vous permet d'utiliser la géométrie Shaders sur WinXP. DirectX ne le fait pas, car les shaders de géométrie ne sont supportés que sur DX10 / 11, qui est Vista ou Windows7. "Et certains d'entre eux sont essentiels pour créer un cadre 3D flexible." Je ne suis pas d'accord avec cette partie. La capacité de créer un cadre flexible est une question de compétence de programmation uniquement. L'API n'a pas d'importance, bon programmeur devrait pouvoir créer un cadre flexible indépendamment de l'API. Jetez un coup d'œil à la "lame d'obscurité" - ils ont créé des ombres, des mutilations et une eau relativement bonne sur le matériel DX7 ...
Yap, alors pourquoi ne peuvent-ils pas atteindre un rendu de haute qualité comme sur la CPU? Seules des raisons de performance? Certainement pas. Ils ont créé un cadre de moteur de jeu flexible et non un cadre de rendu général des objectifs. Vous ne pouvez pas voir que RT Ray-Traçage ne devient possible que lorsque la programmation GPGPU avance? Je ne discute pas que vous pouvez vous adapter à différentes plates-formes, mais la capacité de rendu. Ceci est double: 1.Biabilité de permettre à divers algorithmes; 2.Good ingénierie. (Certaines structures de codage s'appuient fortement sur des caractéristiques spécifiques matérielles. Théoriquement, vous pouvez impliquer n'importe quoi en utilisant des codes infinis, mais pas impraticable)