Hi,

Je suis en train de suivre le tuto LearnOpengl, et dans le tuto il parle de la bibliothèque GLAD, en disant que cela permet de gérer les pointeurs sur les fonctions, parce que le compilateur ne sait pas où les trouver un truc comme ça.

Ça reste très flou pour moi cette histoire

Pouvez-vous m'éclairer un peu plus sur le sujet (à quoi sert exactement GLAD et tout)

Salut,

Je vais tâcher de t'expliquer son utilité.

Quand tu installes Visual Studio sous Windows par exemple, il embarque avec lui la bibliothèque standard de C++. Le compilateur sait alors ce qu'est un std::vector, etc.

Quand tu veux utiliser une bibliothèque externe comme SDL2, c'est toi qui donnes le .LIB et les includes au compilateur et à l'éditeur de liens que tu as téléchargés au préalable sur le site officiel de la SDL2.
Le .LIB indique à l'éditeur de liens à quelle adresse dans la DLL se trouve telle ou telle fonction de la SDL2 que tu appelles dans ton programme. Tout cela s'imbrique alors parfaitement car tu fournis toi-même le fichier SDL2.dll quand tu distribues ton programme à d'autres personnes.
Si maintenant, tu mets une autre version de la DLL de la SDL2, ça ne va pas marcher s'il y a eu d'autres fonctions ajoutées ou supprimées : l'adresse ne correspond plus.

Quand tu veux utiliser OpenGL, c'est plus compliqué. OpenGL ne fait que décrire ce qu'elle doit faire, il n'y a pas de code dans ce qu'on appelle les spécifications d'OpenGL. Ce code est fourni avec le driver de la carte graphique installée dans l'ordinateur de la personne qui lance le programme. Donc, pour chaque driver on peut avoir une DLL opengl32.dll différente. Sans parler des différences possibles entre les implémentations par NVidia, AMD ou Intel.

Tu ne peux donc pas fournir un .LIB à ton programme et donc celui-ci ne pourra pas savoir à quelle adresse se trouve "glClear()" par exemple. Tu ne peux pas non plus donner le fichier opengl32.dll qui est forcément dépendant de la carte graphique.

Il faut alors charger la DLL dans le programme puis chercher manuellement l'adresse de chaque fonction d'OpenGL, comme "glClear()". Le tuto de LearnOpenGL te donne un exemple de ce que tu devrais faire rien que pour pouvoir appeler "glGenBuffers()"...

GLAD sert à donc à simplifier tout ça. Il va charger la DLL pour toi et chercher les adresses auxquelles se trouvent toutes les fonctions d'OpenGL.

