Comment fonctionne ces 2 là ? et je suis un peu mélangé des les concepts.. ce sont des API ou des API 3D ? ou si ce sont des bibliothèques de fonctions ou bien des librairies de fonctions      
 
Car sur le net souvent on arrive sur un site, ils appellent ça un librairies, une bibliothèques, des API, API 3D, lequel est le bon terme ?    
 
et puis comment ils fonctionnent exactement ? disons que je veux refaire mes propres fonctions, comment je peux accéder à la carte vidéo ? avec le mode Vesa ? et donc je devrai programmer mes propres fonctions d'anti-aliasing, de lumières, etc ?

http://www.opengl.org/about/overview.html

Bibliothèque c'est le terme français.
(library en english c'est bibliothèque, le traduire par librairie est une erreur courante)
 
API ou API 3D c'est la meme chose pour parler d'OpenGL.
Idem pour Direct3D.
 
Sinon VESA, c'est.. comment dire "dépassé". Pour programmer la carte tu passes par une API (OpenGL ou D3D) qui est l'interface de programmation standard et qui est la seule qui soit documentée.  
 
Je te rassure, c'est déjà beaucoup de boulot meme en partant avec les fonctions "toute faites".
 
A+
LeGreg

Les deux sont des API / API 3D (Application Programming Interface) fournies par le biais de bibliothèques (librairies) (.dll exploitables en programmation par le biais de .lib)
 
Sinon, tu peux oublier le mode Vesa de nos jours:
 
1. Il marche en interruption (hum... dommage Windows est la...),
2. c'est du software,
3. c'est dépassé,
4. inutile de réinventer la roue...
 
Si tu débutes je te conseilles de te mettre d'abord à openGL qui offre une approche permettant de se focaliser essentiellement sur la programmation graphique et qui est donc beaucoup moins contraignante que l'API Direct3D...
 
OpenGL peu meme être utilisé avec glut qui t'offre un gestionnaire de fenêtre et d'évenements minimal...
 
- Spécifications:
-> http://www.opengl.org
 
- Tutorials et ressources:
-> http://nehe.gamedev.net
 
Sinon sur Direct3D (si c'est toujours comme la version 7.0) il faut savoir qu'il y a deux modes de développement:
 
- Le mode retenu qui offre une souplesse d'utilisation similaire à openGL,
 
- Le mode immédiat qui est de beaucoup plus bas niveau (pas en terme de matériel)

j'ai commençé au 8, le SDK n'expose plus depuis la différence immediate/retained.

 
Quelques confusions ici.
 
Le mode retenu n'a rien à voir avec OpenGL, par contre
c'est vrai qu'il a disparu au profit d'un mode immédiat.
Le mode retenu était plutot evolué (encore plus haut niveau qu'OpenGL) mais personne ne voulait l'utiliser parce que chaque développeur voulait tout faire lui-meme.  
 
Le mode immédiat actuel est relativement proche
d'OpenGL dans le principe meme s'il est beaucoup plus
clean d'un point de vue design (le design original de OpenGL encourage l'utilisation de vertex par vertex à la carte graphique et meme s'il y a des extensions aujourd'hui les mentalités sont lentes à changer).
 
De toute façon il n'y a plus de comparaisons possibles
entre Dx3 (qui a introduit le RM comme le mode principal de programmation) et dx9.
 
LeGreg

oui je n'ai jamais voulu faire de rapprochement entre d3d et openGL, je parlais juste en terme de fonctionnalités et primitives existantes

Mais Opengl lui-même fonctionne comment ? il utilise les API windows comme GDI ? ou si ça à été fait en assembleur et il passe directement par le VESA des cartes ?
 
J'aimerais bien comprendre les étapes de fonctionnement entre la fonction: DESSINE_MOI_UNE_SPHERE() en passant par l'exécution et l'affichage à l'écran.
 
On dit que OpenGL remplace vesa, ouaip bon mais ça marche comment au juste ?  

2 ans après
 
que ce soit l'OpenGl, Direct3D ou l'interface VESA, ce sont des interfaces/api.
 
VESA est exposé par le bios de la carte graphique, et il ne permet qu'un accès linéaire à la mémoire vidéo, et a une multitudes de modes vidéos (pas d'accélération de traçage de primitives, bien que cela aies été tenté par l'interface VBE/AF)
 
D'une part comme c'est un service de bios, sous un OS moderne comme Windows, Linux, MacOS, ce genres d'interfaces bas-niveau ne sont plus accessibles au niveau Application.
 
VESA 2.0 & 3.0 a eu son heure de gloire avec les DOS-extenders (DOS4G/PMODE...), a l'époque des jeux et des démos sous DOS.
 
l'interface VESA ne sert plus que de "fallback" a Windows & Linux quand tu n'as pas de driver pour ta carte vidéo. (les primitives sont traçées en ram vidéo par le cpu, donc ça rame).
Ensuite le driver vidéo de l'OS contoune les services du bios et accède directement au matériel.
 
OpenGl et Direct3D sont des interfaces orientées machine à états, tu as un (unique) contexte de traçage courant où tu définis tes attributs et tu pousses tes primitives de traçage.
 
Ils sont en quasi accès-direct au matériel, ils ne s'appuient pas sur les autres interfaces graphique de l'OS (GDI, serveur X), mais sont implémentés pour bien sûr maintenir une certaine cohérence avec les autres interfaces.
 
Et donc justement, les "drivers" D3D, OpenGl GDI ou autre sont généralement packagés ensemble car ils partagent certaines couches pour maintenir la cohérence de l'accès bas-niveau à la carte.

Ok
 
Mais comment, justement, ils accèdent directement au matériel ?
 
Car la 3D n'est rien d'autres que suite de fonctions en fait, si on parle de primitives, par exemple, un cube, ces fonctions (ceux de opengl par exemple) sont gravé dans une puces sur la carte graphique ?
 
Pourtant quand on exécute un exe sous windows, celui-ci est traité par le cpu central et non par le gpu.    
 
Ce cpu est indépendant du driver, je vois mal comment il fait pour envoyer des datas au gpu..
 
Pour quelqu'un qui voudrait, pour comprendre le fonctionnement, faire sa propre lib 3D, il devra accéder directement à la carte graphique sans lib intermédiaire ? Il devra programmer avec le pilote de la carte ? Pourtant opengl est portable et ne dépend pas du pilote ...  

la carte vidéo expose des ressources matérielles plages mémoire/irq, le pilote vidéo alimente le chip vidéo en écrivant dans ses registres de contrôles et/ou dans une zone d'échange en ram vidéo.

Si tu étudies bien opengl ou directx, tu comprendra le fonctionnement des différents pipelines liés à la 3d. Piloter la carte directement n'est plus vraiment interessant, même si ca pouvait l'etre il y a quelques années. Il y a des choses de plus haut niveau à faire qui sont interessantes et qui t'ameneront à la meme comprehension de tout ça.
 

C'est parce que les drivers fournissent (à peu près) les même interfaces pour opengl.

Si je comprends bien, opengl EST le hardware, enfin des fonctions graphiques présente sur les cartes et les dll de opengl sont une couche au dessus pour utiliser ces fonctions là.    
 
Mais si je créé une fonction, donc software, comment la faire exécuter par le gpu au lieu du cpu ?

tu peux pas, tu est obligé de te plier à ce que l'inteface propose. (accessoirement si les shaders sont supportés tu auras ptet des possibilitées de faire ce que tu désire)

 
J'ai du mal à comprendre, pourrais-tu me donner un exemple concret stp ?

 
avant directx7, on ne pouvait traiter les vertex qu'avec le proc principal, et les textures par la carte vidéo, en hard. Ensuite, on a pu traiter les vertex sur le gpu.

Oui mais justement, comment c'est implanté au juste ?    
 
Si je fais une fonction en c++ qui dessine un cube et le fait tourner, sans opengl, ni directx, comment je peux le faire ?
 
Ce que tu dis c'est que quand on dessine de quoi à l'écran, le exe apelle les api windows, mais les api windows font comment ? la fonction machin() dans opengl32.dll fait sa job comment au juste ? C'est ça je veux comprendre.

RTFM
 
Sinon imagine qu'aujourd'hui tu peux:
- commander le dessin et les rotations d'un cube, une sphere, un tube, ..., que ce soit en dx ou ogl
- modeliser un cube, et commander la rotation des vertices du cube à une api type ogl ou dx
- modeliser les vertices et les matrices de rotation, et afficher le résultat de tes calculs avec opengl, gdi, gdi+, directx, des caractères qui tracent des lignes dans une console...
 
sinon en c++ on dit "méthode", pas "fonction"
 
pour comprendre opengl : http://www.opengl.org/documentatio [...] /state.pdf

Non. RTFM aussi.

méthode de classe alors peut etre ?

On dit -- pédantiquement, mais j'y tiens -- fonction; que l'on qualifie de membre, virtuelle, statique, amie, etc.

certes, j'aurais dû etre plus précis.

 
A un moment donné tu te sers toujours d'une api. (tu ne peux pas dialoguer directement avec le matériel, tu ne peux dialoguer qu'a travers des api d'abstraction qui te permettent d'être plus ou moins proche du matériel, après justement la subtilité est là).
 
en brut de fonderie, il te faut toujours un moyen d'afficher une image (= une collection de pixels) à l'écran.
donc si tu veux faire un cube qui tourne sans directx, opengl...
 
tu dois prendre ton cerveau et coder une méthode de traçage du cube qui tourne, c'est ton problème pas celui de l'os.
ensuite une fois que tu as l'image sous forme de lot de pixel, tu demandes gentilment à une api de te la coller à l'écran. (le gdi ou directdraw dans ce cas sous windows).
 
avec opengl/d3d, l'api expose une fonction de traçage de triangles et tout est construit a partir de triangles. (opengl expose des quads mais des fois c'est émulé à partir de triangles). la fonction traçe_triangle() d'opengl ou d3d ne traçent pas le triangle avec le cpu dans un buffer image, mais renvoyes les données pertinentes vers la carte vidéo et le traçage est effectué par le chip de la catre vidéo.

