Markov a écrit 95 commentaires

Juste une question, si je comprends bien tu demandes aux gens de lancer un scripts qui fait des query (lspci & autres) pour avoir une liste du matos est des modules qui les geres. Mais si le module est proprio, par exemple fglrx, alors qu'une solution libre existe (jusqu'au r400 pour le moment) ton site ne donnera pas cette information non ?

PS: Comme j'en ai marre de m'inscrire sur 150000sites je me suis pas inscrit sur le tien alors peut etre que j'aurai pu trouver la reponse par moi meme.

Je n'irait peut etre pas jusqu'a parler de refonte mais beaucoup de chose changes, Principalement grace a intel qui a mis des sous pour bouger les choses (employer des devs...). Dans tous les cas les prochains mois vont etre charger en ce qui concerne l'actualite graphique sous les plateformes libre. J'espere que d'autre projet comme openbsd se lanceront a porter DRM dans leur noyau pour pouvoir profiter de tout ca.

L'annonce de mesa n'est peut être pas claire mais les VBO était deja supporte au paravent. La nouveauté c'est que l'ensemble de l'architecture interne de mesa utilise maintenant les VBO en lieux et place d'une structure de donne qui était propre a mesa. Cela va permettre de simplifier les drivers des cartes en n'ayant plus qu'une seul et unique interface pour recevoir les vertex.

Je t'invite a consulter les premières version de direct3d et a compare avec le protocole opengl, les similarités sont nombreuse, directx a depuis évolué et suivi une voie un peu différentes mais il reste encore de tres nombreuses similarités même s'il reste vrai que techniquement parlant les deux api n'ont rien de similaire mais il s'agit plus de la facon de présenter que des fondements. C'est d'ailleurs pourquoi wine arrive a convertir les appels direct3d en appel opengl assez facilement.

Mesa ne peut etre competitif avec une acceleration materiel meme avec les cpus actuelle. Seul, peut être, les processeurs cell peuvent rendre utilisable cette approche logiciel. Il y a plusieurs raison a cela :

- Les cartes graphiques sont capables de traiter plusieurs pixels en même temps avec des opérations complexes et particulière (typiquement des groupes de 64 ou 128 pixels, nvidia allez jusqu'a 1024 me semble t-il mais ce n'étaient pas un bon choix) un CPU lui ne pourra pas traiter autant de pixel aussi efficacement même avec les instructions "multimedia". En effet l'agencement mémoire sur la carte graphique et l'architecture autour permet d'optimiser les access sur ces groupes de pixels alors que pour le cpu le plus souvent on a des cache miss et on ne peut avoir une organisation aussi sioux que pour le gpu.

- Les cpu ne sont pas tres efficaces pour des opérations comme le blending de pixel a moins de faire des routines tres optimisées.

- Mesa ne cherche pas a optimiser aux maximums son rendue software principalement car c'est irréaliste. En effet il faudrait écrire en asm chaque combinaison possible de rendu et il y en a plusieurs milliers voir une infinité si l'on considère les vertex et pixel shader. Donc mesa s'intéresse plus a avoir une pipeline software la plus proche des spécifications opengl (je crois que certains professionnel se sert du rendu de mesa comme référence).

- Enfin le rendu dans les résolutions actuelle demande de deplace des dizaines de mega octect de mémoire a chaque frame et l'architecture de nos machines n'est pas la plus optimise pour ca.


Voila pourquoi mesa ne représente pas une solution fonctionnel pour le rendu en software de bureau 3d. Mais mesa est utilisées par tout les pilotes 3d graphiques libre sous linux; effectivement rare sont les cartes qui implémentent l'ensemble d'opengl aussi beaucoup de fonction de l'opengl sont laisse a la charge de mesa.