Quand tu fais gladLoadGLLoader((GLADloadproc)glfwGetProcAddress), tu fais exactement ça : tu vas charger la DLL dans le processus actuel (l'identifiant du processus est donné par glfw dans ce cas) et GLAD va chercher l'ensemble des fonctions d'OpenGL qu'il doit trouver pour toi.

C'est ce qui te permet alors d'utiliser en toute "insouciance" les fonctions d'OpenGL quelque soit ta carte graphique.

-
Edité par Anonyme 23 mars 2020 à 15:12:19

Wow , merci pour cette réponse, c'est tellement rare d'avoir une explication aussi claire et bienveillante en francais. Mais du coup, ton explication appelle une autre question : à quoi sert le opengl.lib ? j'étais persuadé qu'il était justement nécessaire pour pouvoir se "rattacher" aux fonctions de la dll. 

opengl32.lib est une libraire d'import minimaliste d'OpenGL fournie par le SDK Windows. Elle ne couvre qu'OpenGL 1.1, alors qu'on est à OpenGL 4.6 (20 ans d'écart...).

-
Edité par SpaceIn 4 avril 2022 à 12:51:53

Salut,

Pour être complet:

les .lib (quelle que soit la bibliothèque externe envisagée) sont "généralement" de simples archives dans lesquelles on va retrouver le code binaire exécutable de toutes les fonctions qui se trouvent dans la bibliothèque concernées.

Nous parlons alors de "bibliothèque statique".

Ce qui va "généralement" se passer, c'est que, une fois que ton compilateur aura généré le code binaire exécutable de ton programme, ce sera à un deuxième outil de prendre le relais afin de "regrouper" le code binaire exécutable de toutes les parties utilisées par le programme en un seul et unique fichier.

Le taf de ce deuxième outil sera, après avoir "copié" le code de toutes les parties utilisées, de faire correspondre chaque appel à "une fonction quelconque" à l'adresse mémoire à laquelle se trouve le début de cette "fonction particulière"  dans le programme.

Ben oui, parce qu'il faut bien comprendre que les instructions qu'une fonction doit effectuées, elles se trouvent ** forcément ** "quelque part" en mémoire et qu'elles ne vont pas être fournies par "l'air du temps"

Et donc, comme cet outil va "éditer les procédures d'appel" des fonctions pour "faire le liens avec l'endroit où les fonctions se trouvent", nous parlerons en toute"logique" de ... l'éditeur de liens

Seulement, tu as pu constater que j'ai utilisé à deux reprises le terme "généralement".  Si je l'ai fait, c'est parce que les explications qui précèdent sont valables, justement, lorsque l'on utilise des bibliothèque statiques, c'est à dire des bibliothèques dont le code binaire exécutable qui les compose est "directement" ajouté à l'exécutable.

C'est parce que, lorsque l'on utilise une dll, les choses sont "un peu plus complexes" du point de vue de l'outil. Lui, il voudra toujours faire le même taf, et il va le faire parfaitement.  A ceci près qu'il n'est plus question de prendre le code binaire exécutable de la dll pour le copier dans l'exécutable.

Le .lib que l'on utilise va alors correspondre à ce que l'on appelle une "bibliothèque de liaison".

Pour faire simple, les choses vont alors se faire "en deux temps":  Dans un premier temps (au niveau du développeur de la dll) le .lib va dresser la liste des fonctions exposées par la dll et s'assurer d'être en mesure d'accéder à  chacune d'elle, afin de "transférer" correctement l'appel à  "une fonction particulière".

Dans un deuxième temps, l'éditeur de liens va utiliser le .lib (ce qu'il fait déjà avec une bibliothèque statique) pour modifier les endroits du code binaire exécutable où les différents aux différentes fonctions surviennent afin de faire en sorte ... que l'appel à une fonction bien particulière pointe bien vers l'endroit l'endroit de la mémoire dans l'exécutable  auquel commence cette fonction et qui, dans le cas d'une dll, se "contentera" de "transférer l'appel" vers la dll.

Cela permet de faire en sorte que, quelle que soit la version de la dll utilisée et pour autant que la "compatibilité binaire" soit assurée (comprends: que les mêmes fonctions se trouvent au même endroit dans les différentes versions de la dll), il est "en théorie"(*) possible de changer la version de la dll (pour profiter des mises à jour, par exemple) sans avoir besoin de faire "quoi que ce soit" au niveau du programme en lui-même

(*) Bien sur, il y a toute une série de circonstances qui peuvent faire que la théorie ne soit pas applicable, mais ca, c'est une autre histoire

Merci Koala01, les choses sont plus claires maintenant ! Si j'ai tout bien compris, le .lib ne fait que contenir le noms des fonctions de la dll , accompagné de l'adresse de la dite fonction dans la dll. Mais dans le cas de Opengl, les constructeurs de CG ne respectant pas forcement la fameuse "comptabilité binaire" dont tu parles, le .lib ne sert finalement pas à grand chose. D'ou l'intérêt de GLAD, qui permet, par je ne sais quel tour de passe-passe, de récuperer l'adresse exacte de toutes les fonctions de la dll pendant l'exécution .

C'est à peu près cela, en effet

Ceci dit, le "tour de passe passe" en question, il est tout simple, étant donné que glad va commencer par charger la dll en mémoire (dlopen() )

Ensuite, il va demander l'adresse (dans la dll) de toutes les fonctions qui l'intéressent, ce qui correspond -- pour faire simple -- à la liste de toutes les fonctions "potentiellement utilisables" pour la version de OpenGL que l'on souhaite utiliser

Mais le fait est que tu n'as pas vraiment à t'en inquiéter: glad est prévu pour être très facile à compiler (même si c'est du code écrit en C), et, pour peu que tu t'assure de compiler le fichier glad.c et de donner l'accès aux fichiers glad/glad.h et KHR/khrplatform.h (souvent optionel ), la magie pourra opérer sans que tu n'aie besoin de te casser la tête avec cela

La seule chose à laquelle tu devras être attentif étant, au  final, de n'appeler que les fonctions

• qui correspondent à la version de OpenGl que tu souhaites utiliser et
• dont l'adresse a été trouvée dans la dll fournie par le constructeur de la carte graphique

-
Edité par koala01 5 avril 2022 à 16:44:08

Oui effectivement, mais par tour de passe-passe , je fais justement référence au fait que je ne sais pas comment il trouve le début de chaque fonction dans la dll, car si je ne dis pas de bêtise, une dll c'est du code binaire. C'est la ma dernière petite incompréhension . Y a t il du texte au début de chaque dll qui précise l'emplacement de chaque nom de fonction?

Et oui comme tu dis, je n'ai pas forcement à comprendre tout ça , mais bon ... ahhh curiosité quand tu nous tiens 

Qu'entendez vous pas "code binaire" ?

Un exécutable est aussi un code binaire, et lui aussi, comme une dll, dispose de zone/en-tête qui permet de faire des "tâche administratives" par l"OS (les dll "statiquement" liées au module binaire, le point d'entrée (qui n'est généralement ni "main" ou "DllMain" mais une fonction crée par le compilateur "en sous-marin"), les symboles exportés pour qu'ils soient visibles de l'extérieur du module,  etc...)

Et les noms de fonctions (ainsi que leurs numéros) ne sont que des symboles comme les autres, exportable comme les autres variable globales externes/exportées.

Donc votre vue du "texte au début du chaque dll" est simpliste mais pas si éloignée de la réalité.

Bonjour bacelar, merci pour votre réponse.

Par code binaire, j'entends que les noms de variables et les noms de fonctions n'existent plus (enfin c'était ce que je croyais avant de vous lire). Vous dites qu'avant chaque exe ou dll il y a une en-tête avec écrit le nom des variables global et fonction du code source, et les adresse de chacune? Dans ce cas (désole de tourner en rond ! xd), je ne comprends toujours pas à quoi sert Glad. Le .h ne devrait il pas suffire à retrouver les bonnes fonctions à l'aide de cette fameuse en-tête dans la dll, même si la comptabilité binaire dont koala01 parlait n'est pas respecté, dans la mesure ou l'en-tête est créé par la dll elle même? Ou y a t il encore quelque chose que je ne saisis pas?

Cela m'intéresse beaucoup de mieux comprendre tout cela (notamment l'organisation détaillé d'un exe ou dll). Avez vous un livre ou un site à me conseiller sur ce sujet, en francais de préférence, ou en anglais pas trop compliqué (je me suis mis à fond dans l'apprentissage de l'anglais il y a peu, mais j'ai encore un niveau bancal).

VictorLemaire3 a écrit:

Bonjour bacelar, merci pour votre réponse.

Par code binaire, j'entends que les noms de variables et les noms de fonctions n'existent plus (enfin c'était ce que je croyais avant de vous lire). Vous dites qu'avant chaque exe ou dll il y a une en-tête avec écrit le nom des variables global et fonction du code source, et les adresse de chacune? Dans ce cas (désole de tourner en rond ! xd), je ne comprends toujours pas à quoi sert Glad. Le .h ne devrait il pas suffire à retrouver les bonnes fonctions à l'aide de cette fameuse en-tête dans la dll, même si la comptabilité binaire dont koala01 parlait n'est pas respecté, dans la mesure ou l'en-tête est créé par la dll elle même? Ou y a t il encore quelque chose que je ne saisis pas?

On va donc reprendre depuis le début:

OpenGL, ce n'est qu'une spécification, c'est à dire un "papier" qui reprend la liste des fonctions dont l'on s'attend à disposer quand on veut communiquer avec la carte graphique ainsi que des résultat que tu peux attendre de la part de ces fonctions.

Cette spécification en est -- sauf erreur de ma part -- à sa quatrième version majeure, auxquelles il faut ajouter on va dire entre quatre et huit versions "secondaires" par version majeure.

Bref, au total, on peut "raisonnablement" penser que ce machin a évolué une bonne quarantaine de fois depuis sa création. Et chacune de ces (on va dire) quarante évolutions propose une bonne trentaines de fonctions "requises" par la spécifications.

Donc, pour faire simple, nous en sommes à près de quarante versions d'une trentaine de fonctions différentes (en fait, ce n'est pas tout à fait vrai, car certaines fonctions n'ont fait leur apparition qu'à l'occasion d'une version majeure et pour d'autres, on a justement profité du passage d'une version majeure à la suivante pour les supprimer, parce qu'elles étaient devenues inutiles).

A tout ce beau monde, il faut ajouter une série de fonctionnalité comme des structures et autres qui sont susceptibles d'être utilisées par la carte graphique.

Et comme si cela ne suffisait pas, il y a plusieurs fondeurs de carte graphiques (principalement AMD et NVIDIA) qui se font une concurrence acharnée et qui prennent un malin plaisir à fournir LA fonctionnalité que l'autre ne fournit pas (ou éprouve du mal à mettre en place). Et ils n'ont bien sur, aucune raison de renoncer à ces fonctionnalités. Ils vont donc tout faire pour que leurs fonctionnalités "spécifiques" apparaissent dans la spécification, même si cela implique qu'elles soient "taguées" sous une forme qui dise "attention, ceci n'est disponible que pour les cartes AMD/NVIDIA/autres...

Bref, c'est un sérieux bordel (et je n'ai même pas encore parler des versions "assouplies" comme GLS et autres

D'un autre coté, l'en-tête gl.h et ses consoeurs que tu utilises peut-être, elle ne sont absolument pas fournies par l'un ou l'autre fondeur de carte graphique. Elle est fournie par ... celui qui développe ton compilateur.

Et lui ne sait absolument pas quelle carte graphique tu veux utiliser. Ce fichier d'en-tête va donc déclarer ... toutes les fonctions possibles et imaginables que la spécification peut avoir citées.

Ainsi, si on fait le compte des fonctions déclarées dans les différents fichiers d'en-tête (gl.h, glaux.h, glattr.h, glext.h, glu.h et glxext.h), on se retrouve au final avec 6 à 8000 fonctions déclarées car "susceptibles d'être requises par une version (ou une autre) de la spécification OpenGL"

Et toi, pauvre utilisateur d'une carte graphique, tu dois choisir parmi ces 6 à 8000 fonctions, seulement entre trente et cinquante fonctions "qui t'intéressent" en fonction de la version de OpenGL que tu veux utiliser.

Et bien sur, tu dois t'assurer que chacune de ces fonctions soit bel et bien fournie par le pilote de ta carte graphique.

GLAD ne fait que ca pour toi: il sélectionne -- parmi les 6 à 8000 fonctions déclarées par les en-têtes dont tu disposes -- la trentaine ou la quarantaine de fonction qui correspondent effectivement à la version de OpenGL que tu veux utiliser et, s'assure (à l'exécution) qu'elles soient toutes effectivement disponibles du coté du pilote de ta carte graphique.

Et si le fichier d'en-tête glad.h ne suffit pas, c'est justement parce qu'il y a cette "vérification" à l'exécution (qui se fera -- de plus -- de manière différente selon l'OS utilisé) qui doit être effectuée

(Je supprime ce message qui était à coté de la plaque, je lirai votre message plus attentivement plus tard koala)

-
Edité par Askypp 18 avril 2022 à 18:15:30

Il y a pas mal de vérifications supplémentaires mais vous avez une vue d'une implémentation assez "réaliste"?

C'est bon, j'ai tout bien compris, merci à vous trois. D'ailleurs, mon incompréhension tenait plutôt aux dll en général que à glad.

Pour les prochains qui tomberaient sur cette discussion à l'avenir, je vous conseil en complément des explications ici présente,  de construire et utiliser une dll manuellement. L'utilité de glad ensuite vous coulera de source. (oui c'est ce que j'ai fais aujourdhui).

Bonne continuation à tous.