Cuda C, OpenCL, directcompute,

Bonjour à tous,
Actuellement, afin de visionner mes applications en relief, j'utilise deux écrans séparés. Ils reçoivent les images vues respectivement par l'œil droit et l'œil gauche. Du point de vue programmation, l’affichage se fait sur un seul écran physique (Fonctionnalités proposées par NVIDIA),les 2 écrans sont vus comme un seul de 1900 x2 pixels en largeur).Un système de miroirs encombrant est nécessaire pour la fusion des 2 images.
J’envisage l’utilisation d’un moniteur « 3d active »(avec lunette).
Ma question est de savoir comment se fait la programmation d’un tel moniteur : en clair, comment programme-t-on les 2 écrans physiques qui s’affichent alternativement à une cadence de 100 mhz environ ?

A grand peine j’ai trouvé quelques pistes…
citation: "Le fabricant vien de présenter Nexus, un environnement de développement supportant Cuda C, OpenCL, ou encore directcompute, et fonctionnant sous visual studio. Le développeur peut ainsi coder et débuguer le code du GPU de la meme facon et avec les meme outils que pour le CPU, rendant très simple l'intégration du GPU dans le code principal."
http://www.iz3d.com/api
http://www.nvidia.fr/object/directcompute_fr.html

C’est du chinois pour moi…quelqu’un pourrait-il m’éclairer ?

Merci pour votre aide.

Salut,

Comme, a priori, je ne vois pas vraiment comment on pourrait t'aider, je vais déjà essayer de faire de manière à ce que tu comprennes ce que tu lis :D

D'abord, il faut savoir que, si l'on peut appréhender les volumes, c'est parce que l'on a deux yeux séparés qui envoient au cerveau des image "un tout petit peu différentes" de l'autre oeil (bon, je simplifie, ca ne sert à rien d'entrer trop dans les détails, hein ? ).

En effet, comme l'oeil gauche ne se trouve (encore heureux, tu me diras :D) pas à la même place que l'oeil droit, le "point de vue" de l'un est différent du point de vue de l'autre.

C'est le cerveau qui amalgamera les deux images pour en faire quelque chose de cohérent qui nous donnera une idée du volume des choses ;)

Il faut savoir que, dés que les images défilent à une certaine vitesse (de l'ordre de 25 images par seconde, et je crois que c'est meme un chiffre un peu moins élevé :P), et bien qu'il s'agisse d'images fixes, la permanence rétinienne va déjà te donner une impression de mouvement.

Si tu "montes" à plus de 50 à 60 images par secondes, tu ne verras plus de différences, et les mouvements te sembleront tout à fait fluides.

L'idée de la projection 3D (car c'est le meme principe que tu sois dans une salle de cinéma ou que tu regardes la télé) est donc de se dire que, comme on arrive à faire en sorte que les images se raffraichissent à une vitesse de l'ordre de 100 images par secondes, on pourrait très bien s'arranger pour envoyer une image sur deux pour l'oeil gauche et une image sur deux pour l'oeil droit, en ayant pris soin de décaler légèrement le point de prise de vue, le cerveau est tellement habitué au décalage qu'il reproduira ce qu'il fait en permanence, à savoir, fournir une vision stéréoscopique.

Evidemment, il faut, surtout, faire en sorte que l'image qui est destinée à l'oeil droit ne soit perçue que par l'oeil droit, et que celle qui est destinée à l'oeil gauche ne soit perçue que par l'oeil gauche.

C'est là qu'interviennent les lunettes car, pour y arriver, on joue sur les couleurs et sur les filtres (je fais toujours simple, donc, ce n'est pas forcément tout à fait juste, mais le principe est quand meme là ;))

Ca, c'était pour le principe général de la projection en 3D ;)

Maintenant, il faut savoir qu'une image qui arrive à l'écran, ce n'est jamais qu'une succession d'impulsions électriques qui seront comprises et analysées par, faisons simple, un processeur.

Seulement, c'est un processeur particulier dans le sens où il est spécialisé dans le traitement du rendu d'images.

C'est pour cela qu'on l'appelle "GPU" (pour Graphic Processing Unit), par comparaison au terme utilisé pour les processeurs "traditionnel" qui CPU.

Ainsi, quand l'article dit

Citation:

---

Le développeur peut ainsi coder et débuguer le code du GPU de la meme facon et avec les meme outils que pour le CPU, rendant très simple l'intégration du GPU dans le code principal.

---

hé bien, il veut dire qu'il devient aussi facile de programmer le processeur graphique que de programmer n'importe quel autre processeur ;)

Enfin, l'article parle de CUDA C, OpenCl, DirectCompute et Visual Studio...

CUDA est l'acronyme de Compute Unified Device Architecture, pour faire simple, une technologie qui permet de programmer un processeur graphique pour qu'il prenne en charge certains traitement du processeur classique en utilisant le langage C ;).

OpenCl et DirectCompute ne sont en définitive que des technologies sommes toutes très similaires à CUDA.

Quant à Visual Studio, en fait, c'est un EDI (un Environnement de Développement Intégré) fourni par microsoft qui supporte différents langages ;)

Au final, l'article tend à dire "quelle que soit la technologie que vous connaissez / préférez, vous pourrez programmer le GPU tres facilement ;))

Bonjour,

De mémoire, NVIDIA a un système d'extension pour OpenGL qui propose quelques buffers en plus (un pour l'oeil gauche et un pour l'oeil droit) et ainsi on choisit ce que l'on veut dessiner et où.

Sinon, le pilote peut faire le travail tout seul en s'aidant du buffer de profondeur.

Citation:

---

Envoyé par nodarp

Ma question est de savoir comment se fait la programmation d’un tel moniteur : en clair, comment programme-t-on les 2 écrans physiques qui s’affichent alternativement à une cadence de 100 mhz environ ?

---

Bonjour.

Vous êtes sous DirectX ou OpenGl, ou alors vous diffusez les videos avec un player ?

Merci beaucoup pour les explications et les pistes offertes.
J’avais espéré plus simple…mais je vais essayer .si j’ai bien compris, nul besoin d’avoir un moniteur 3d pour afficher tour à tour les images gauches et droites …il faut « vider le buffer » dans lequel sont placées alternativement les images gauches et droites à la cadence souhaitée. La particularité d’un moniteur 3d c’est donc d’émettre un signal pour obturer, soit le verre de lunette gauche, soit le droit en fonction de l’image présente à l’écran, ce en quelque centième de seconde…pas besoin de carte graphique spéciale donc ?
Ne faut-il pas connaitre la cadence exacte de la substitution gauche-droite ? Ou récupérer le signal adressé aux lunettes pour vider le buffer?

J’avoue que du code « tout cuit » sous c# ou VBNET qui ferait appel aux DLL citées m’arrangerait !
J’ai moi-même trouvé des pistes qui semblent intéressantes :
http://code.msdn.microsoft.com/windo...ceCode#content
Qu’ en pensez-vous ?
Faire des constructions géométriques directement dans l’espace, y promener un curseur, c’est passionnant …si je pouvais me débarrasser de mon encombrant jeu de miroirs !
Encore merci pour votre aide !