ptere que ce qu'il veut savoir c'est si il y a besoin des dlls pour faire tourner le code.
Si tu compiles en statique tout est inclu dans le code de ton application, sinon il faut les libs précompilées (les dlls).
Il me semble
Je sais pas si direct3D permet de le faire.
Je suis pas sur et certain du tout même
Avec opengl c'est l'inverse, je sais pas si il existe des librairie dynamiques opengl. Probablement.

 
ben ... si

dans tous les cas il te faudra te lier avec une bibliothèque de l'api.
 
dans le cas de l'Opengl, tu te lies direct avec la bibliothèque propriètaire du matériel.
dans le cas de DirectX, tu te lies avec les biblothèques de DirectX qui communique avec le driver propriétaire du matériel.
 
ou alors j'ai rien compris a ce que tu voulais mettre en évidence.

bah je pensais qu'avec une appli directx compilé en statique (donc sans dependance avec des dlls) il n'y aurai pas besoin de directX en entier installé sur un pc pour que le binaire créé puisse communiquer avec les drivers de la carte graphique.
 
Et pour opengl pareil.
Si par exemple tu link sur mesa en static bah tu inclue un bout de mesa qui permetrait a ton binaire d'acceder au driver sans mesa d'installé.

je vais essayer de pas dire de conneries mais:
 
OpenGl et le Direct3D sont structurés légèrement différemment:
 
le D3D est fait pour permettre une rétro-compatibilité, sans avoir a faire l'API rétro-compatible (ie D3D9 n'est pas une extension EXPLICITE de D3D8, ni lui même une extension EXPLICITE de D3D7).
 
(je précise explicite pour ce qui arrive par la suite)
 
d'une part ça permet de reconstruire l'API à 0 si besoin est.
 
d'autre part, à l'heure actuelle, donc D3D9, avec un driver de carte 3D D3D9,  c'est microsoft qui fait le pont d'émulation D3D7, D3D8 vers le driver D3D9, le fabricant n'a plus a ce préocuper de la rétrocompatiblité et des cas combinatoires, ainsi que le mélange des paradigmes.
 
Alors qu'en OpenGl tu as un seul driver OpenGl, et les fontions "primitives" OGL 1.1, 1.4, 2.0....  
 
Ce qui fait qu'un driver OpenGl même à l'époque d'un futur l'OpenGl 4.0, il faudra supporter le 1.1, le 1.4, le 2.0....
Le driver sera bloated de cas combinatoires à la con...
Et les architectes de l'API sont pieds & points liés à l'histoire de l'API.
 
C'est pour ça que je précises quand le cas de l'OpenGl, ont est dans le cas d'un système d'extension explicite, obligatoire, non contournable, bref pète-couilles.
 
Si tu prends par exemple D3D10 qui va arriver:
une carte D3D9 n'est pas utilisable (elle expose un driver D3D9)
une carte D3D10 n'expose qu'une interface D3D10
=> si l'application est D3D9 ou 8 ou 7, microsoft se charge du wrapping de l'API 'X' vers le driver D3D10
=> si l'appli est D3D10, alors ça coule tout seul
 
par exemple en D3D10 le paradigme T&L fixe passe à la poubelle: la philosophie générale c'est shaders, shaders, shaders, l'API est épurée un max de l'approche machine à états des versions précédentes.
 
ce qui fait que mettons que tu utilises du T&L fixe dans une appli D3D9:
 
si le driver est D3D9, ça sera directement redirigé vers le driver (qui dans le cas des Radeons émule le T&L par du µcode de shaders, les Geforces ont "encore" un support plus ou moins cablé du T&L fixe).
 
si le driver est D3D10 (carte matériellement D3D10), c'est grosoft  
 
 (ou l'implémenteur du runtime, puisque un jour j'espère, D3D sera autant cross-platform qu'OpenGl, vu qu'il n'y aucunes dépendances techniques à Windows dans le D3D a part 3 pauvres appels pour créer et lier les objets de base a une fenêtre OS comme pour l'OpenGl, qui n'a rien d'ouvert au gus qui passe par là et qui était initialement propriétaire pour ceux qu'il l'auraient oubliés)
 
