Reprise du message précédent :

bah mon objectif était de gagner quelques microcycles de boot sur un ssd et pis jaime bien les p'tites lignes qui défilent.
c'était juste pour tester, pas grave

 
Génération de carte trop récente    
 
De mon expérience, Nouveau fonctionnait très bien sur 7900GS et 8800GTS, faut lui laisser un peu le temps de mûrir pour ta Quadro

Possible. Comme je l'avais dit l'autre jour, je reste sous nvidia, mais je garde un oeil sur les nouvelles versions de Nouveau de manière à tester régulièrement les évolutions de ce pilote, étant naturellement sympathisant du Libre mais ne pouvant pas avoir un ordi stable sans le pilote propriétaire

perso, j'ai viré nouveau parce qu'il n'était pas assez rapide.
mais de temps en temps depuis que j'ai fais le changement, la tv HD crashe alors que ça n'arrivait pas avec nouveau.
par contre au niveau des jeux, impossible de jouer à quoiquecesoit autre que tuxracer avec nouveau.

Je ne parviens pas à afficher blender (2.49 ou 2.57) correctement sur une carte ATI 9200 PRO, RV280 pilote libre, sauf:
- à mettre un "NoAccel" "True" dans mon xorg.conf
- ou à utiliser le script blender-softwaregl du binaire 2.57
 
Les polices de caractère sont illisibles.
 
J'ai me semble-t-il presque tout essayé:
- avec ou sans KMS: soit avec Grub soit avec Options radeon modeset=0 dans /etc/modprobe.d/radeon-kms.conf
et / ou
- avec ou sans composite
- en modifiant le fichier xorg à l'envie...  
 
Pour info (avec KMS)

 
En revanche, j'ai un vieux portable avec une Ati Xpress 200M qui lui permet d'afficher correctement blender.
 
Bref, si quelqu'un a une carte avec un RV280 et un blender fonctionnel, ça m'intéresse.

vu la description du problème, c'est pas au niveau de KMS ou de X qu'il faut regarder mais au niveau du pilote 3D (donc dans mesa).
 
L'accélération matérielle des fonctions opengl a l'air de pas aimer blender (ou le contraire). on le voit parce qu'en rendu logiciel (avec noaccel ou softwaregl, mais ça marcherait aussi en forçant la variable LIBGL_ALWAYS_SOFTWARE=1 avant de lancer blender) ça fonctionne.
 
ça marche avec un X200M parce que ce n'est pas le même pilote (vraisemblablement R300g pour ce dernier versus R200 pour la 9200).
 
ça vaudrait surement le coup de rapporter le bug.

Mjules: tu es incollable comme d'habitude. Merci bien    
 
Car en effet, un simple: LIBGL_ALWAYS_SOFTWARE=1 blender fonctionne tel quel.
 
Alors que j'avais besoin:
1.- de lancer le script blender-softwaregl
2.- de modifier le script de telle sorte qu'il toggle composite.
 
Bon, je vais faire un rapport de bug sur le bugzilla de freedesktop.org.
 

Bon, étonnamment lorsque c'est LIBGL_ALWAYS_SOFTWARE=0 blender, cela fonctionne aussi.
 
Et j'ai quand même dans les deux cas une erreur dès lors que j'ouvre une boîte de dialogue (User preferenes):
LIBGL_ALWAYS_SOFTWARE=0 blender
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  155 (GLX)
  Minor opcode of failed request:  11 (X_GLXSwapBuffers)
  Serial number of failed request:  1021
  Current serial number in output stream:  1021
 
Bug reporté.

Bon, j'ai installé mesa git et c'est nettement mieux.
 
