IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Développement 2D, 3D et Jeux Discussion :

Un développeur donne son point de vue sur la conception d'OpenGL


Sujet :

Développement 2D, 3D et Jeux

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Responsable 2D/3D/Jeux


    Avatar de LittleWhite
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mai 2008
    Messages
    27 157
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Mai 2008
    Messages : 27 157
    Billets dans le blog
    152
    Par défaut Un développeur donne son point de vue sur la conception d'OpenGL
    Un développeur donne son point de vue sur la conception d'OpenGL
    Et explique pourquoi OpenGL est en retard par rapport à DirectX 12 ou Mantle

    Rich Geldreich, développeur chez Valve écrit sur un blog ses opinions personnelles (donc, à ne pas lier avec Valve) sur OpenGL. Son opinion est intéressante, notamment car Rich a été développeur sur le premier moteur utilisant la technique de rendu différé (pour Shrek, sur Xbox), ensuite il a aussi créé une bibliothèque de compression avancée pour le DXTc, pour Ensemble Studios et travaille maintenant chez Valve, notamment sur le portage et l'optimisation des jeux Portal 2 et DoTA 2 sur Linux). Il est aussi un des développeurs de vogl, un nouveau débogueur/profileur OpenGL multiplateforme.


    Dans son blog, il donne son point de vue sur la conception d'OpenGL et y explique pourquoi la bibliothèque est en retard par rapport aux récentes solutions proposées par les concurrents (DirectX 12 et Mantle). Même si certains de ces points peuvent être mineurs et négligeables, cela décourage bien souvent les développeurs voulant s'intégrer dans l'écosystème OpenGL.


    20 ans d'héritage, OpenGL nécessite une refonte

    Il faut qu'OpenGL suive le concept KISS (Keep It Simple, Stupid). En cas de doute, on doit se débarrasser de tel ou tel élément. La bibliothèque doit être extrêmement simplifiée, notamment en enlevant le mode de compatibilité. DirectX 12 et Mantle vont être très agressifs du point de vue de la performance alors que le système de contexte global et le modèle basé sur les liaisons sont pourris. Une bibliothèque reposant sur un accès à l'état direct (Direct State Access) devrait être maintenant un standard.
    La plupart des développeurs vont préférer une transition douce en portant leur code de rendu PS4/Xbox One vers DirectX 12 et/ou Mantle. Ils ne vont pas réécrire leur pipeline de rendu en entier pour utiliser un regroupement super agressif des ordres de rendu et autres techniques avancées comme la communauté OpenGL le conseille depuis quelques temps afin d'améliorer les performances. Mais à cause de cela, OpenGL sera toujours considéré comme une solution de seconde zone et aucun portage ne sera fait tant qu'il n'y aura pas de modernisation et simplification de la bibliothèque.


    La création de contexte OpenGL est un enfer

    La création d'un contexte OpenGL moderne est une source d'erreur inimaginable. Le processus est même dépendant de la plateforme et Rich recommande aux développeurs de ne jamais utiliser des bibliothèque GLX/WGL/... mais plutôt des bibliothèques de plus haut niveau comme SDL ou GLFW (et un truc comme GLEW pour récupérer les pointeurs de fonctions et autres extensions).
    Le principe de devoir utiliser des bibliothèques tierces est nul. La bibliothèque devrait être simplifiée et normalisée afin que l'utilisation d'une bibliothèque tierce ne soit plus une nécessité lors de la création d'un contexte.


    Le thread du contexte courant pourrait être un pointeur "this" implicite

    Les fonctions retournées par GetProcAddress() ne peuvent (ou ne devraient, suivant la plateforme) pas être utilisées globalement car elles peuvent être fortement liées au contexte (en langage OpenGL : dépendante ou indépendante du contexte). En d'autres mots, l'appel à la fonction GetProcAddress() sur un contexte et l'utilisation du pointeur retourné dans un autre contexte est mauvais et provoquera des crashs.


    Déficience de glGet()

    Ceci est peut-être fortement lié au tracing des appels OpenGL mais cela impacte indirectement les développeurs car les outils sont inefficaces ou inexistants.
    La série de fonction glGet* (glGetIntergerv, glGetTexImage...) ne possède pas de paramètre "taille_maximale", donc il est possible pour le pilote d'écraser les données des tampons suivant les paramètres ou l'état du contexte global. Avec un paramètre de taille, la fonction pourrait retourner une erreur si la taille maximale est trop petite et non provoquer un écrasement de mémoire.
    Le calcul de la taille du tampon de texture lu ou écrit par le pilote dépend de plusieurs état du contexte global, ce qui est mauvais.
    Il y a une centaine d'énumérations acceptées par la fonction glGet() et certaines ne sont acceptées que par des pilotes spécifiques. Si vous écrivez un débogueur ou un traceur, il n'y a aucune méthode officielle pour déterminer comment les valeurs seront gérées par le pilote.


    glGetError

    Il n'y a pas de glSetLastError() comme dans la bibliothèque Win32, rendant le tracing d'application difficile. Certaines applications n'appellent jamais glGetError(), d'autres une fois par image, d'autres seulement lors de la création des ressources. Certaines l'appelle des centaines de fois à l'initialisation et plus jamais par la suite. Rich a vu des applications dans le commerce ayant des erreurs OpenGL à chaque image (est-ce que les développeurs le savent ?).


    Impossibilité de faire des requêtes sur des éléments clés

    Comme il n'est pas possible de faire des requêtes sur des éléments tels que les cibles de texture, le débogage d'application est encore plus difficile, notamment dans les cas de rendu d'ombre. Tous les états devraient pouvoir être accessibles.


    Les bibliothèques en accès directs aux états ne sont pas un standard et pas toujours correctement supportés

    L'accès direct aux états permettra une grande différence dans le surcoût des appels des fonctions OpenGL.


    La spécification n'est toujours pas complète en 2014

    La spécification XML ne possède pas d'information de types pour les paramètres. Par exemple :
    Code xml : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    <command>
        <proto>void <name>glBindVertexArray</name></proto>
        <param><ptype>GLuint</ptype> <name>array</name></param>
        <glx type="render" opcode="350"/>
      </command>
    Seule glapi.py est la source d'information la plus complète à ce jour :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    GlFunction(Void, "glBindVertexArray", [(GLarray, "array")]),

    Pas d'outils standard/officiel pour OpenGL

    Il y a besoin de :
    • outil d'aide pour la conversion de texture et de pixel qui ne repose pas sur le pilote ou un contexte OpenGL ;
    • équivalent de DXTEX pour le format KTX (équivalent du DDS), qui fonctionne avec tous les fichiers ;
    • outil de conversion d'image vers KTX ;
    • une bibliothèque pour compiler les shaders.



    Extensions décrient comme des diff par rapport à la spécification

    Pour comprendre la documentation des extensions, il faut connaître parfaitement la spécification.


    Horreur de MakeCurrent()

    La fonction peut être extrêmement coûteuse, tout en ayant des coûts supplémentaires avec certaines extensions (NB_bindless_texturing), peut provoquer des crashs si elle est appelée entre des blocs glBegin()/glEnd(). Le comportement de cette fonction devrait mieux être expliqué aux développeurs.


    Les pilotes ne devraient pas crasher le GPU, ni le CPU, ni même freezer lors des comportements indéterminés de la bibliothèque

    Soit les pilotes devraient mieux être testés, soit la bibliothèque doit être restructurée pour éliminer les comportements indéfinis.
    Le pilote freeze en cas de trop nombreux appels à glBufferSubData(). Le pilote peut caler tout le pipeline pendant vos opérations de rendu et rien ne vous indique la raison. Les requêtes peuvent aussi provoquer ce comportement.


    Destruction des objets

    Bonne chance si l'objet en cours de destruction est lié à un autre contexte.
    L'appel de glGet() sur un objet partiellement détruit (encore existant car lié dans un autre contexte) provoque des comportements qui diffèrent entre les pilotes.


    Compilation et édition des liens des shaders

    Il y a de nombreux problèmes de performances liés à la compilation des shaders. Le système utilisé dans Direct3D fonctionne. En plus, OpenGL n'accepte que des shaders en texte. Les temps de compilation entre les pilotes sont très variables et certains utilisent des techniques d'optimisation alors que d'autres ne le font pas (compilation en parallèle, système de cache).


    Multithreading

    Certains développeurs ont décidé d'activer leur pilote multithread alors que ceux-ci sont bogués et cela, plusieurs mois après les tests des développeurs de jeux. Même les glGet() peuvent être bogués lorsque le parallélisme est activé. Il n'y a aucune méthode pour savoir si le pilote est multithreadé ou non.


    Votre opinion

    Que pensez-vous de tous les défauts rapportés par Rich Geldreich ? Sont-ils légitimes ?
    Trouvez-vous que DirectX propose une meilleure bibliothèque, exempt de défauts ?
    Utilisez-vous OpenGL directement, ou préférez-vous l'utilisation d'un moteur ? Lequel et pourquoi ?


    Voir aussi

    La vérité sur la qualité des pilotes graphiques OpenGL
    Les développeurs de Dolphin dressent un tableau de la qualité du support d'OpenGL
    Conférence de Rich Geldreich aux Steam Dev Days
    Game Connection 2013 - Europe : Techniques OpenGL ES avancées dans la série des GTA


    Source

    Blog de Rich Geldreich
    Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  2. #2
    Membre éprouvé Avatar de marsupial
    Homme Profil pro
    Retraité
    Inscrit en
    Mars 2014
    Messages
    1 870
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Mars 2014
    Messages : 1 870
    Par défaut
    Que pensez-vous de tous les défauts rapportés par Rich Geldreich ? Sont t-ils légitimes ?

    L'expérience de DirectX donne une grande avance sur OpenGL mais est en même temps légitimée par sa spécialisation et l'ouverture exclusive du matériel.
    Lequel matériel donne en contrepartie des pilotes graphiques de 100+Mo ultra compressé. ( Le kernel linux pèse 75% faiblement compressé )


    Trouvez-vous que DirectX propose une meilleure bibliothèque, exempt de défauts ?

    Du fait de son poids, il est plus réactif. Imaginons un microscope électronique( "nanoscope"), en exagérant, avec DirectX, l'OS plus le pilote prendra la taille d'un cluster tel celui du CERN.
    Un cluster dans un lanceur, ça pèse son poids à faire décoller pour un télescope qui dispose de lentilles de plusieurs tonnes.


    Utilisez-vous OpenGL directement, ou préférez-vous l'utilisation d'un moteur ? Lequel et pourquoi ?
    Ni l'un ni l'autre, je laisse à un spécialiste du domaine se prononcer.
    Par contre, un "best of both worlds" serait du meilleur aloi.

  3. #3
    Membre très actif
    Homme Profil pro
    Étudiant
    Inscrit en
    Mars 2014
    Messages
    183
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 25
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Mars 2014
    Messages : 183
    Par défaut
    je ne suis pas un spécialiste d'OpenGL donc j'ai lu que les titres mais les défauts cités m'ont l'air plutôt légitimes
    je ne connais pas directX mais d'après ce que j'ai entendu il marche que sur windows donc si c'est le cas c'est pas terrible
    j'essaye de développer directement a partir d'OpenGL et Qt mais en un mois je n'ai toujours pas réussis a faire une fenêtre qui peut afficher une forme (j'essaye d'utiliser opengl 3.0 mais c'est galère avec Qt)
    donc oui je pense qu'OpenGL nécessite une refonte et qu'elle permette de créer des fenêtres avec un contexte directement sans que les développeurs aient besoin de manipes compliquées avec Qt, la SDL...

  4. #4
    Candidat au Club
    Femme Profil pro
    1
    Inscrit en
    Avril 2014
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Afghanistan

    Informations professionnelles :
    Activité : 1

    Informations forums :
    Inscription : Avril 2014
    Messages : 4
    Par défaut Rich Geldreich se ridiculise lui même en racontant de la merde
    - la doc opengl est complète RTFM. Je pense que Rich a eu un problème avec son navigateur. ex:
    http://www.opengl.org/sdk/docs/man3/...ertexArray.xml
    chez moi toute la doc s'affiche correctement.

    - dans la section "Horreur de MakeCurrent()" : il est cité l'utilisation de blocs glBegin()/glEnd() (utilisé pour définir les sommets un par un coté CPU). Ici ça montre que Rich parle de l'ancienne api : en mode compability qui est deprecated, donc c'est une vision totalement fausse de l'opengl d'aujourd'hui et c'est vraiment pas malin de ça part de vouloir détruire opengl. Dans l'api actuel, il faut créé un buffer object (buffer coté GPU), et upload les datas tous simplement avec un glBufferData(), puis lancer un vertex / fragment shader.

    - la création d'un context opengl n'est pas du tout un enfer. L'api laisse de la place au paramétrage, après il faut utilisé la bonne librairie pour la bonne abstraction. On a l'impression que Rich fait parti des personnes qui n'ont pas compris le rôle d'opengl, qui est d'être une api de rendu ! À la différence de directx qui fait vraiment partie de toute un framework proposé par microsoft (rendu, I/O, son, ... )

    - lorsqu'il parle de freeze, il utilise des drivers instable, donc ne l'écouté pas !

    - pas d'outils standard / officiel d'opengl. Il cite le manque d'outils pour convertir des fichiers : ça n'a absolument rien à voir avec opengl qui est une api de rendu : ces propos sont totalement hors sujet !

    - à un moment il parle des temps de compilation des shaders. Encore une fois ça n'a rien à voir avec une api. Une api sert juste à définir des spécifications. La compilation dépend de l'implémentation du compilateur, avec les drivers de nvidia, c'est le compilateur cg qui est utilisé.

    ---------
    Pour résumé, Rich n'a rien compris à ce qu'était opengl, et fait parti des personnes qui attendent que tout soit mi sur un plateau. J'utilise opengl es 2 (qui est sous-ensemble d'opengl 3), donc opengl avec les shaders. J'utilise opengl es 2 dans mes programmes écrit avec le framework Qt en C++, et mon code est multi-plateforme: sur les ordis, tablettes, smartphone. De plus avec le langage glsl (langage des shaders : vertex et fragment shader) le code est à la fois compatible dans une application riche (ordi, smartphone, ...) mais aussi dans les navigateurs web. À ma connaissance aucune autre api de rendu ne propose ça.

    Et en règle générale il faut se méfier de tout ce qui vient de chez Valve. Quand Valve dit qu'il est pour le libre, c'est n'importe quoi ! il n'y a qu'à voir la plateforme steam qui est la plus grosse plateforme de drm jamais créée !

  5. #5
    Membre très actif
    Homme Profil pro
    Étudiant
    Inscrit en
    Mars 2014
    Messages
    183
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 25
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Mars 2014
    Messages : 183
    Par défaut
    Citation Envoyé par cocolapin0 Voir le message
    - à un moment il parle des temps de compilation des shaders. Encore une fois ça n'a rien à voir avec une api. Une api sert juste à définir des spécifications. La compilation dépend de l'implémentation du compilateur, avec les drivers de nvidia, c'est le compilateur cg qui est utilisé.
    c'est pas OpenGL qui compile les shaders ?

  6. #6
    Responsable 2D/3D/Jeux


    Avatar de LittleWhite
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mai 2008
    Messages
    27 157
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Mai 2008
    Messages : 27 157
    Billets dans le blog
    152
    Par défaut
    OpenGL n'est qu'une bibliothèque ou plus précisément une spécification d'une bibliothèque. Chacun des constructeurs de cartes graphiques va réimplémenter (recoder les fonctions décrite dans la spécification) comme il le souhaite. Parmi l'une de ces fonctions, il y a glCompileShader() qui accepte une chaîne de caractère contenant le code source et qui le compile en un shader GPU. Le compilateur est implémenter par les constructeurs et cette implémentation (comme le reste de la bibliothèque) se trouve dans le pilote graphique.

    Donc, en soit, OpenGL ne fait rien. Ce n'est qu'une liste de fonctions que les gens doivent suivre pour supporter OpenGL.

    - dans la section "Horreur de MakeCurrent()" : il est cité l'utilisation de blocs glBegin()/glEnd() (utilisé pour définir les sommets un par un coté CPU). Ici ça montre que Rich parle de l'ancienne api : en mode compability qui est deprecated, donc c'est une vision totalement fausse de l'opengl d'aujourd'hui et c'est vraiment pas malin de ça part de vouloir détruire opengl. Dans l'api actuel, il faut créé un buffer object (buffer coté GPU), et upload les datas tous simplement avec un glBufferData(), puis lancer un vertex / fragment shader.
    Ouep, mais le pilote ne devrait pas crasher, même dans un tel cas, vous ne croyez pas ?

    - à un moment il parle des temps de compilation des shaders. Encore une fois ça n'a rien à voir avec une api. Une api sert juste à définir des spécifications. La compilation dépend de l'implémentation du compilateur, avec les drivers de nvidia, c'est le compilateur cg qui est utilisé.
    Oui, mais pourquoi ne pas permettre d'utiliser des shaders précompilés (à l'instar de DirectX) ? Cela est dit dans cette vidéo : http://jeux.developpez.com/videos/Op...r-jeux-OpenGL/
    Là, la spécification ne permet pas les shaders précompilés, du tout. Donc, oui, là, cela peut revenir à un soucis de bibliothèque et de sa spécification.

    - pas d'outils standard / officiel d'opengl. Il cite le manque d'outils pour convertir des fichiers : ça n'a absolument rien à voir avec opengl qui est une api de rendu : ces propos sont totalement hors sujet !
    Ici, vous avez une spécification, mais aucune implémentation de référence, aucun outil pour bosser avec les implémentations actuelles, ou les applications qui l'utilisent. Même si ce n'est pas un soucis de spécification à la base, il en reste que cela démotive les développeurs à l'utiliser, car dès qu'ils se plantent sur l'utilisation de la bibliothèque, ils ont rien pour trouver l'erreur.

    Pour OpenGL ES, l'avantage, c'est que la spécification est un sous ensemble de OpenGL, donc qui limite énormément les complexités d'implémentation et qui réduit les trucs inutiles (le pipeline fixe a été viré très tot, ainsi que les fonctions associés, dans cette spécification). Oui, vous aurez une application portable, mais vous n'aurez pas les dernières fonctionnalités de vos cartes graphiques OpenGL 4, avec une application en OpenGL ES 2. Vous vous êtes énormément limité en terme de rendu possible (même si, je ne doute pas que cela suffise à vos besoins ).
    Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  7. #7
    Membre émérite

    Profil pro
    Inscrit en
    Décembre 2013
    Messages
    403
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2013
    Messages : 403
    Par défaut
    (OpenGL permet d'utiliser les shader programs compilé, cf glGetProgramBinary/glProgramBinary. Quand au reste, j'ai l'impression que c'est le perpétuel débat "vieux quelque chose qui doit maintenir la rétrocompatibilité" vs "nouveaux truc qui peut repartir sur une API neuve" : C++ vs D, GL vs Mantle, etc. Bof)

  8. #8
    Responsable 2D/3D/Jeux


    Avatar de LittleWhite
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mai 2008
    Messages
    27 157
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Mai 2008
    Messages : 27 157
    Billets dans le blog
    152
    Par défaut
    Dans cette vidéo, si je me rappelle bien, ils disaient que certes, il y a cette extension, mais que chaque pilote produit son propre binaire et que ce binaire n'est compatible que pour la carte qui compile/la version du pilote en cours. Du coup, même en ayant le binaire, qui est une représentation trop dépendante de la machine/pilote, on ne s'en sort pas.
    Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  9. #9
    Invité
    Invité(e)
    Par défaut
    Personnellement il y a beaucoup de vrai dans ce qu'il dit et je n'ai jamais utilisé opengl directement, cette librairie est trop compliquée, je l'utilise en travers d'une librairie déjà existante qui encapsule le contexte opengl. (Car en effet pour la compatiblité entre palteforme c'est une vrai horreur. :/)

    Et pour certaines autres choses qui ont été dîtes aussi, je pense que opengl nécessite vraiment une refonte!

    Mais bon c'est une librairie de bas niveau donc..., je ne m'attendait pas à mieux, il faut souvent beaucoup d'abstraction si on veut faire de l'optimisation, du multipass-rendering et du code portable et l'opengl moderne avec les layouts nécessite d'en faire encore plus.

    D'ailleurs je n'utilise pas l'opengl moderne (à part les VBO qui sont très intéressante) pour la simple et bonne raison que ça ne fonctionne pas toujours avec tout les drivers et puis, ça complexifie grandement les choses, j'utilise encore les anciens glVertexPointer, glColorPointer, etc..., qui marche sans soucis avec les FBO sur tout les drivers, même ceux qui ne supporte pas le GLSL moderne. (Ainsi que les geometry shader ou encore l'instanced rendering)

    Mais bon il faudrait implémenter certaines choses dans le pipeline aussi. (et pas tout dans les shaders, selon moi les shaders doivent rester un moyen de faire de meilleurs effets mais ne doivent pas intervenir au niveau de la mécanique de base de opengl)
    Un alpha test plus précis qui nous permettrait de comparer l'alpha avec celui du pixel couramment dessiné à l'écran serait le bienvenu également plutôt que de devoir le faire obligatoirement sur une valeur de l'alpha. (Ca a été l'horreur pour moi de devoir faire ça avec des textures semi-transparentes qui se croisent)
    Dernière modification par Invité ; 04/06/2014 à 22h28.

  10. #10
    Membre émérite
    Homme Profil pro
    Développeur
    Inscrit en
    Juillet 2009
    Messages
    417
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Juillet 2009
    Messages : 417
    Par défaut
    - lorsqu'il parle de freeze, il utilise des drivers instable, donc ne l'écouté pas !
    Il ne faut pas oublier que beaucoup de drivers PC, notamment sur les chipsets Intel, implémentent OpenGL avec beaucoup de retard et pas mal de bugs. C'est pas très pro de reprocher à ses clients/utilisateurs finaux de choisir la mauvaise machine
    Dans OpenGLES, j'ai récemment été traumatisé par les drivers de chez QualComm (je l'ai détaillé sur un autre topic).

    Pour ce qui est de la création du contexte, je n'ai pas suivi les dernières évolutions d'OpenGL, mais dans OpenGLES, on a depuis longtemps EGL (qui est aussi spécifié par Khronos) qui permet de créer très facilement un contexte. Donc l'argument du mec de chez Valve est invalide dans ce cas.

    Par contre, si un jour je décide de faire une appli 3D sur PC, j'éviterais de vouloir à tout prix implémenter des fonctionnalités d'OpenGL 4 (à mon avis actuellement vaut mieux se limiter au 2.1, et encore. En tout cas faut au moins proposer un fallback vers cette version), et je pense que je proposerais à côté un renderer DirectX, histoire d'éviter les problèmes de compatibilité.

  11. #11
    Expert confirmé

    Avatar de dragonjoker59
    Homme Profil pro
    Software Developer
    Inscrit en
    Juin 2005
    Messages
    2 035
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Software Developer
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2005
    Messages : 2 035
    Billets dans le blog
    12
    Par défaut
    Moi je suis partisan de la refonte d'OpenGL, il y a beaucoup de code dont on ne se sert plus (ou en tout cas dont on ne devrait plus se servir), pour ne citer que les plus connus : mode direct, display lists...
    Cependant ils ne peuvent pas réellement le faire car OpenGL est encore fortement utilisé en milieu industriel, principal frein à ces évolutions, qui casseraient beaucoup d'applications.
    Donc je pense qu'ils ont choisi un excellent compromis avec le Core Profile. C'est celui que j'utilise depuis quelques années et je m'en porte bien.

    Je dois avouer que la logique objet de DirectX est confortable, ... mais c'est tout en fait. Au fur et à mesure que D3D avance, je trouve qu'il se rapproche de ce qui se fait en OpenGL, notamment au niveau shaders (exit Effect).

    Pour la création du contexte OpenGL, il décrit ça comme un enfer, mais pour avoir un contexte X11 et un contexte Windows, je ne vois pas l'enfer. Il est peut-être dommage d'avoir des variations dans la création, mais en même temps dès qu'on touche à de la GUI il est évident qu'il y aura des variations dans le lien entre OpenGL et la GUI. Et c'est la seule variation ! Le reste du code est identique entre Windows, GNU/Linux et Mac (et autres aussi, d'ailleurs). C'est un faible prix à payer je trouve.

    Pour le problème qu'il décrit avec GetProcAddress, c'est vrai que gDEBugger râle quand on récupère des fonctions qu'on utilise dans un autre contexte, mais je n'avais encore pas rencontré de problème par rapport à ça. (par contre je l'ai corrigé, sait-on jamais).

    glGetError est le meilleur ami d'un développeur OpenGL. Tout développeur OpenGL devrait le savoir, sinon ... Après il est vrai que la spécification est un peu légère sur le debug. Ca tend à se combler avec les extensions ARB_debug_output ou AMD_debug_output, mais il y a des lacunes au niveau des implémentations (surtout côté AMD même si là encore ça s'améliore).

    Pour les crash de pilote, ça ne m'est pas arrivé fréquemment, et ça m'est essentiellement arrivé sous GNU/Linux et j'avoue que ça me fait enrager aussi.
    Si vous ne trouvez plus rien, cherchez autre chose...

    Vous trouverez ici des tutoriels OpenGL moderne.
    Mon moteur 3D: Castor 3D, presque utilisable (venez participer, il y a de la place)!
    Un projet qui ne sert à rien, mais qu'il est joli (des fois) : ProceduralGenerator (Génération procédurale d'images, et post-processing).

  12. #12
    Membre Expert
    Avatar de shenron666
    Homme Profil pro
    avancé
    Inscrit en
    Avril 2005
    Messages
    2 582
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : avancé

    Informations forums :
    Inscription : Avril 2005
    Messages : 2 582
    Par défaut
    Premier constat, le traducteur a fait l'erreur de traduire D3DX en DirectX.
    Hors la source parle bien de Direct3D.

    A part ce point, une partie des remarques sont fausses ou inexactes depuis OpenGL 3, plus encore depuis OpenGL 4.
    D'autres sont liées à l'appréciation du développeur.
    Il ne faut pas oublier non plus un détail on ne peut plus important : OpenGL est multi-OS contrairement à Direct3D.

    D'autres remarques encore sont à adresser aux développeurs de pilotes (stabilité, compilateur de shader) voire de Microsoft en ce qui concerne les pilotes sous Windows car ce dernier a toujours fait de l'obscurantisme et mis des bâtons dans les roues d'OpenGL (rappelez-vous de Vista qui ne devait supporter OpenGL qu'en tant que surcouche Direct3D).

    Bref mon avis : encore un blogueur de bas étage qui aurait pu dire quelque chose d'intéressant s'il n'avait pas cherché à ajouter un max d'arguments pour cracher sur OpenGL qui, à l'heure actuelle, a bien rattrapé son retard sur Direct3D.
    Il suffit de voir les benchmark sous Unigine qui sont à ma connaissance ceux qui exploitent le mieux OpenGL.
    Tutoriels OpenGL
    Je ne répondrai à aucune question en MP
    - Si c'est simple tu dis que c'est compliqué et tu le fait
    - Si c'est compliqué tu dis que c'est simple et tu le sous-traite ou le fait faire par un stagiaire.

  13. #13
    Membre extrêmement actif

    Profil pro
    Inscrit en
    Février 2006
    Messages
    2 408
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 2 408
    Par défaut
    Citation Envoyé par shenron666 Voir le message
    A part ce point, une partie des remarques sont fausses ou inexactes depuis OpenGL 3, plus encore depuis OpenGL 4.
    D'autres sont liées à l'appréciation du développeur.
    développez, développez, sinon c'est pas mieux ...

    Citation Envoyé par shenron666 Voir le message
    Il ne faut pas oublier non plus un détail on ne peut plus important : OpenGL est multi-OS contrairement à Direct3D.
    xbox, xbox one, windows toute version, windows phone, windows rt, donc non plus.
    (contre windows, mac os, linux, les os mobiles étant exclus, opengl es étant suffisamment éloigné pour devoir réécrire systématiquement une partie du code)

    Citation Envoyé par shenron666 Voir le message
    D'autres remarques encore sont à adresser aux développeurs de pilotes (stabilité, compilateur de shader) voire de Microsoft en ce qui concerne les pilotes sous Windows car ce dernier a toujours fait de l'obscurantisme et mis des bâtons dans les roues d'OpenGL (rappelez-vous de Vista qui ne devait supporter OpenGL qu'en tant que surcouche Direct3D).
    perdu aussi, ça n'a jamais été le cas, mais bon, on se rattrape comme on peut. de plus, il a juste fallu une ou 2 mises à jour des pilotes de la part des constructeurs pour que opengl marche bien, parce que je rappelle quand même que vista avait introduit un nouveau modèle de pilote.

    Citation Envoyé par shenron666 Voir le message
    Bref mon avis : encore un blogueur de bas étage qui aurait pu dire quelque chose d'intéressant s'il n'avait pas cherché à ajouter un max d'arguments pour cracher sur OpenGL qui, à l'heure actuelle, a bien rattrapé son retard sur Direct3D.
    Il suffit de voir les benchmark sous Unigine qui sont à ma connaissance ceux qui exploitent le mieux OpenGL.
    *michel denisot* et si on parlait du post que tu viens de faire?
    et en plus opengl n'est pas tout rose (voir ce qui ce passe dans le mobile avec opengl es, où là pourtant il n'y a pas microsoft; ou encore les devs de dolphin qui ont quelques difficultés avec opengl, où alors ceux sont des dévs de bas-étage aussi?) bref, ai-je vraiment besoin de développer?

  14. #14
    Membre Expert
    Avatar de shenron666
    Homme Profil pro
    avancé
    Inscrit en
    Avril 2005
    Messages
    2 582
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : avancé

    Informations forums :
    Inscription : Avril 2005
    Messages : 2 582
    Par défaut
    Citation Envoyé par stardeath Voir le message
    xbox, xbox one, windows toute version, windows phone, windows rt, donc non plus.
    (contre windows, mac os, linux, les os mobiles étant exclus, opengl es étant suffisamment éloigné pour devoir réécrire systématiquement une partie du code)
    oui tu as raison, windows, windows, windows, windows, windows, windows, windows, et... windows
    (xbox et xbox one utilisant un ersatz de windows)
    ça en fait des plateformes différentes

    quand à opengl es, il est bien plus proche que tu ne semble vouloir le faire croire
    et tu peux adapter ta remarque à Direct3D vu que tu parles de windows phone
    Citation Envoyé par stardeath Voir le message
    perdu aussi, ça n'a jamais été le cas
    ça c'est fort
    Citation Envoyé par stardeath Voir le message
    mais bon, on se rattrape comme on peut.
    sérieux ?
    Citation Envoyé par stardeath Voir le message
    je rappelle quand même que vista avait introduit un nouveau modèle de pilote.
    aucun rapport avec la choucroute

    Citation Envoyé par stardeath Voir le message
    *michel denisot* et si on parlait du post que tu viens de faire?
    alors désolé mais je ne connait pas "michel denisot", alors si rapport il y a... je ne vois pas
    Citation Envoyé par stardeath Voir le message
    et en plus opengl n'est pas tout rose
    loin de là, sauf qu'il y a un moment où la critique doit être dirigée sinon on passe au troll
    Citation Envoyé par stardeath Voir le message
    bref, ai-je vraiment besoin de développer?
    pas la peine, j'ai parfaitement cerné que tu es pro D3D
    ce que je ne peux pas être vu qu'il n'est pas sous linux
    Tutoriels OpenGL
    Je ne répondrai à aucune question en MP
    - Si c'est simple tu dis que c'est compliqué et tu le fait
    - Si c'est compliqué tu dis que c'est simple et tu le sous-traite ou le fait faire par un stagiaire.

  15. #15
    Membre extrêmement actif

    Profil pro
    Inscrit en
    Février 2006
    Messages
    2 408
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 2 408
    Par défaut
    Citation Envoyé par shenron666 Voir le message
    oui tu as raison, windows, windows, windows, windows, windows, windows, windows, et... windows
    (xbox et xbox one utilisant un ersatz de windows)
    ça en fait des plateformes différentes
    bah oui toutes ces plateformes sont différentes, malgré que tu veuilles le contraire ...

    Citation Envoyé par shenron666 Voir le message
    quand à opengl es, il est bien plus proche que tu ne semble vouloir le faire croire
    et tu peux adapter ta remarque à Direct3D vu que tu parles de windows phone
    bah non, opengl es 2 et opengl 4, compare et tu verras que c'est très différent.
    et oui direct3d aussi, mais c'est pas moi qui essaie de cacher la moitié des choses.

    Citation Envoyé par shenron666 Voir le message
    ça c'est fort

    sérieux ?

    aucun rapport avec la choucroute
    et tu développes quand? ou alors il n'y a rien à développer de ta part tellement ton post est vide?

    Citation Envoyé par shenron666 Voir le message
    alors désolé mais je ne connait pas "michel denisot", alors si rapport il y a... je ne vois pas
    tant mieux.

    Citation Envoyé par shenron666 Voir le message
    loin de là, sauf qu'il y a un moment où la critique doit être dirigée sinon on passe au troll
    et d'ailleurs c'est quand qu'elle arrive la tienne de critique constructive? relis ton propre post et avise ...

    Citation Envoyé par shenron666 Voir le message
    pas la peine, j'ai parfaitement cerné que tu es pro D3D
    ce que je ne peux pas être vu qu'il n'est pas sous linux
    et? je le redis, et tu peux aller voir les autres threads, je préfère dx parce que je n'aime pas la syntaxe et le modèle de programmation d'opengl, et que entre dx et ogl maintenant c'est bonnet blanc et blanc bonnet.
    donc tes posts foireux, tu te les gardes et tu reviens quand tu as quelque chose à dire, à bon entendeur.

  16. #16
    Membre Expert
    Avatar de shenron666
    Homme Profil pro
    avancé
    Inscrit en
    Avril 2005
    Messages
    2 582
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : avancé

    Informations forums :
    Inscription : Avril 2005
    Messages : 2 582
    Par défaut
    Citation Envoyé par stardeath Voir le message
    et d'ailleurs c'est quand qu'elle arrive la tienne de critique constructive? relis ton propre post et avise ...
    [...]
    donc tes posts foireux, tu te les gardes et tu reviens quand tu as quelque chose à dire, à bon entendeur.
    avant de donner des conseils à d'autres, applique les à toi même
    tes posts ne sont pas plus constructifs que les miens bien au contraire

    chacun son avis, je ne préfère ni l'un ni l'autre personnellement, mais de mon point de vue les critiques du gars sont partiellement infondées

    ps : à l'avenir, évites d'être insultant et condescendant, franchement on dirait une réponse de gamin en pleine crise d'adolescence
    Tutoriels OpenGL
    Je ne répondrai à aucune question en MP
    - Si c'est simple tu dis que c'est compliqué et tu le fait
    - Si c'est compliqué tu dis que c'est simple et tu le sous-traite ou le fait faire par un stagiaire.

Discussions similaires

  1. Problème de points de vue sur les sockets ?
    Par humitake dans le forum C++
    Réponses: 19
    Dernier message: 07/04/2011, 16h17
  2. Vos points de vue sur ce CU
    Par cenotechnology dans le forum Cas d'utilisation
    Réponses: 0
    Dernier message: 13/05/2010, 17h33
  3. Point de vue sur le stokage rqte sql
    Par Mengué georges dans le forum JDBC
    Réponses: 1
    Dernier message: 07/11/2008, 18h54
  4. Réponses: 7
    Dernier message: 21/02/2005, 13h28
  5. compression de données du point de vue algorithmique
    Par GoldenEye dans le forum Algorithmes et structures de données
    Réponses: 9
    Dernier message: 26/06/2002, 15h51

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo