[Lib] DLL basées sur une même lib

Bonjour à tous,

Le contexte : je travaille actuellement sur un programme de traitement d'images bitmap dont on veut assurer l'extensibilité et la flexibilité.
Le programme principal, écrit en C++, charge des bibliothèques dynamiques qui contiennent des fonctions de traitement lourds (des plugins en somme) tels que fonction de correlations, ....
Ce même programme principal lance alors un script lua qui orchestre les traitements lourds pour arriver au résultat demandé. Jusqu'à là tout va bien.

Je désire maintenant que certaines fonctions lourdes, séparées dans plusieurs bibliothèques dynamiques, puissent utiliser OpenGL pour accélérer les calculs.


Est-ce que le fait d'intégrer la même lib statique dans chaque dll de traitement peut poser des problèmes de symboles à l'exécution, et est-ce une bonne solution ?

J'avais pensé également "wrapper" OpenGL dans une autre DLL et d'exposer les méthodes par le biais d'une interface, mais ca semble long et lourd, qu'en pensez-vous ?

Merci d'avance !

PS : j'ai déjà fait "google est mon ami", mais j'ai du mal à exprimer ma requête, donc à obtenir des réponses satisfaisantes.

Euh... OpenGL n'est-elle pas déjà dynamique? :?

En fait, la "librairie" openGL n'est qu'un wrapper de la librairie dynamique ad-hoc. Qui ne sera donc chargé qu'une fois.

Par contre, il faut savoir qu'OpenGL n'est vraiment pas réentrant, et donc, dire au revoir au parallèlisme (pourtant très utile en traitement d'image) si on se limite à l'executable qui appelle une fonction sur l'OpenGL pour recevoir le resultat et le passer à un autre traitement OpenGL. D'une part, il ne sera pas possible de "partager" le resultat (offscreen buffer) entre deux traitements, et d'autre part, cela necessitera un stall CPU/GPU à la fin de chaque traitement.

Il vaudrait mieux proposer une méthode plus "high-level" genre:

Plugin
|----------------|
Traditional ShaderPlugin

TraditionalPlugin va travailler à la dure sur les pixels...
ShaderPlugin va fournir un "shader" de pixels
Si les ShaderPlugin se suivent, alors on peut combiner tous les shaders en un "gros" shader, et n'utiliser qu'un device, et une passe de traitement...

Enfin.... à voir :)