ldconfig -p | grep libGL.so
        libGL.so.1 (libc6,x86-64, Système d'exploitation ABI : Linux 2.4.20) => /opt/xorg/lib/libGL.so.1
        libGL.so.1 (libc6,x86-64) => /usr/lib64/libGL.so.1
        libGL.so.1 (libc6) => /usr/lib/libGL.so.1
        libGL.so (libc6,x86-64, Système d'exploitation ABI : Linux 2.4.20) => /opt/xorg/lib/libGL.so
        libGL.so (libc6,x86-64) => /usr/lib64/libGL.so
 
 
Pas de crash et un affichage à peu près correct.

Bon, c'est décidé, je retente nouveau

Je viens de réinstaller le pilote, j'ai fait ce qu'il fallait au niveau du chargement des modules, etc. Maintenant, je m'atèle à resoudre les soucis, à commencer par :

- les couleurs sur les dégradés qui sont dégueulasses
- le vsync qui mériterait d'être activé
- des microlags de la souris par moment. J'ai l'impression que ce n'est présent que lorsque les effets de bureau sont activés (KDE)
- freeze complet de X par moment, comment tracer ce qui a provoqué l'erreur d'ailleurs ? Genre un log consultable au démarrage suivant ?

Si vous avez les solutions, je suis ultra preneur  

Edit : Je viens d'avoir un nouveau freeze. J'avais de la musique dans Clementine. Le graphique s'est figé, impossible de faire quoi que ce soit bien que je puisse encore déplacer le curseur à l'écran. La musique a continué de tourner jusqu'à la fin du morceau en cours mais n'a pas enchaîné sur le suivant. Si ça peut aider à envisager l'origine du problème et le début d'une solution. C'est très chiant, 2 fois en à peu près une heure...

Edit² : mes problèmes de freeze ressemblent beaucoup à ça
http://www.mail-archive.com/ubuntu [...] 53356.html

Ah, c'est exactement ça : http://bugs.debian.org/cgi-bin/bug [...] bug=610987

D'après le thread chez Debian, le kernel 2.6.39 résoudrait le problème. Je viens de l'installer depuis testing (ArchLinux), on va bien voir ce que ça donne, au moins pour les freezes.

Pour l'instant, le noyau semble au moins ramener la stabilité du système. Pour le reste des problèmes, rien n'a changé. Et encore, je n'ai pas encore testé le multi-écrans chez moi.
 
En revanche, quel connerie d'avoir appelé ce pilote nouveau, pour les recherches sur le net c'est relou, ça remonte plein de choses dont on a que foutre.

Une NVS3100m n'est pas franchement une bête de course. Je ne comprends pas trop l'intérêt d'un GPU aussi faiblard quand l'IGP est au moins aussi puissant (sauf si t'as besoin de cuda). A ta place, j'oublierai simplement le GPU.

plains toi au correcteur d'orthographe du client IRC de marcheu.

pour les couleurs, essaye de jouer avec le dithering (option fpdither), pour le vsync, voir avec un noyau récent mais par défaut le vsync est activé sur les pilotes récents (mesa et DDX). pour les lags de la souris, regarde avec latencytop, possible que ce soit lié au polling du vga ( https://bugs.freedesktop.org/show_bug.cgi?id=29536 et https://bugs.freedesktop.org/show_bug.cgi?id=29433), dans ce cas, options drm_kms_helper poll=0  dans /etc/modprobe.conf devrait résoudre le problème.

 
Si tu ne veux pas utiliser git pour le reste de tes opérations, il est possible de le mettre dans un endroit hort $PATH et de l'appeler spécifiquement pour un soft donné :

 
j'ai mis ça dans mon bashrc, et j'appelle les softs que je veux avec rdgl nom_du_soft.

Crois moi, le 3100M n'a rien a voir avec IGP des Core iX, pour avoir eu les deux, c'est le jour et la nuit sur les effets de bureau. Ca reste un petit GPU, mais c'est quand même autre chose. Et puis de toute façon, j'ai pas le choix, l'IGP n'est pas accessible sur mon 8440p, seul le GPU fonctionne.

 
Merci pour tout ça, je regarde les choses dans le week end

Apparemment, l'ajout de l'option dans modprobe.conf semble corriger les microlag de souris

Le VSync, j'ai l'impression que depuis que je suis passé sous le kernel 2.6.39, c'est OK, en plus d'avoir redonné sa stabilité à mon système.

Reste cette histoire de couleur qui ne passe pas, même avec l'option FPDither, à moins que je l'aie mal utilisée. Elle doit se situer dans quel section du xorg.conf (ou quel fichier de xorg.conf.d) ?

Et dès que j'essaie de passer sur un écran externe, le système se fige quelques secondes après l'ouverture de session. Bref, ce n'est pas encore gagné nouveau...

Tu peux activer le dithering en temps réel avec randr. C'est plus simple pour tester si ça fonctionne:  
 
http://nouveau.freedesktop.org/wiki/Dithering

Bon, finalement, j'en ai eu marre, je suis repassé sous nvidia. Je retenterai nouveau régulièrement, mais pour l'instant c'est trop de alère. D'autant plus qu'en persévérant, j'ai enfin réussi à configurer TwinView comme je le voulais, donc tout fonctionne comme je le souhaite

Salut Mjules,
Quelqu'un avait créé une page wikipédia "Pile graphique Linux" ; je l'ai remplie du mieux que j'ai pu si tu veux jeter un œil voir si je dis pas trop de bêtises ?

Une lecture rapide n'a pas retrouvé de problème

merci :-)

Il y a un petit retropédalage sur la fin (au sein au sein), mais sinon c'est sympa à lire.

corrigé, merci :-)

tiens j'ai rajouté deux paragraphe à la page wikipédia :

mais je suis pas sûr de comprendre "Un pilote DDX modifié pour tirer partie de Glamor, EGL et KMS rend possible le démarrage d'un serveur X via Mesa/EGL sans système de fenêtrage natif" http://fr.wikipedia.org/wiki/Pile_graphique_Linux

la phrase d'introduction du dernier paragraphe n'est pas tout à fait exacte.  
Glamor est un moyen d'utiliser OpenGL pour accélérer le rendu 2D, d'une certaine façon, il ressemble un peu à glucose (projet qui n'a jamais décollé) mais il faut savoir que la partie 3D des cartes graphiques est déjà utilisée pour accélérer le rendu 2D. EXA et UXA (ou SNA) sont implémentées de telle façon qu'elles tirent parti des moteurs 3D des cartes graphiques actuelles (d'un autre coté, il n'y a plus de partie 2D sur les cartes desktop du moment).

tiens ça m'étonne
 
1°) Tu veux dire qu'EXA/UXA accèdent aux routines 3D sans passer par OpenGL ? Comment est-ce possible ?
 
2°) cette phrase de 2005 n'est donc plus juste ?

http://linux.tlk.fr/traitement-graphique/

 
Mon point de vue de développeur : ça dépend si tu es côté driver ou côté application en fait avec ton EXA/UXA
 
Un driver qui supporte OpenGL (ou Direct3D d'ailleurs) donne au programmeur qui veut faire un logiciel une façon d'accéder aux capacités de la carte graphique sans trop se prendre la tête : il sait qu'en codant un truc utilisant l'API OpenGL (ou Direct3D donc), le driver de la carte fera en sorte d'utiliser l'accélération matérielle le mieux possible.
 
Maintenant si tu es le type qui code ce driver, tu accèdes directement au hardware et tu es en charge -- en autre chose -- de fournir un driver OpenGL correct pour les applis qui veulent faire de la 3D. Correct ça veut que tu respectes la spec (OpenGL n'est qu'une spec, un bout de papier en fait).  
Mais tu peux faire ce que tu veux, y compris rajouter dans ton driver d'autres manières d'accéder aux capacités 3D de la carte (ton propre OpenGL)  .
 
Tout ça pour dire que côté application on utilise ce que propose le driver, mais côté driver on fait ce qu'on veut du matériel

1/ pas mieux que Xavier_OM, aujourd'hui, il n'y a plus de circuit 2D dans les GPU, l'accélération 2D (RENDER via EXA ou UXA principalement) est implémentée en utilisant le moteur 3D de la carte graphique. Ils implémentent les routines à l'aide du langage spécifique de la carte. Tout au moins pour les 3 cartes desktop principales, c'est d'ailleurs pour ça que les pilotes 2D ont besoin du module noyau DRM (ou équivalent dans les pilotes proprios).

2/ effectivement, elle ne l'est plus. il y a eu une grosse refonte des pilotes (gestionnaire de mémoire, KMS, gallium3D etc) depuis que ce texte a été écrit. Refonte qui d'ailleurs va plutôt dans le sens des plaintes qu'il exprimait à l'époque. De façon ironique, il avait écrit ça parce qu'il pensait qu'EXA était une grosse erreur et voulait partir uniquement sur openGL. Au final, EXA s'est révélé inutilisable sans le moteur 3D, OpenGL s'est révélé difficile pour de la 2D pure (d'où openVG notamment)et complexe tout court (d'où openGL ES).

Ah ben j'apprends tout ça, merci à tous deux
 
je n'avais pas compris que DRM ne parlait qu'à des circuits 3D ("c'est d'ailleurs pour ça que les pilotes 2D ont besoin du module noyau DRM" )
Moi qui pensais que la version Composite de Metacity (GNOME 2) utilisait les circuits 2D des cartes, en fait il utilise le pilote 2D pour accéder au circuit 3D
Finalement la différence entre pilote 2D et pilote 3D est que le pilote 3D passe par Mesa/OpenGL alors que le pilote 2D utilise son propre langage en quelque sorte, tous deux dialogant avec le circuit 3D ?

avec Glamor, Jon Smirl doit être content (sauf qu'il est pas de la partie...)
 
d'ailleurs quand on lit ça c'est prophétique :

 
Cairo aujourd'hui utilise EXA il me semble (un backend OGL (gl) est en développement il me semble).
Demain il utiliserait Glamor (si le projet est adopté) ou son propre backend ?

le DRM est nécessaire pour accéder à la carte graphique de façon sécurisée et performante vu qu'aujourd'hui une carte graphique est un énorme processeur à programmer.
dans le passé, la partie 2D était accessible " en driect" mais ce n'était pas très performant et pas sécurisé du tout (on ne passait pas par le filtre du noyau)
 
pour ta 2° question, c'est à peu près oui :
2D :
applis > EXA > DDX > langage spécifique de la carte > gpu
 
3D > OpenGL/Direct3D > pilote mesa ou gallium 3D > langage spécifique > GPU

Glamor passe par DDX pour des raisons de compatibilité au niveau applicatif ?
 
ce qui donnerait :
2D > (EXA ?) > DDX modifié > Glamor > OpenGL/Direct3D > pilote mesa ou gallium 3D > langage spécifique de la carte > gpu

PS :"langage spécifique de la carte" c'est DRM qui gère ça si j'ai tout suivi ?

Tiens, sur le plan de domination du monde par OpenGL : http://cworth.org/~cworth/papers/2 [...] k-Tour.pdf

pas vraiment, c'est le pilote utilisé qui fait ça. le module DRM sert à :
 - filtrer les commandes envoyées à la carte pour éviter qu'elle dysfonctionne
 - permettre un transfert rapide des données via le DMA
 - gérer la mémoire allouée au GPU, qu'elle soit sur la carte ou mémoire système
 - depuis plus récemment, gérer les modes (résolution, fréquences etc)
 
Les pilotes en espace utilisateur lui converti les commandes envoyées via une API (EXA, OpenGL, OpenVG, Xv, VDPAU etc) en commandes compréhensibles directement par la carte (très grossièrement, une sorte d'assembleur pour GPU, spécifique à celui-ci). Une fois que cette conversion est faite (+ un certain nombres d'optimisations), il envoie tout ça au GPU en passant par le DRM qui est le seul à pouvoir communiquer avec le matériel.
 
 
un exemple de langage spécifique à la carte :
http://cgit.freedesktop.org/xorg/d [...] 0_shader.c

Je ne connais pas très bien glamor, mais en substance, ça doit pas être trop loin de la vérité.
Je pense (donc à prendre avec des pincettes), que l'idée de glamor, c'est un peu la même idée que celle du state tracker xa, c'est à dire avoir un seul pilote spécifique à la carte au lieu de 2 : un pilote Xorg générique et un pilote spécifique (Mesa/gallium) à la carte, un peu comme est la situation actuelle avec evdev et les périphérique d'entrées (un seul pilote pour presque tout, les spécificités étant gérées dans le noyau).

 
amha, cairo utilisera son propre backend vu comme ils sont partis.

J'essaie d’approfondir cairo-gl et glamor, s'agissant de l'accélération 2D via OpenGL
J'ai interrogé Eugeni Dodonov de chez Intel :
 

(je grasse)  
Si je comprends bien, jusque là on avait, côté GNOME (pour reprendre les schémas de Jon Smirl) :
App -> GTK+ -> X -> EXA/UXA/SNA -> hw ou  App -> GTK+ -> Cairo -> X Render -> X -> EXA/UXA/SNA -> hw [1]
C'est bien ça ou le 1er schéma est abandonné ?
 
Maintenant on aura
App -> GTK+ -> Cairo -> Cairo-gl -> LibGL (Mesa/Gallium 3D) DRI -> hw
donc on se débarrase de DDX, le pilote du serveur X, pour ne garder que DRI, le pilote de Mesa
c-a-d que X n'est plus utilisé du tout pour la partie graphique dans cette hypothèse ?    
 
Dans cette configuration je vois pas ce que Glamor apporte ni où il se situe ?!
Peut être App -> GTK+ -> XLib/XCB (X) DDX -> Glamor -> Cairo/Cairo-gl -> LibGL (Mesa/Gallium 3D) DRI -> hw ?
Quel bordel
 
[1] GTK+ 2.8 a permis l'exploitation de Cairo, et GTK+3.0 (en fait GTK+ 2.22) court-circuite GDK pour confier directement à Cairo le rendu, donc on gagne une étape : au lieu de App -> GTK+ -> GDK -> Cairo on a App -> GTK+ -> Cairo

en fait Glamor ressemblerait à AIGLX d'après tes explications http://mjules.littleboboy.net/carn [...] e-5-partie
on airait un rendu indirect accéléré qui garderait certainement la transparence réseau ?
 
A part ça, tu expliques pas en 1re page ce qu'est EGL exactement ? et GLSL  ?