Alors le peuple aurait du payer la facture parceque des dirigeants de banques ont pris des risques demesures ? Donc en gros selon toi on privatise les profits et on fait payer aux peuples les pertes. Je trouve que le peuple d'islande a eu raison de dire non, de ne pas vouloir payer les fautes d'un petit groupe.
Je suis d'accord que la situation en Grece est differente mais il n'empeche qu'un referendum en Grece avait de la legitimite. D'autant plus qu'en Grece c'est principalement l'argent de banque qui est en cause et qu'au finale aujourd'hui en pratique la Grece ne remboursera qu'une partie de sa dette (pour les optimistes).
Qu'est ce qui est extremiste ? Une societe dans laquelle certains gagnent des centaines de fois plus que des personnes qui travaillent ? Ou une societe qui prone un juste salaire et une juste distribution des richesses.
Et sincerement avec 30000euros par moi tu peux t'acheter un gros appartement, une grosse voiture, manger dans des bon restaurant tous les jours, bref vivre tres bien selon les criteres consumeristes. A quoi te servirons des milliers d'euros de plus ? Acheter un jet ? Un gros yatch ?
C'est fallacieux de dire que si le peuple Grec avait repondu non il n'y avait pas d'autre solution. D'autre solution existe toujours, ici en l'occurence aucun politique ne voulait se donner la peine de reflechir a une autre solution.
Je te conseille de lire le monde diplomatique pour avoir un large pannel d'autre solutions possibles. Ou encore http://www.naomiklein.org/shock-doctrine pour te rendre compte de l'utilisation horrible qui est faite de cette crise economique.
Je ne dis pas que tous les referendums sont bon, pour moi la qualite d'un referendum depend de son libelle. Dans le cas evoque je trouve que le libelle : Rembourser la dette ? (oui | non) est tout ce qu'il y a de plus democratique.
Encore une fois faut etre realiste, les mach64 ne permettent certainement de pas d'avoir compiz avec 2M de video ram … 8 pour le top end des mach64. Leur taille de texture limite … Donc non les mach64 en 3d ca ne sert a rien. Les r100 par contre oui peuve supporte compiz et les r100 sont toujours supporte par le driver open source. Pour les intel 840 c'est une decision d'intel et comme dans la communaute seul intel fait du support pour leur gpu et bien le driver pour 840 est partie dans les oubliettes mais ca n'empeche personne de le resussite les sources sont la.
Il faut comprendre que sur les GPU ont en sous effectif chronique et que sincerement on pas le temps de s'embete de GPU vieux de plus de 20ans (les mach sont sortie en 1990-92).
Les intel 840 sont plus recent 1998/99, mais bon c'est pas de tout derniere fraicheur non plus.
Donc arrete de dire qu'on demande un GPU de moins de 6mois, on demande un GPU de moins de 10ans. C'est vraiment pas grand chose.
A oui ca c'est sur que c'est des GPU qui depote, sincerement deja les r100 c'est juste bon pour quake1/quake2, les mach a peine utile pour quake1. A un moment faut etre realiste …
Alors la merci de me donner un pointeur parceque non le pilote libre pour les GPU radeon n'est pas abandonne. Ce pilote (plusieurs si on va dans les details) support des radeon r100 (radeon 9000) au derniere HD6xxx et bientot HD7xxx.
Le probleme viens principalement du fait que ttm/gem a de gros besoins sur comment marche le memory management du noyau linux a des api pour tous ces trucs. La derniere fois que j'ai regarde un noyau bsd (5 ou 6 ans maintenant). Il y avait presque rien c'etait vraiment pas concu pour marcher comme on le veut. Bref il semblait necessaire de devoir d'abord travailler sur le corps du noyau bsd avant de pouvoir implementer un des memory manager. Mais je pense que le travail qui a ete realise pour avoir les driver nvidia a probablement bcp change les choses.
Tu utilise un truc comme llvmpipe (opengl avec CPU). Ou alors tu fais ton propre truc de rendu software mais la ton probleme ca sera les clients wayland, car c'est eux qui font le rendu de leur fenetre. Donc il faudra aussi que tu portes les toolkit pour qu'il marche en GL ou avec autre chose.
GL c'est le denominateur commun choisi implicitement parceque tout les platformes de ces 5 dernieres annees le supportent.
On peut jouer a ce jeux longtemps ;) Moi j'aime bien jouer :)
Ecrire des specifications comme par exemple celle d'opengl ou du c99 pour TTM/GEM/KMS ... n'a aucun sens. Fondamentalement le coeur de TTM/GEM/KMS n'a pas cesse de changer. Mais l'interface expose est toujours la meme. Un simple uint32_t (et voila je peux meme plus faire le feignant et utiliser u32) qui identifier de maniere unique un buffer pour TTM/GEM et un moyen de mmap a partir de cette uint32_t. C'est tout ce que demande l'userspace.
Sincerement je crois que tu as passe trop de temps a faire du management de projet et autre truc .... (je me censure).
Par ailleur je tiens a preciser que tout le code TTM/GEM/KMS est double license GPL/BSD. Donc oui vous pouvez regarder le code et meme le copier.
Vraiment demander une doc c'est de la mauvaise foi. C'est pas dure a comprendre tous ce code. Le probleme c'est que le memory management des *BSD est different et qu'il faut une personne qui comprenne le code gerant la memoire dans le noyau *BSD (a propos elle est ou la doc pour ca ?)
Faut pas avoir peur de la taille du code des drivers GPU. Le modesetting prend bcp de
place et c'est pas complique.
Je soutiens qu'une personne capable d'ecrire un driver GPU n'aura aucun mal a porter vers un BSD et qu'aucune documentation au monde ne servira. Vraiment ecrire la doc prendrer plus de temps que d'ecrire le code.
L'idée c'est d'utiliser EGL & GLES2. EGL c'est un API standard pour pouvoir créer des contexts OpenGL ou OpenVG ou autre (rien d'autre dans le standard pour le moment). Donc tu écris ton compositeur wayland avec EGL, tu crées un context opengl (wayland encourage d'utiliser GLES2 parceque c'est en gros opengl 2.0 - opengl 1.0 et que ca correspond as ce que supporte tous les GPU embedded).
Et voila c'est exactement comme les compositeur actuel. Tu fais de l'opengl, et les bugs GPU bah c'est des bugs du driver GL.
Bon je simplifie un peux parceque tu as aussi besoin de faire le modesetting mais ca y a deja des librairies pour utiliser KMS et faire le boulot a ta place. Ou tu peux copier le code de weston.
La vérité c'est que la partie modesetting & creation de context ca doit être 1000lignes de code en plus par rapport a un compositeur X. C'est pas grand chose et c'est standard si tu utilises EGL et KMS (KMS linux only pour le moment).
Les API soit disant obscures ... sont on ne peut plus simple, et le code est la meilleur documentation. Vraiment n'importe qui capable de faire un driver GPU peut comprendre tous ces API en moins d'une journee en lisant le code. Et rien n'oblige *BSD a utiliser les memes.
TTM & GEM c'est des memory manager, leur API c'est un id u32 pour identifier chaque buffer, pas besoin d'ecrire une doc pour ca.
KMS c'est xrandr dans le noyau, tu prends la docs d'xrandr et voila.
DRI* c'est un protocol propre au server X qui permet a une application d'utiliser directement le buffer d'une pixmap pour faire son rendu. C'est utiliser principalement par OpenGL. Ca permet a une application de faire le rendu opengl directement (d'ou Direct Rendering Infrastructure) au lieu d'envoyer les commandes opengl au serveur X (indirect opengl rendering). DRI* encore une fois c'est simple en gros c'est comment obtenir le u32 qui identifie de maniere unique un buffer avec le kernel memory manager (TTM/GEM).
Voila la doc tu l'as, maintenant faut plus pleurer !
Gallium n'est pas une implementation generique d'OpenGL.
Gallium offre une abstraction pour l'ecriture de driver, ce qui permet de simplifier le processus.
En gros en mesa classic :
GL->mesa->driver (avec un api pour les drivers qui a toutes les faiblesses d'opengl notament sur la gestion des texture)
Avec gallium:
GL->mesa->Gallium->driver
Mesa est le frontend opengl de gallium, certain travail sur un frontend directx, d'autre sur un frontend vdpau. L'avantage ici c'est que toutes les saloperies d'opengl ne sont pas exposes au driver mais dans la glue mesa-gallium et donc qu'il y a un seul endroit ou il faut faire le sale boulot.
La gestion de la memoire ne change pas vraiment entre classic et gallium, il n'y pas d'impact visible du point de vue de l'utilisateur.
On peut recuperer le firmware du driver proprio pour faire le RE si la license de ce firmware fait peur... Le driver proprio n'a pas cette section iirc
Perso j'aimerai bien voir un RE du firmware, il n'y a pas grand chose d'interessant dedans mais ca serait utile.
En gros sur le GPU il y a des especes de microcontrolleur et les firmware c'est le code qu'execute ces microcontrolleur. Ces microcontrolleur s'occupe de tache repetitive (lire la memoire system et programmer les registres GPU, gerer les IRQ, power management, ...)
Il y a de la 3D pour radeon, jusqu'au HD6850 (pour les HD6950 et au dessus ca arrive). Bon pour avoir la 3D faut un keunel recent (2.6.38/37) avec KMS et un ddx recent et surtout un mesa comme 7.10 (jusqu'a HD5xxx iirc) ou alors 7.11(git quoi).
Oui desole, j'oublie aussi la categorie infographie, bien que dans ce cas a mon sens les applications d'infographie ne sont pas aussi complex que les jeux (souvent un bon rendu filaire suffit et l'application utilise du raytracing pour le rendu finale).
J'avoue que dans tous les cas je ne tombe dans auncune des categorie, mon bureau linux c'est des terminaux gnome et un browser woeub les jours de folies ! ;)
Le pilote proprio fait confiance à l'userspace, il ne font donc aucune analyse et il n'ont pas non plus d'étape de relocation (ie translation entre buffer id et address physique simplement parceque leur memory manager ne fonctionne pas de la même manière)
Avec gallium, il n'y a pas de software fallback, tout est accéléré, cela étant dit lorsqu'une extension est ajoutée a mesa puis gallium, cela ne veut pas dire que tout les pilotes gallium en profitent automatiquement, il faut souvent du code spécifique dans le pilote.
Le pilote Nouveau est dans la partie staging du noyau ; par conséquent, ils peuvent théoriquement changer leur API sans que Linus gueule (mais Linus gueule quand même). Pour radeon, ce n'est pas le cas ; on a donc une API figée. La solution est soit d'introduire un nouveau pilote soit de rajouter par dessus l'ancien un nouveau pilote qui se comporte différemment (cela pose bcp de problèmes).
Ce n'est pas tant r600g qu'il faut réécrire mais des parties du pilote noyau. Je m'amuse avec différents designs, après rien ne dit que les autres dev accepteront un nouveau design. Si cela devait arriver je dirais 1an-2an à moins que subitement il y ait plein de gens a travailler sur le stack graphique.
J'ai oublier de preciser, a mon avis on peut relativement facilement depasser r300g avec r600g une fois qu'on aurai le support de l'hyperz et du fast clear et avec des optimizations supplementaire. Par contre a mon avis on restera loins derriere le driver closed source.
Apres la question est de savoir qu'elle avenir on veut pour la platform linux. Si l'on considere que le but est d'avoir un desktop aguichant et reactif alors on a deja plus ou moins atteind l'objectif. Si l'on veut permettre a linux de faire tourner des jeux pour Jean Kevin alors on est encore tres tres loin de l'objectif.
Pour m'a part, je pense que linux ne pourra pas percer sans les jeux, je pense que la majeur partie des ordinateurs prive ont une forte orientation ludique. A mon sens meme si les entreprises utilisaient linux, les particuliers continueraient a utiliser windows en majorite.
Mon objectif est donc d'avoir un jour une alternative credible et open source qui puisse seduire un Jean Kevin.
Ne t'inquiete pas les trolls je les fais moi meme ! Je suis un grand garcon maintenant.
Non, il me semble impossible de corriger certaines choses sans tout refaire. Par exemple pour l'ioctl noyau. Apres pour l'userspace il est possible d'ameliorer petit a petit mais a un moment ou a un autre le mauvais design de l'interface noyau sera le bottleneck et a ce moment il n'y a pas d'autre solution que de reecrire la partie noyau ce qui implique aussi une reecriture de l'userspace (mais on devrait pouvoir garder bcp de code).
Les pilotes proprietaire ne sont pas destine a madame Michu ou meme a Jean Kevin (d'ailleurs va falloir qui range sa chambre celui la). Les pilotes proprietaire c'est pour les grands monsieur qui font de la dao,cao ... catia et compagnie le tout sur des stations de travail certifie (Suse,RHEL,...).
Le fait que tu puisse installer ces drivers pour les gpu vendu dans le commerce, c'est juste un malheureux hasard...
Donc le driver proprio c'est pour un segment de marche tres specifique, hyper restreint et passer du driver proprio au driver libre n'est juste pas imaginable (il faudrait probablement investir plusieurs dizaine de millions de dollars pour mettre le driver libre a niveau).
Autant que je reponde, j'aime trop les trolls, je suis comme ca je peux pas m'en empecher :)
Atombios ne pose aucun probleme point de vue 3D/2D ou acceleration. Atombios est uniquement utilisee pour le mode setting ou pour la configuration du GPU (nombre de ligne PCIE, economie d'energie ...). Autrement dit atombios n'interviens dans aucun code critique. ie rien qui doit tourner ultra vite, si le modesetting prend 50ms au lieux de 10ms personne ne verra la difference, on change pas constament de mode video.
Le probleme majeurs des drivers radeon c'est l'architecture meme du materiel. En gros pour resumer, sur les cartes nvidia il y a des espaces d'addressage par channel ce qui permet de controller les zones memoires auxquelles le GPU peut acceder. Pour radeon c'est un unique espace d'addressage ce qui implique que les commandes du GPU peuvent etre utilisees pour acceder a toute la memoire, y compris toute la memoire system s'il n'y a pas d'iommu proprement configure (aujourd'hui a ma connaissance toutes les iommu sont configurees en passthrough a cause de tous leurs bugs).
Du coup pour avoir un semblant de securite le driver radeon dans le noyau linux analyse les commandes de l'userspace avant de l'envoye au GPU. Dc l'userspace prend du temps CPU a construire un buffer commande et le kernel prend du temps a analyser se buffer de commandes.
Ce n'est pas l'unique explication, en plus de ce point, la cs ioctl (que j'ai eu la mauvaise idee de creer) a un certain nombre de limitation, nombre de dw que l'on peut envoyer par appel, relocation ... Tout cela conduit a des bottleneck a droite a gauche.
Enfin r600g, une fois encore c'est moi qui est eu la bonne idee des mauvaises decisions je suis tres fort pour ca ! :o) r600g a ete concu selon le modele des constants states. J'etais jeune et innocent ! Je decouvrais le monde. Je peux vous le dire aujourd'hui il y a pas plus mauvais design que les constants state dans le driver si l'api que vous accelerez n'a pas de constant state. Hors c'est quoi donc qu'on accelere ? OpenGL ! Qui n'est pas concu du tout mais alors pas du tout pour les constants state (je ne mentione pas ici de l'extension qui va dans ce sens car qd bien meme celle ci serait integre pour les futures version d'opengl on aura encore pour une tripote d'annee des apps gl qui n'en tireront pas partie).
Rajoutez a cela que gallium aussi a prit le chemin des constant state et vous rajoutez une mauvaise decisions sur une autre mauvaises decisions ! Au final le driver r600g passe enormement de temps a construire chaque command buffer (plus que le driver nouveau qui a ete mieux concu sur ce point). r300g s'en sort bien aussi, un petit nombre de developpeur a passer bcp de temps a l'optimiser.
Bon, pamplemouse sur la cerise (sisi ca peut tenir) r600g ne tire pas partie de fonction comme l'hyperz ou le fast clearing (alors que nouvau tire partie de fonctionalite equivalente). Par ailleurs le ddx aussi joue probablement un role mineur dans la diff de performance.
Voila, sur ce je repart prendre de nouvelle mauvaise decisions le tout pour aguicher des jolies troll.
[^] # Re: Pitié
Posté par glisse . En réponse au journal Mélenchon à 14% d'intentions de vote.... Évalué à 5.
Alors le peuple aurait du payer la facture parceque des dirigeants de banques ont pris des risques demesures ? Donc en gros selon toi on privatise les profits et on fait payer aux peuples les pertes. Je trouve que le peuple d'islande a eu raison de dire non, de ne pas vouloir payer les fautes d'un petit groupe.
Je suis d'accord que la situation en Grece est differente mais il n'empeche qu'un referendum en Grece avait de la legitimite. D'autant plus qu'en Grece c'est principalement l'argent de banque qui est en cause et qu'au finale aujourd'hui en pratique la Grece ne remboursera qu'une partie de sa dette (pour les optimistes).
[^] # Re: 2 tours
Posté par glisse . En réponse au journal Mélenchon à 14% d'intentions de vote.... Évalué à 1.
La methode de Borda modifie, me semble la meilleur pour l'election d'une personne. Pour une assemble, la proportionnelle est plus simple.
http://fr.wikipedia.org/wiki/M%C3%A9thode_Borda
Modifier: N candidat, un electeur classe M candidat avec M
[^] # Re: Pitié
Posté par glisse . En réponse au journal Mélenchon à 14% d'intentions de vote.... Évalué à 5.
Qu'est ce qui est extremiste ? Une societe dans laquelle certains gagnent des centaines de fois plus que des personnes qui travaillent ? Ou une societe qui prone un juste salaire et une juste distribution des richesses.
Et sincerement avec 30000euros par moi tu peux t'acheter un gros appartement, une grosse voiture, manger dans des bon restaurant tous les jours, bref vivre tres bien selon les criteres consumeristes. A quoi te servirons des milliers d'euros de plus ? Acheter un jet ? Un gros yatch ?
[^] # Re: Pitié
Posté par glisse . En réponse au journal Mélenchon à 14% d'intentions de vote.... Évalué à 6.
C'est fallacieux de dire que si le peuple Grec avait repondu non il n'y avait pas d'autre solution. D'autre solution existe toujours, ici en l'occurence aucun politique ne voulait se donner la peine de reflechir a une autre solution.
Je te conseille de lire le monde diplomatique pour avoir un large pannel d'autre solutions possibles. Ou encore http://www.naomiklein.org/shock-doctrine pour te rendre compte de l'utilisation horrible qui est faite de cette crise economique.
Je ne dis pas que tous les referendums sont bon, pour moi la qualite d'un referendum depend de son libelle. Dans le cas evoque je trouve que le libelle : Rembourser la dette ? (oui | non) est tout ce qu'il y a de plus democratique.
[^] # Re: Pitié
Posté par glisse . En réponse au journal Mélenchon à 14% d'intentions de vote.... Évalué à 4.
C'est sur que eux les politiques ils potassent les sujets …
http://bigbrowser.blog.lemonde.fr/2012/02/02/aveuglement-en-grece-qui-donc-a-lu-le-memorandum-du-fmi-avant-de-le-signer/
[^] # Re: Merci pour ATI
Posté par glisse . En réponse au journal Voilà comment j'abandonne Linux à la maison. Évalué à 2.
Encore une fois faut etre realiste, les mach64 ne permettent certainement de pas d'avoir compiz avec 2M de video ram … 8 pour le top end des mach64. Leur taille de texture limite … Donc non les mach64 en 3d ca ne sert a rien. Les r100 par contre oui peuve supporte compiz et les r100 sont toujours supporte par le driver open source. Pour les intel 840 c'est une decision d'intel et comme dans la communaute seul intel fait du support pour leur gpu et bien le driver pour 840 est partie dans les oubliettes mais ca n'empeche personne de le resussite les sources sont la.
Il faut comprendre que sur les GPU ont en sous effectif chronique et que sincerement on pas le temps de s'embete de GPU vieux de plus de 20ans (les mach sont sortie en 1990-92).
Les intel 840 sont plus recent 1998/99, mais bon c'est pas de tout derniere fraicheur non plus.
Donc arrete de dire qu'on demande un GPU de moins de 6mois, on demande un GPU de moins de 10ans. C'est vraiment pas grand chose.
[^] # Re: Merci pour ATI
Posté par glisse . En réponse au journal Voilà comment j'abandonne Linux à la maison. Évalué à 2.
A oui ca c'est sur que c'est des GPU qui depote, sincerement deja les r100 c'est juste bon pour quake1/quake2, les mach a peine utile pour quake1. A un moment faut etre realiste …
[^] # Re: Merci pour ATI
Posté par glisse . En réponse au journal Voilà comment j'abandonne Linux à la maison. Évalué à 2.
Alors la merci de me donner un pointeur parceque non le pilote libre pour les GPU radeon n'est pas abandonne. Ce pilote (plusieurs si on va dans les details) support des radeon r100 (radeon 9000) au derniere HD6xxx et bientot HD7xxx.
[^] # Re: Wayland / X
Posté par glisse . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 5.
Le probleme viens principalement du fait que ttm/gem a de gros besoins sur comment marche le memory management du noyau linux a des api pour tous ces trucs. La derniere fois que j'ai regarde un noyau bsd (5 ou 6 ans maintenant). Il y avait presque rien c'etait vraiment pas concu pour marcher comme on le veut. Bref il semblait necessaire de devoir d'abord travailler sur le corps du noyau bsd avant de pouvoir implementer un des memory manager. Mais je pense que le travail qui a ete realise pour avoir les driver nvidia a probablement bcp change les choses.
En gros on a besoin de tous ce qui est decrit dans ce mail et probablement un peux plus parcequ'on fait certaine chose differement de nvidia.
http://lists.freebsd.org/pipermail/freebsd-hackers/2006-June/016995.html
[^] # Re: Gestionnaire de fenêtres
Posté par glisse . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 2.
Tu utilise un truc comme llvmpipe (opengl avec CPU). Ou alors tu fais ton propre truc de rendu software mais la ton probleme ca sera les clients wayland, car c'est eux qui font le rendu de leur fenetre. Donc il faudra aussi que tu portes les toolkit pour qu'il marche en GL ou avec autre chose.
GL c'est le denominateur commun choisi implicitement parceque tout les platformes de ces 5 dernieres annees le supportent.
[^] # Re: Wayland / X
Posté par glisse . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 8.
On peut jouer a ce jeux longtemps ;) Moi j'aime bien jouer :)
Ecrire des specifications comme par exemple celle d'opengl ou du c99 pour TTM/GEM/KMS ... n'a aucun sens. Fondamentalement le coeur de TTM/GEM/KMS n'a pas cesse de changer. Mais l'interface expose est toujours la meme. Un simple uint32_t (et voila je peux meme plus faire le feignant et utiliser u32) qui identifier de maniere unique un buffer pour TTM/GEM et un moyen de mmap a partir de cette uint32_t. C'est tout ce que demande l'userspace.
Sincerement je crois que tu as passe trop de temps a faire du management de projet et autre truc .... (je me censure).
Par ailleur je tiens a preciser que tout le code TTM/GEM/KMS est double license GPL/BSD. Donc oui vous pouvez regarder le code et meme le copier.
Vraiment demander une doc c'est de la mauvaise foi. C'est pas dure a comprendre tous ce code. Le probleme c'est que le memory management des *BSD est different et qu'il faut une personne qui comprenne le code gerant la memoire dans le noyau *BSD (a propos elle est ou la doc pour ca ?)
Faut pas avoir peur de la taille du code des drivers GPU. Le modesetting prend bcp de
place et c'est pas complique.
Je soutiens qu'une personne capable d'ecrire un driver GPU n'aura aucun mal a porter vers un BSD et qu'aucune documentation au monde ne servira. Vraiment ecrire la doc prendrer plus de temps que d'ecrire le code.
[^] # Re: Gestionnaire de fenêtres
Posté par glisse . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 3.
Tu te trompes ;)
L'idée c'est d'utiliser EGL & GLES2. EGL c'est un API standard pour pouvoir créer des contexts OpenGL ou OpenVG ou autre (rien d'autre dans le standard pour le moment). Donc tu écris ton compositeur wayland avec EGL, tu crées un context opengl (wayland encourage d'utiliser GLES2 parceque c'est en gros opengl 2.0 - opengl 1.0 et que ca correspond as ce que supporte tous les GPU embedded).
Et voila c'est exactement comme les compositeur actuel. Tu fais de l'opengl, et les bugs GPU bah c'est des bugs du driver GL.
Bon je simplifie un peux parceque tu as aussi besoin de faire le modesetting mais ca y a deja des librairies pour utiliser KMS et faire le boulot a ta place. Ou tu peux copier le code de weston.
La vérité c'est que la partie modesetting & creation de context ca doit être 1000lignes de code en plus par rapport a un compositeur X. C'est pas grand chose et c'est standard si tu utilises EGL et KMS (KMS linux only pour le moment).
[^] # Re: Wayland / X
Posté par glisse . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 6.
Les API soit disant obscures ... sont on ne peut plus simple, et le code est la meilleur documentation. Vraiment n'importe qui capable de faire un driver GPU peut comprendre tous ces API en moins d'une journee en lisant le code. Et rien n'oblige *BSD a utiliser les memes.
TTM & GEM c'est des memory manager, leur API c'est un id u32 pour identifier chaque buffer, pas besoin d'ecrire une doc pour ca.
KMS c'est xrandr dans le noyau, tu prends la docs d'xrandr et voila.
DRI* c'est un protocol propre au server X qui permet a une application d'utiliser directement le buffer d'une pixmap pour faire son rendu. C'est utiliser principalement par OpenGL. Ca permet a une application de faire le rendu opengl directement (d'ou Direct Rendering Infrastructure) au lieu d'envoyer les commandes opengl au serveur X (indirect opengl rendering). DRI* encore une fois c'est simple en gros c'est comment obtenir le u32 qui identifie de maniere unique un buffer avec le kernel memory manager (TTM/GEM).
Voila la doc tu l'as, maintenant faut plus pleurer !
http://www.youtube.com/watch?v=vQDCUnXNJrA
# Touche d'humour
Posté par glisse . En réponse au journal Un budget équilibré, est-ce trop demander ?. Évalué à 1.
Bon je suis en retard sur ce beau thread, juste une touche d'humour
http://www.youtube.com/watch?v=cRvPY1-jIj8
# Gallioume
Posté par glisse . En réponse à la dépêche Petites brèves : Mesa 7.11, samba 3.6 et qemu 0.15. Évalué à 7.
Gallium n'est pas une implementation generique d'OpenGL.
Gallium offre une abstraction pour l'ecriture de driver, ce qui permet de simplifier le processus.
En gros en mesa classic :
GL->mesa->driver (avec un api pour les drivers qui a toutes les faiblesses d'opengl notament sur la gestion des texture)
Avec gallium:
GL->mesa->Gallium->driver
Mesa est le frontend opengl de gallium, certain travail sur un frontend directx, d'autre sur un frontend vdpau. L'avantage ici c'est que toutes les saloperies d'opengl ne sont pas exposes au driver mais dans la glue mesa-gallium et donc qu'il y a un seul endroit ou il faut faire le sale boulot.
La gestion de la memoire ne change pas vraiment entre classic et gallium, il n'y pas d'impact visible du point de vue de l'utilisateur.
[^] # Re: L'argent
Posté par glisse . En réponse à la dépêche AMD s’investit dans ses pilotes libres.. Évalué à 3.
Oui c'est pris en charge par mesa dc opengl, un mesa 7.10 ou 7.11 avec un noyau au moins 2.6.39 mais 3.0 preferable.
Par contre ce n'est exploite que par des applications OpenGL qui utilise les shader. Le GPGPU vendu par les commerciaux ca ne sera pas avant 2-3 ans.
[^] # Re: GNOME 3.0, ou comment se tirer une balle dans le pied
Posté par glisse . En réponse à la dépêche GNOME 3.0 : le grand saut !. Évalué à 8.
Peut tu donner le modele exact de ton GPU ?
[^] # Re: quelle carte pas chère acheter aujourd'hui ?
Posté par glisse . En réponse à la dépêche Effervescence autour de la pile graphique libre. Évalué à 6.
On peut recuperer le firmware du driver proprio pour faire le RE si la license de ce firmware fait peur... Le driver proprio n'a pas cette section iirc
Perso j'aimerai bien voir un RE du firmware, il n'y a pas grand chose d'interessant dedans mais ca serait utile.
En gros sur le GPU il y a des especes de microcontrolleur et les firmware c'est le code qu'execute ces microcontrolleur. Ces microcontrolleur s'occupe de tache repetitive (lire la memoire system et programmer les registres GPU, gerer les IRQ, power management, ...)
[^] # Re: nouveau driver
Posté par glisse . En réponse à la dépêche Effervescence autour de la pile graphique libre. Évalué à 9.
Il y a de la 3D pour radeon, jusqu'au HD6850 (pour les HD6950 et au dessus ca arrive). Bon pour avoir la 3D faut un keunel recent (2.6.38/37) avec KMS et un ddx recent et surtout un mesa comme 7.10 (jusqu'a HD5xxx iirc) ou alors 7.11(git quoi).
http://xorg.freedesktop.org/wiki/RadeonFeature
[^] # Re: nouveau driver
Posté par glisse . En réponse à la dépêche Effervescence autour de la pile graphique libre. Évalué à 4.
Oui desole, j'oublie aussi la categorie infographie, bien que dans ce cas a mon sens les applications d'infographie ne sont pas aussi complex que les jeux (souvent un bon rendu filaire suffit et l'application utilise du raytracing pour le rendu finale).
J'avoue que dans tous les cas je ne tombe dans auncune des categorie, mon bureau linux c'est des terminaux gnome et un browser woeub les jours de folies ! ;)
[^] # Re: nouveau driver
Posté par glisse . En réponse à la dépêche Effervescence autour de la pile graphique libre. Évalué à 10. Dernière modification le 03 avril 2011 à 17:49.
Le pilote proprio fait confiance à l'userspace, il ne font donc aucune analyse et il n'ont pas non plus d'étape de relocation (ie translation entre buffer id et address physique simplement parceque leur memory manager ne fonctionne pas de la même manière)
Avec gallium, il n'y a pas de software fallback, tout est accéléré, cela étant dit lorsqu'une extension est ajoutée a mesa puis gallium, cela ne veut pas dire que tout les pilotes gallium en profitent automatiquement, il faut souvent du code spécifique dans le pilote.
Le pilote Nouveau est dans la partie staging du noyau ; par conséquent, ils peuvent théoriquement changer leur API sans que Linus gueule (mais Linus gueule quand même). Pour radeon, ce n'est pas le cas ; on a donc une API figée. La solution est soit d'introduire un nouveau pilote soit de rajouter par dessus l'ancien un nouveau pilote qui se comporte différemment (cela pose bcp de problèmes).
Ce n'est pas tant r600g qu'il faut réécrire mais des parties du pilote noyau. Je m'amuse avec différents designs, après rien ne dit que les autres dev accepteront un nouveau design. Si cela devait arriver je dirais 1an-2an à moins que subitement il y ait plein de gens a travailler sur le stack graphique.
[^] # Re: nouveau driver
Posté par glisse . En réponse à la dépêche Effervescence autour de la pile graphique libre. Évalué à 10.
J'ai oublier de preciser, a mon avis on peut relativement facilement depasser r300g avec r600g une fois qu'on aurai le support de l'hyperz et du fast clear et avec des optimizations supplementaire. Par contre a mon avis on restera loins derriere le driver closed source.
Apres la question est de savoir qu'elle avenir on veut pour la platform linux. Si l'on considere que le but est d'avoir un desktop aguichant et reactif alors on a deja plus ou moins atteind l'objectif. Si l'on veut permettre a linux de faire tourner des jeux pour Jean Kevin alors on est encore tres tres loin de l'objectif.
Pour m'a part, je pense que linux ne pourra pas percer sans les jeux, je pense que la majeur partie des ordinateurs prive ont une forte orientation ludique. A mon sens meme si les entreprises utilisaient linux, les particuliers continueraient a utiliser windows en majorite.
Mon objectif est donc d'avoir un jour une alternative credible et open source qui puisse seduire un Jean Kevin.
[^] # Re: nouveau driver
Posté par glisse . En réponse à la dépêche Effervescence autour de la pile graphique libre. Évalué à 10.
Ne t'inquiete pas les trolls je les fais moi meme ! Je suis un grand garcon maintenant.
Non, il me semble impossible de corriger certaines choses sans tout refaire. Par exemple pour l'ioctl noyau. Apres pour l'userspace il est possible d'ameliorer petit a petit mais a un moment ou a un autre le mauvais design de l'interface noyau sera le bottleneck et a ce moment il n'y a pas d'autre solution que de reecrire la partie noyau ce qui implique aussi une reecriture de l'userspace (mais on devrait pouvoir garder bcp de code).
En meme temps au final tout ca m'occupe... ;)
[^] # Re: Gaspillage de ressources.
Posté par glisse . En réponse à la dépêche Effervescence autour de la pile graphique libre. Évalué à 6.
Les pilotes proprietaire ne sont pas destine a madame Michu ou meme a Jean Kevin (d'ailleurs va falloir qui range sa chambre celui la). Les pilotes proprietaire c'est pour les grands monsieur qui font de la dao,cao ... catia et compagnie le tout sur des stations de travail certifie (Suse,RHEL,...).
Le fait que tu puisse installer ces drivers pour les gpu vendu dans le commerce, c'est juste un malheureux hasard...
Donc le driver proprio c'est pour un segment de marche tres specifique, hyper restreint et passer du driver proprio au driver libre n'est juste pas imaginable (il faudrait probablement investir plusieurs dizaine de millions de dollars pour mettre le driver libre a niveau).
[^] # Re: nouveau driver
Posté par glisse . En réponse à la dépêche Effervescence autour de la pile graphique libre. Évalué à 10.
Autant que je reponde, j'aime trop les trolls, je suis comme ca je peux pas m'en empecher :)
Atombios ne pose aucun probleme point de vue 3D/2D ou acceleration. Atombios est uniquement utilisee pour le mode setting ou pour la configuration du GPU (nombre de ligne PCIE, economie d'energie ...). Autrement dit atombios n'interviens dans aucun code critique. ie rien qui doit tourner ultra vite, si le modesetting prend 50ms au lieux de 10ms personne ne verra la difference, on change pas constament de mode video.
Le probleme majeurs des drivers radeon c'est l'architecture meme du materiel. En gros pour resumer, sur les cartes nvidia il y a des espaces d'addressage par channel ce qui permet de controller les zones memoires auxquelles le GPU peut acceder. Pour radeon c'est un unique espace d'addressage ce qui implique que les commandes du GPU peuvent etre utilisees pour acceder a toute la memoire, y compris toute la memoire system s'il n'y a pas d'iommu proprement configure (aujourd'hui a ma connaissance toutes les iommu sont configurees en passthrough a cause de tous leurs bugs).
Du coup pour avoir un semblant de securite le driver radeon dans le noyau linux analyse les commandes de l'userspace avant de l'envoye au GPU. Dc l'userspace prend du temps CPU a construire un buffer commande et le kernel prend du temps a analyser se buffer de commandes.
Ce n'est pas l'unique explication, en plus de ce point, la cs ioctl (que j'ai eu la mauvaise idee de creer) a un certain nombre de limitation, nombre de dw que l'on peut envoyer par appel, relocation ... Tout cela conduit a des bottleneck a droite a gauche.
Enfin r600g, une fois encore c'est moi qui est eu la bonne idee des mauvaises decisions je suis tres fort pour ca ! :o) r600g a ete concu selon le modele des constants states. J'etais jeune et innocent ! Je decouvrais le monde. Je peux vous le dire aujourd'hui il y a pas plus mauvais design que les constants state dans le driver si l'api que vous accelerez n'a pas de constant state. Hors c'est quoi donc qu'on accelere ? OpenGL ! Qui n'est pas concu du tout mais alors pas du tout pour les constants state (je ne mentione pas ici de l'extension qui va dans ce sens car qd bien meme celle ci serait integre pour les futures version d'opengl on aura encore pour une tripote d'annee des apps gl qui n'en tireront pas partie).
Rajoutez a cela que gallium aussi a prit le chemin des constant state et vous rajoutez une mauvaise decisions sur une autre mauvaises decisions ! Au final le driver r600g passe enormement de temps a construire chaque command buffer (plus que le driver nouveau qui a ete mieux concu sur ce point). r300g s'en sort bien aussi, un petit nombre de developpeur a passer bcp de temps a l'optimiser.
Bon, pamplemouse sur la cerise (sisi ca peut tenir) r600g ne tire pas partie de fonction comme l'hyperz ou le fast clearing (alors que nouvau tire partie de fonctionalite equivalente). Par ailleurs le ddx aussi joue probablement un role mineur dans la diff de performance.
Voila, sur ce je repart prendre de nouvelle mauvaise decisions le tout pour aguicher des jolies troll.