si tu partages les DLL entre plugins, tu vas aussi partager leurs variables globales (dans le cas d'opengl, l'état d'opengl est global, un plugin va affecter un autre plugin)

Citation:

---

Envoyé par grob1212

Je désire maintenant que certaines fonctions lourdes, séparées dans plusieurs bibliothèques dynamiques, puissent utiliser OpenGL pour accélérer les calculs.

---

Hé attention Open GL c'est plutot conçu pour accélèrer l'affichage.

Citation:

---

Est-ce que le fait d'intégrer la même lib statique dans chaque dll de traitement peut poser des problèmes de symboles à l'exécution, et est-ce une bonne solution ?

---

Mais non parce qu'une dll c'est un programme exécutable ( mais qui ne s'exécute pas par le shell) indépendant.
Une lib liée à une dll pour faire un flou gaussien même si c'est la même dans une autre dll par exemple pour rajouter du bruit cette même lib n'interfera pas l'autre dll ce sont 2 programmes indépendants.
Je ne comprends pas ton problème
Une dll c'est un module de code qui en principe est commun à tous les programmes exe qui lui font appel

Sinon regarde la technologie ATL-COM cela conviendra plus à tes besoins peut-être

Pour Mat.M :

Citation:

---

Hé attention Open GL c'est plutot conçu pour accélèrer l'affichage.

---

Pas dans mon cas, il s'agit bien de faire du GPGPU avec OpenGL (dans une autre vie, sous DirectX, cela m'a permis d'accélérer un traitement particulier par plus de 400).

Citation:

---

Mais non parce qu'une dll c'est un programme exécutable ( mais qui ne s'exécute pas par le shell) indépendant.

---

Je me trompe peut-être, mais il me semble que c'est justement le contraire (au moins pour les dll inprocess). Une DLL est un ensemble code/données qui est chargé dans l'espace d'exécution lié au processus. Sauf à ce que je n'ai rien compris (et c'est possible :)), il me semble donc que si l'on charge 2 dll liées une lib statique, on va se retrouver avec des conflits ?

D'ailleurs j'avais pris l'exemple d'OpenGL qui ne semble pas être un bon exemple pour décrire mon interrogation.

Citation:

---

Sinon regarde la technologie ATL-COM cela conviendra plus à tes besoins peut-être

---

C'est un développement multiplateforme.

Pour screetch :

Citation:

---

si tu partages les DLL entre plugins, tu vas aussi partager leurs variables globales (dans le cas d'opengl, l'état d'opengl est global, un plugin va affecter un autre plugin)

---

En fait c'est 1 plugin=1 traitement=1 DLL. Et mon problème c'est que plusieurs DLL peuvent utiliser la même lib (statique ou dynamique).
Je suis d'accord avec toi sur ce que tu dis entre parenthèses.

Pour nicroman :
Je n'ai pas l'intention de faire du parallèlisme CPU/GPU. C'est juste que certains de mes algos s'exécuteront beaucoup plus rapidement avec une approche purement GPU qu'avec une approche purement CPU et ceci, même en y ajoutant les temps de chargement/récupération de texture/init des render states.
Par contre, j'aime assez bien l'idée des ShaderPlugins, je vais gratter dans ce sens.

En tout cas, merci pour les contributions !

OK, pour le partage, mini-cours.

1. Définitions:
   
   • Module (Windows): Un exe ou une DLL.
   • Bibliothèque statique: Une vraie bibliothèque statique qui contient vraiment du code. Je ne parle pas ici des bibliothèques statiques d'importation qui permettent à un module d'en référencer un autre.
2. Partage des données:
   
   • Deux modules employant la même bibliothèque statique possèdent chacun leur propre copie des variables "globales" de ladite bibliothèque: En clair, les variables globales d'une bibliothèque statique ne sont pas partagée entre les modules.
   • Les modules ont leurs propres variables globales, mais au sein d'un même processus, ils peuvent se passer des pointeurs vers les variables en question.
   • Les variables globales d'un même module ne sont pas partagées entre les processus.
   • Si deux modules d'un même processus référencent le même troisième module, il n'y aura dans ledit processus qu'un seul exemplaire des variables globales dudit troisième module.

Voilà, j'espère que ça clarifie. Ne connaissant pas OpenGL ni les bibliothèques statiques ou dynamiques employées dans les plugins, je ne peux pas tirer de conclusions sur les éventuels conflits de données; c'est aux intéressés de le faire.

Salut

Citation:

---

Envoyé par grob1212

Bonjour à tous,
Est-ce que le fait d'intégrer la même lib statique dans chaque dll de traitement peut poser des problèmes de symboles à l'exécution, et est-ce une bonne solution ?

---

Au niveau concept. c'est pas une bonne solution dans le cas ou les deux DLL font des choses completement differentes
En ce qui concerne OpenGL, GLU, GLAUX ... devrait suffire. Si tu veux créer une ta propre DLL,Fais en sorte qu'elle ne fasse que de l'OpenGL et pas du calcul scientifique car s'est des domaines completement a l'oposé l'un de l'autre.
cordialement
ps : c'est jsute un avis, et les avis divergent souvent

Franchement, trop fort là !

Je pensais justement que ce serait bien que quelqu'un connaissant bien le sujet puisse faire un mini-cours, ca c'est de la proactivité !

Plus sérieusement, merci Médinoc. Est-ce que c'est valable pour linux ?

Je vais regarder ce que ça donne, ramené à mes préoccupations.

Je ne connais pas assez linux pour savoir comment son équivalent des DLLs marche, mais je présume que oui.

c'est pareil sauf qu'un bibliothèque partagée sous Linux est capable de référencer l'executable (c'est aussi valable sous windows mais plus compliqué)

Sous windows, tu ne peux pas avoir A.exe qui référence B.dll qui référence A.exe de nouveau. Tu peux seulement avoir A.exe qui référence B.dll ou bien B.dll qui référence A.exe. Il doit avoir quelque part un chargement dynamique pour que ca marche.

en revanche sous linux l'édition de lien est partielle, tu peux donc avoir a.so qui référence b.so qui référence a.so de nouveau, et ca marche.

c'est la seule réelle différence, il me semble.
Le reste est toujours valables (séparation des données)

c'est tres important de comprendre ce que medinoc a ecrit; a chaque fois que tu utilises une variable globale il faut que tu te demandes :
"ou est cette variable ?" (dans quel module de quel processus ?)
on part du principe que tu n'as qu'un seul processus
alorsi l faut toujours te demander "ou est ma variable?"

une variable ne peux PAS etre dans un .lib statique, elle ne peut etre que dans un .exe ou une .dll
donc si tu as une variable globale dans une bibliotheque statique, elle existera dans toute les dll qui y font référence

le contraire : si une variable est dans une dll, et que la dll est utilisée par plusieurs autres dll, alors ta dll est partagée et donc ta variable est partagée aussi.

Merci pour ces précisions screetch.
Ce serait bien d'en faire profiter tout le monde sous la forme d'un article.
Je m'y collerai dès que j'aurais un peu de temps, avec votre aide biensur :)

Si vous avez des références sur le sujet, elles sont bienvenues (l'anglais ne me pose pas de problème).

Merci encore.