Gallium 3D
-
Je vois qu’on parle de gallium sur un autre fil, mais comme c’est un sujet intéressant et que je m’aperçois que personne n’a compris de quoi il est question, j’en fait un fil à part:
Si on pense que gallium n’est juste “qu’un nouveau driver 3D OpenGL opensource”, ça offre pas une image exacte.
Les GPU qui permettent de faire des shaders existent depuis 2002, et OpenGL2.0 qui permet de faire des shaders avec le language GLSL à été rendu public vers 2004/2005 pour les premières versions.
Il faut comprendre que:
– Du temps d’OpenGL1.x le pipeline de rendu était fixe, et les algos de dessin des polygones étaient cablés de façon configurable mais statique en hardware, DONC: faire un driver par reverse-engeneering était possible dans la mesure ou pour un constructeur donné les adresses GPU variaient pas trop
– Sur des GPU fait pour du OpenGL2/et shaders, le GPU n’est plus fait à priori pour dessiner de la 3D: c’est juste des arrays de CPU parallélisé spécialisés dans le calcul flottant et le travail en parallèle: les drivers GL2 font alors 2 choses, complétement différente de ce que faisait un driver GL1:
* compiler le code des shaders GLSL vers un assembleur GPU
( ces compilations se font dans les inits d’un moteur 3D)
* propager les shaders aux différentes unités du GPU pour dessiner un polygone.
… Mais on peut utiliser les Units GPU pour n’importe quoi d’autre que du graphique.
Donc un driver OpenGL2 n’a rien à voir avec un driver OpenGL1 , et est beaucoup plus lourd à gérer ( c’est plus proche qu’un compilateur C pour partie, et un compilateur FPGA pour une autre ! )
… Donc voir un jour un driver OpenGL 2 par reverse engeneering, ça tenait de l’impossible, seul Gallium répond à cette problématique de façon élégante:
Sur le principe, gallium est une putain de *REVOLUTION*
dans l’informatique en général, Pas pour l’amiga ni pour linux; (en plus Il n’est pas final du tout à l’heure actuelle sous linux), mais c’est de la balle pour son architecture et le fait qu’il abstrait la gestion des GPU units: Un genre de nvidia/optimus GPL plus qu’autre chose.
Gallium est pas un driver “GL”, c’est juste un driver qui normalise la gestion des GPU Units quelque soit la carte, et qui permet de normaliser une bonne fois pour toute *UN SEUL* driver GL, branché sur gallium et pas sur du hardware. Ca correspond à la réalité des GPU d’aujourd’hui. Et quoi d’autre peut-on brancher sur gallium ? OpenVG, OpenCL , etc. … cerise sur le gâteau pour les hackers: attaquer direct la couche gallium pour du GPGPU. (general purpose GPU)
Du coup , des gens qui veulent une API de gestions générale d’units de calculs massifs parrallèle lorgnent sur gallium:
pas étonnant il existe un port gallium du cell de la PS3 http://www.mesa3d.org/cell.html – ( la ps3 est connues pour n’avoir jamais eu d’API 3D potable dans ses SDK ) (autre note: wine prévoit un driver Direct3D <=> gallium, sans passer par GL ! )
On est qu’au début de gallium, mais ça va dépoter bien!
C’est ce que je pense aussi pour l’instant c’est juste le manque d’optimisations certain qui manque a gallium
L’autre truc à savoir , et ça fait partie des specs d’OpenGL 2.x:
Un driver OpenGL2.x est sencé exécuter un shader, dés que sa syntaxe est valide: ensuite il est exécuté par “la partie hardware qui peut l’exécuter”, mais on n’a pas le droit de ne pas l’exécuter !
Donc un rendu OpenGL2 basculera en software CPU:
– si une des instructions (une seule!) utilisé en shader n’est pas exécutable en hard sur le GPU
– si le cache de programme des GPU units est trop court.
… et dans le pire des cas, un driver OpengL2 gallium doit pouvoir s’exécuter en intégralité en CPU ! donc dans le cas d’un GMA intel, c’est le massacre, mais c’est vrai aussi sous windows.
C’est aussi vrai en WebGL ces trucs là (webgl=en gros OpenGL2.2, on peut faire du GLSL en javascript !)
(edit)… donc c’est pas des questions “d’optimisations qui manque à gallium”.. c’est plutôt l’état d’avancement du support de telle instruction GPU, et des fallbacks en CPU, (qui de toute façon sont inévitables avec des trucs comme GMA qui supporte même pas GL2.x).
Merci de ces eclaircissements un peu comme sous dx9 ou des parties sont exexutees en soft avec le gma
@krabob: perso, j’ai rien compris mais je pense que gallium 3D est une bonne alternative pour AOS et AROS, le seul truc qui me déplait (et la je chipote) c’est que c’est pas une bande d’amigaïstes qui ont créer leur propre “système 3D”.
Bref, pour moi, j’espère qu’il y aura de l’optimisation, pas envie de tomber dans du générique, sa me fais un peux chier cette solution de je veux être compatible avec tous donc je tape moins dans le hard.
Edit: imagine un truc tellement optimiser que Doom 3 tournerait à 50Fps sur 460 par exemple
Re Edit: Mon edit est une image, je dis pas que la 460 puisse faire tourner doom3…
Tient je fais encore des posts car le sujet me passionne:
perso, j’ai rien compris
Ben… je reprends alors: en OpenGL1.x, tout les moteurs 3D dessinent de la même façon: tout est statique: on peut juste faire du texture mapping, du goureau, faire plusieurs couches de texture mapping à la limite et puis c’est tout. C’est nul en plus, parce que ça ne sait faire que des “interpolations” sur des polygones: des dégradé de couleur, etc,… par exmple en OpenGL1.x, les calculs d’éclairage ne peuvent être fait que sur les points (vertex), puis interpolées. Si tu veux faire un rendu un peu plus technique en Opengl1.x tu vas essayer des “extensions” opengl moches qui chacune présente des options disponibles ou pas selon la carte, ce qui est chiant.
En Opengl2.x, c’est le programmeur qui décide exactement ce qui se passe exactement quand le polygone est dessiné, et comment sont fait les calculs dans le GPU: avec les shaders, qui sont des petites fonctions écrites dans un language proche du C, et qui donc, doivent être compilés par le driver avant chaque exécution.
et là c’est du vrai bonheur, parce que les GPU peuvent bosser de manière beaucoup plus puissante et souple qu’avec un CPU. (quand on prends conscience de tout ce qu’on peut faire avec ça, programmer un cpu fait rigoler.) C’est comme si on avait 256 altivecs, mais qu’en plus ils pouvaient lire plusieurs gros flux de mémoires video à fond la caisse, tout en faisant les pires calculs arithmétique, trigonométriques, des fonctions exponentielles à qui mieux mieux, le tout à fond en précision double.
En OpenGL2.x, on interpole plus rien: on peut (on doit!) refaire les raytracing complet par pixel, renormaliser les vecteurs autant qu’on veut, pas de problème. Le codeur qui a jamais fait de shaders, il perd une expérience unique dans sa vie.
le seul truc qui me déplait (et la je chipote) c’est que c’est pas une bande d’amigaïstes qui ont créée leur propre “système 3D”.
Avoir un driver 3D OpenGL1.x fonctionnel sur amiga, sans source ou aide à la base, est déjà une gageure,
Mais quand on doit compiler les sources des shaders et les monter dans le GPU, même si ça devait être fait juste pour un modèle de GPU ce serait un bordel monstrueux.
Là on est plus dans le “je bricole dans mon garage” (comme on pouvait l’être en gl1.x), et pour tout dire on est pas non plus dans le “je suis une grande firme informatique et je fais tout avancer à moi tout seul”. L’architecture “shaders” a été inventé pour les premiers logiciels de synthèse interne de pixar dans les années 80, toutes les boites de GPU (pas seulement ati et nv) et les universités ont apporté leurs pierres au début des années 2000 pour introduire ça de manière souple dans le hardware (le but étant d’en finir une fois pour toute avec les extensions stupides en gl1.x ) et donc Khronos, qui est le conçortium qui gère les specs GL depuis ces années là, spécifie ce qui est OpenGL ou pas en mettant tout le monde d’accord. Si ça avait été bricolé par une firme privé, là ça aurait été pourri ! (exemple excellent de coordination anarchiste , d’ailleurs.)
La seule chose qui manque, c’était justement de quoi rendre plus “opensource” le fait d’avoir un pont entre l’implémentation hardware et les drivers, et gallium apporte ça.
ça me fais un peux chier cette solution de je veux être compatible avec tous donc je tape moins dans le hard.
On est pas forcément plus puissant parce “qu’on tape dans le hard”. Il faut des API bien faites pour les coder pareil, et c’est le rôle d’un driver de taper comme il faut dans “tout les hards”.
Quand on code du OpenGL (1 ou 2), le CPU n’est pas sencé faire grand chose à part configurer le GPU. Puis on lance les masses de calculs en une seule instruction ! Difficile de faire mieux comme rapport (efficacité)/(effort)
imagine un truc tellement optimiser que Doom 3 tournerait à 50Fps sur 460 par exemple
Re Edit: Mon edit est une image, je dis pas que la 460 puisse faire tourner doom3…
J’imagine que du point de vue “gamer”, tout ce qui interesse c’est les “fps”, et que peus voient l’intérêt d’avoir du GL2 à la place du GL1… mais pour moi c’est comme si un type demandait un vélo de course à la place d’un moto cross… alors que pour le même prix il pourrait avoir une F1. (une F1 qui consommerait la même énergie que son vélo, avec la vitesse d’une F1.)
Le truc que je pige pas, normalement le CPU est le moteur d’un ordi, donc, c’est lui qui devrait être le plus puissant? non?
toutes les infos passent pas obligatoirement par le CPU?
En gros, rien à faire du CPU, se qui faut c’est un gros GPU, j’ai bien compris?
Pourquoi me demander ça ? Je n’ai que faire de l’OpenGL et Gallium en particulier, ce n’est pas du tout mon terrain.
Mais lorsqu’on aura envie d’avoir des pilotes 3D supralents, alors oui, on pensera en premier lieu à Gallium3D, c’est certain, il est le mieux placé pour ça.
Un CPU, c’est bien parce que c’est “itératif”, ça fait une chose après l’autre, donc ça se programme facilement, avec un langage fait pour l’itératif: en C par exemple. Mais c’est la limite du truc: par exemple si les 68060 et pentium sont beaucoup plus rapide que leurs prédécesseurs, c’est parce qu’ils réussissent à parralléliser certains calculs.
Un GPU, ça fait du calcul “parallèle”, pour la 3D ça sert à travailler sur plein de pixels à la fois, mais du coup, il a fallu inventer de nouvelles façon de programmer pour en tirer parti.(shaders, puis compilateurs exprès pour le calcul partagé comme OpenCL, Cuda)
Donc le CPU sert de “chef d’orchestre” au GPU. Et de mon point de vue, ouai c’est has been coté mips.
Ces dernières années, avec les intel quadcore et autres cells (ps3: 9core), on se retrouve avec pleins d’unités CPU et GPU et il faut les faire travailler ensemble, d’ou encore, l’utilitée de ces langages qui sont fait pour répartir les tâches et les calculs.
@artblink
Il suffit de lire les nombreux benchmarks, où gallium se fait battre de façon non négligeable par toutes les autres solutions sous linux (qui ne sont déjà pas bien glorieuses, comparé à windows ou osx).
Le projet en lui-même, c’est super, mais l’utilisateur final sous linux préfèrera des drivers proprios qui permettent de jouer convenablement (sauf les extrêmistes de l’opensource, bien évidemment ). Bref, donnons encore quelques décennies à Gallium et peut être que le résultat sera satisfaisant.
(et entre parenthèses, les abstractions destinées à uniformiser tout, c’est sympa, comme concept, mais ça a ses limites, quand c’est fait avec les pieds).
Je viens de lire quelques docs gallium sur le net:
donc d’autre part:
– Si Pas de gallium, difficile ( sinon impossible) d’avoir et de maintenir de l’opengl 2 (ou plus). Ca c’est le mur du son de toute façon sur amiga.
– Avec Gallium, le travail nécessaire à la création d’un driver pour un GPU donné est minimal, et davantage portable d’une plateforme à l’autre.
– Ah oui ça gère les drivers 2D aussi (tant qu’on y est !)
– Pas de gallium, pas d’OpenVG, pas d’OpenCL, lesquels sont gratos puisqu’ils sont cotés gallium, en plus de l’OpenGL2.
– Pour l’instant les versions publiques sont des gallium 0.4: je viens d’installer une mint debian, c’est ce qui est installé à défaut comme glx sur un de mes portable avec ATI XPress R300. Mais il le met en GL1.4 alors que le R300 peut faire du GL2.2 … donc héhé: on est d’accord, c’est pas final, mais pour un projet encore jeune c’est pas mal. ( un système qui intégre gallium devrait se retrouver à suivre les linux de près, coté driver. )
Un slide de conférence d’un gars:
http://www.slideshare.net/olvaffe/gallium3d-mesas-new-driver-model
… par ailleurs on peut tout à fait imaginer des ports propriétaires de drivers gallium, ce qui sera plus facile à réaliser qu’un port GL2 complet.
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Développement › Gallium 3D