... qui implémente le wrapping du T&L fixe vers des Shaders. (les fabricants sont délestés de l'émulation, et se focalisent sur le paradigme par Shaders)
 
moralité, ça permet de se focaliser sur l'évolutivité et la maximisation du rendement pour le plus haut niveau de spécificité.

et y a pas moyen de faire un wrapper direct3d vers opengl pour utiliser des programmes direct3d sous linux ?
Il y avait un projet visiblement mais c'est mort : http://sourceforge.net/projects/dxglwrap

Sans trop m'avancer, ca serait sans doutes pas jouable au niveau des perfs.

dans l'absolu oui mais c'est du boulot (pour rien si on était pas dans un monde de merde):
 
si tu prends un driver OpenGl mettons 2.0 pour une carte vidéo machin, l'API et les specs et le hardware sont les mêmes.  
 
un driver OpenGl de Geforce ou radeon machin, devrait donc en principe énormément partager du code entre Windows, Linux, MacOS X.
a part l'aspect "Administratif" avec la gestion des ressources matérielles, des interruptions et tout le bordel (et qui peut être fusionné avec la couche administrative des autres api graphiques, D3D, GDI, Serveur X), l'aspect générations d'états et de µcode internes au GPU est conservé.
 
de la même manière je pense qu'il est 10 milles fois plus simple de porter le D3D même sous Linux, MacOs X, je veux dire c'est pareil: passé les spécificités administratives de chaque OS, le driver D3D9/10 a les mêmes raisons que l'OpenGl pour conserver son code et ses techniques de préparations de données au GPU.
 
maintenant pour Grosoft, lâcher la laisse sur la poule aux oeufs d'or qu'est le D3D (qui est pour moi la meilleure techno qu'ils aient pu pondre vu qu'ils ont réussi a faire un truc réellement interressant et bien chié techniquement) leur fait peut être mal aux c**.
 
mais c'est vrai que ce serait tellement mieux pour tout le monde qui veut faire du D3D, de pouvoir le faire partout, et pas seulement sur les platformes qui "valent le coup économiquement", parceque il n'y a pas de restriction intrinsèque dans l'API pour faire "que" du Windows.
 
Mais bon là je pense que le temps fera son office, et peut être qu'avec les pressions que Microsoft subit, ça se fera.
 
(perso je trouves les attaques faites contre Microsoft en ce moment en total décalage avec ce qu'il faudrait les pousser a faire: mais apparement c'est plus facile d'appuyer sur le bouton pour coller des amendes débiles que de permettre clairement a quiqonque de réimplémenter les idées des autres sans pour autant piquer l'implémentation de l'autre, enfin je me comprends)

 
ça crées un overhead si jamais ça marche, mais bon dans certains profils d'utilisation, l'overhead peut se retrouver masqué....

l'overhead créé serait sans doute négligeable par rapport au temps que la carte graphique prend pour faire les calculs.
 
l'overhead aurait lieu sur les intialisations et appels des primitives de l'api opengl par les fonctions direct3D.
 
Enfin c'est comme ça que je le verrai

disons qu'il peut être clairement masqué, mais pareil ça impactes le rendement sur les petits batchs.... hors actuellement la chasse aux overheads est ouverte (donc vaut mieux pas faire dépasser la tête du mur )

en fait pour être plus précis, c'est d'avoir une correspondance presque 1<=>1 entre les primitives d'API D3D et les primitives OpenGL.
(ça doit être jouable entre D3D9 et OpenGl 2.0 + extensions propriétaires)
 
que t'es pas a mouliner un VB/IB D3D pour repacker vers l'équivalent en OpenGl (ça tuerai les perfs dans tout ce qui est géométrie procédurale, moteur de particules...)
et que les P/V Shaders D3D puissent être facilement retranscrits en Shaders OpenGl.
 
bon clairement c'est du boulot, pour ça faut des mecs qui connaissent bien à la fois D3D et OpenGl.

(je crois que realtech avait commencé un wrapper d3d non ?)
 
ouais:
http://www.realtech-vr.com/directx/index.html

ouais mais c'est mort

en même temps c'est normal. il faudrait plus un mouvement pour porter réellement le D3D, mais sans l'appui des fabricants la viabilité fait plouf.

C'est sur que le cadet des soucis c'est plutot les drivers proprios à la con.

oui & non, mais c'est surtout que tu peux tenter de porter D3D sur d'autres OS a partir des spécifs visibles depuis le SDK et le DDK, mais avoir un résultat de qualité il faut le concourt des fabricants.
l'ouverture du code des drivers changera pas grand chose vu la complexité de la tache.
l'ouverture et la discussion sur comment implémenter au mieux l'intégration du driver à l'OS oué, mais le contenu du driver lui-même, j'ai des doutes sur les capacités d'une communauté même motivée, a part aller chez ATI & nVidia se faire former sur leur GPUs .
 
enfin c'est compliqué.