Mesa est aussi utilise pour tester des idées en software de protocole ou extension opengl qui pourrait être utile. Il est aussi probablement utilise dans plusieurs application professionnel qui ne peuvent se contenter du rendu des cartes graphiques. Bref je ne pense pas que l'on puisse facilement dresser une liste exhaustive de ses utilisations. Mais il reste un composant clef de l'accélération matériel sous linux ou netbsd, il s'agit tout simplement du centre névralgique par ou tout passe pour l'opengl. C'est pourquoi chaque amélioration qu'il subit a de grande chance d'améliorer les drivers libres de manière indirect.

Et le but de ce projet c'est simplement de proposer une implémentation d'opengl en software la plus conforme possible ainsi que de fournir une infrastructure pour l'accélération matériel d'opengl. A ma connaissance c'est la seul implémentation aussi complète d'opengl en software, il s'agit vraiment d'un travail énorme.

Fork le mot est peut etre excessif mais si tu regarde la premiere version ca ressemble beaucoup a opengl avec des classes et l'horrible notation polonaise en plus.

Sur quel plate forme as tu fait de l'opengl 2.0 ? Attention GL 2.0 est compatible avec 1.5 ou avant donc tu peux très bien faire plein de truc sans vraiment utiliser une fonction particulière/propre a GL 2.0/2.1.

Si tu fais un glxinfo tu verra la version du protocole GLX (ca doit etre 1.2 pour tout les linux d'aujourd'hui sauf peut être avec les drivers nvidia). Le protocole GLX fait le liens entre OpenGL et le protocole X donc GLX n'est utile et n'a de sens que sous un système X window, et ce protocole définis qu'elle version d'opengl est supporte(voir le lien que j'ai donné).

Enfin je serais pas étonné que les fonctions GL 2.0 soient tout de même exposées sous le protocole GLX 1.2 ou 1.3. Ce qui ne serait pas conforme au protocole mais par exemple l'extension EXT_TFP nécessaire a compiz sous AIGLX est expose avec glx 1.2 alors qu'elle requiert au moins le 1.3 ou 1.4 (enfin c'est un micmac du genre).

Il me semble aussi qu'il manque un nouveau glx pour vraiment en tirer parti (voir tableau 6.1 page 49 dans le document suivant):

http://www.opengl.org/documentation/specs/glx/glx1.4.pdf

Donc pour le moment on doit avoir l'interface opengl 2.0 disponible uniquement si on link directement avec mesa dc sans acceleration ou affichage sous X.

Bienvenue dans le subtile monde des protocoles graphiques :)

Les erreurs supplementaire sont la pour noyer le poisson dans l'air :)

Non, compresser puis décompresser le framebuffer ou des fenêtres en software ne ferait que rajouter des calculs aux processeurs et donc ralentir l'ensemble. Si aujourd'hui tu ne peux avoir d'effet comme ceux de beryl ou compiz avec vesa, il y a peut de change que tu puisse en avoir demain. La seul solution est d'écrire des routines de rasterisation optimise pour ton processeurs et encore je pense que tu ne pourrais pas dépasser le 1024x768 sans voir les performances s'écrouler. Enfin je ne pense pas que mesa s'intéresse énormément a écrire les routines de rasterisation les plus optimisée possible, il s'intéresse surtout a la qualité du rendu pour ce qui concerne le rendu en software.

D'autre projet comme enlightenment pourrait éventuellement apporter ce genre d'effet en software, ils semblent s'intéresser bcp plus au rendu software qu'a tirer partit de l'accélération matériel.

Le problème c'est que visiblement peut de personnes semblent attiré pour bosser sur les drivers radeon (le driver r300 étant de plus probablement un mauvais exemple de driver tant il reste plein de hack pas beaux tout partout) et comme les développeurs existant on peut de temps tout avance lentement aux grées de leur temps libre.

Enfin pour les radeons X1K je crois pouvoir dire que d'ici peu un driver libre fera son apparition, attention probablement aucune acceleration simplement la gestion des changements de modes, pour l'acceleration il faudra attendre que les différences avec les r300 & r400 soit isoler afin de pouvoir se servir du moteur 3d.

Je crois pas que tu trouvera des informations sur des sites ou des blogs, les dev restent en général discret car ils savent jamais quand il vont trouver une heure pour finir le point de détail qui manque avant de publier le boussin. Mais en restant sur irc tu peux récupérer des brides conversations sur le sujet :)

Le driver r300 supporte ta radeon9800 pro, tu as probablement un distribution un peu vieillotte ou alors tu as un problème de dépendance.

Difficile de repondra a ta question sans description precise. De plus quand Xorg sort cela ne veut plus necessairement dire que les drivers videos sont aussi update. Enfin dans la chaine d'affichage graphique il n'y pas que le driver DDX d'xorg qui gere la carte mais aussi le module DRM (kernel), le DRI et Mesa bref tout ca fait qu'il peut y avoir plusieurs sources a tes problemes.

Une description plus precises aiderait, sinon cherche sur le bugzilla de freedesktop.

Effectivement selon cette definition ce n'est pas multi-coeur, mais les multiple unites de traitement que l'on trouve dans la ge8800 (ou la X3000) me semble presque autonome, il parge le bus memoire et certains autres fonctions mais ils sont tous capable de realiser les
memes operations. Probablement le terme multi unites seraient plus appropries.

Dans tous les cas je ne pense qu'Intel est l'intention de demander a tout le monde de changer de type de rendu. Meme si les nouvelles architectures comme la ge8800 doivent certainement pouvoir accelerer aussi le rendu en raytracing.

http://graphics.stanford.edu/papers/i3dkdtree/

Je doute que cela soit optimisee pour le raytracing, de plus les applications actuelles se pretent tres bien aux multi-coeur. NVidia avec sa 8800 le prouve, c'est un chipset avec plusieurs coeurs. D'ailleurs, les primitives des rasterizer actuelles se prettent bien a une repartion sur plusieurs coeurs (traitement de plusieurs primitives en parallele).

Mon avis est donc que cela serat simplement comme la derniere generation de carte graphique (NVidia 8800, Intel GMA X3000, ATI R600) des unitees de calculs tres puissantes (un peux comme SSE, altivec ou consor) avec des fonctionnalites plus specifiques a la rasterization. Naturellement tout ca optimisee, avec des frequences de fonctionement ahurissante :)

De plus la convergence du GPU et CPU supporte cette hypothese. Quand tu regardes le dernier GMA X3000 tu as l'impression de programmer des unitees altivec.

Enfin avec les GPU actuel tu peux faire des rendues de type radiosity. Je pense donc que l'architecture actuelle n'a aucune raison de changer fondamentalement.

http://dee.cz/rrb/

Je fais reference ici a tous ce qui a publiquement filtre a propos de direct x10; developpe en liens etroit avec ATI & NVidia mais plus particulierement avec ATI car celui-ci fournit le chipset graphique de la xbox360 (c'est ce genre de relation commercial qui vous cree d'un coup des amities de 30ans ;)).

D'apres la petite analyse des drivers Vista (qui fait l'objet d'une autre news) il y a peux, mais alors vraiment peux, de chances de voir ATI/AMD ouvrir son driver; surtout quand on connait les liens etroits entre ATI & Microsoft. Je pense qu'AMD a laisse courir un bruit sur l'ouverture des drivers car ce ne pouvais que leur etre favorable (qu'elle compagnie cracherait sur de la publicite gratuite).

Je crains fort que seul des efforts de reverse engineering puissent changer la donne; a moins que NVidia et AMD finissent par en avoir marre du model Vista (pour de "basse" raisons financieres) et lachent microsoft. Mais je suis de nature pessimiste et je vais relire 1984 du bon vieux George afin de me preparer pour le monde de demain.

Toutes les radeons jusqu'aux X850 sont supportees. Prochainement les nvidia avec nouveau :).

Il me semble important de le rappeler :
http://perso.orange.fr/patrice.mandin/images/nv-kitten.jpg

Je crois que tu connais tres mal OpenGL. OpenGL propose des extension, parmis les extension il y a les extensions proprietaire mais aussi les extensions ARB qui sont normalise et donc que touts les constructeurs peuvent supporter.

Ensuite OpenGL supporte l'equivalent des shader 3 depuis openl 1.3 avec les extensions ARB. Pour le model 4, il serait supporte d'office avec opengl 2.0 ou 2.1. De plus il est bcp plus facile pour un constructeur de proposer une technologie innovante avec opengl car il peut faire sa propre extension. Avec DX il est oblige d'attendre que MS veuille bien faire quelque chose.

Je te conseil de te renseigner plus en avant sur opengl avant de le denigrer. Enfin OpenGL c'est le seul API vraiment professionnel.

NVidia fournis ce driver libre et est responsable de sa maintenance d'ailleur personne à part NVidia ne fait des modifications sur ce driver. De plus les sources sont complétement illisible, il semble que nvidia travail sur son driver en interne puis le passe a travers un programme afin de rendre le code "illisible" avant de le fournir.

Croit tu vraiment que personne n'essaie de convaincre ATI ou NVidia de coopérer ? Certain travail de lobbying se font mieux sans en parler à tout le monde, surtout quand ca porte pas ces fruits :)

Et ben tu n'as pas de chance de devoir être à la pointe de la technologie ;) mais pour le driver libre nv c'est de la faute de nvidia qui bride intentionnellement le driver libre.

Pour les radeon < X850 et la sortie tv n'est pas encore totalement opérationnel cela est principalement du l'histoire un peu étrange des drivers radeon sous xorg mais dans la version git du driver cette fonction est plus ou disponible (en cour de development donc peut marcher ou pas en fonction de la carte).

Pour les ATI >= X1300 ATI n'a rien fournis comme information et donc la seul solution pour evite le proprio c'est vesa ce qui n'est pas très excitant...

Ce qui me semble surtout important c'est de ne pas dénigrer Xorg et leur effort sur les drivers car les volontaires qui travaille dessus le font sans avoir les spécifications et doivent effectuer du reverse engineering. Alors cracher sur leur driver sans prendre en compte l'enorme travail déjà accomplis me semble manquer de respect en vers eux.

Ensuite si tout le monde commence à accepter des drivers propriétaire alors on finira par avoir un système d'exploitation plus du tout libre. Car le but d'un système d'exploitation libre c'est (du moin pour moi) d'avoir le controlle de sa machine et donc des périphérique qui y sont ratacher et de pouvoir comprendre ce qui s'y passe.

Dc aujourd'hui la carte graphique, demain la carte son, après demain la carte réseau, puis la carte mère puis le reste et le noyau se retrouve alors comme un chef d'orchestre qui n'est pas la moindre idée de ses musiciens ni de comment les faire interagir...

Je ne sais pas de qu'elle carte il s'agit mais toutes les radeons jusqu'aux X850 sont tres bien supportees pour la 2d et tu peux allegrement depasser le 1600x1200 si tu en as envie. Il en va de meme avec intel mais eux il n'ont pas de driver proprio que du libre. Pour nvidia le driver libre est fournis par nvidia et est complement opaque, il est de plus bride afin de pousser les gens a utiliser le driver proprio.

Oui il font des radeons en PCI-E toutes les cartes des X300 aux X850 sont supportees aussi bien pour la 2D que pour la 3D (le driver 3D est en constente amelioration et est issue du reverse engineering).

Les firmware ont longtemps poses aucuns probleme au libre. Mais aujourd'hui les constructeurs mettent de plus en plus de chose dedans, si bien qu'on finit par perdre le controle du materiel pour le donner au firmware dc oui eviter les firmware proprietaire me semble justifier.

D'apres ce que disais les developeurs d'Xorg a l'epoque, XGI n'a jamais rien fournis en libre a part le driver 2D. Donc non je ne pense pas qu'XGI supporte le libre. Pour le moment seul intel le fait.

Au passage un bench du GMA X3000 d'intel:
http://www.phoronix.com/scan.php?page=article&item=571&a(...)