Reprise du message précédent :
OK merci bcp pour toutes ces précisions, la machine en question n'est plus chez moi, je testerai ça dès que possible et je vous tiens au courant (par contre ma version sera peut être pas assez récente, je suis revenu à ubuntu feisty)

Oui mais non, ce n'est pas aussi simple que cela.    
 
Voici le problème :
 
- soit on utilise l'ancien driver Intel (i810) qui utilise XAA par défaut avec une bonne implémentation de GLX_EXT_texture_from_pixmap. Le résultat est un Compiz qui tourne de façon fluide avec un minimum d'usage CPU, mais des films qui ne tournent qu'avec une sortie X11 et non XV (l'accélération 2D est désactivée, XAA ne permettant pas d'allouer de la mémoire vidéo "offscreen" indispensable pour le placage de textures vidéo sur les éléments OpenGL affichés par Compiz).
 
- soit on utilise le nouveau driver Intel (intel) qui utilise EXA par défaut avec une mauvaise implémentation de GLX_EXT_texture_from_pixmap. Le résultat est un Compiz qui ne tourne pas de façon fluide avec beaucoup d'usage CPU, mais des films qui tournent avec une sortie XV (l'accélération 2D est activée, EXA permettant d'allouer la mémoire vidéo "offscreen" et donc de gérer le placage de textures vidéo sur les éléments OpenGL affichés par Compiz).
 
 
En bref, la seule véritable solution est d'attendre que le problème soit réglé en upstream au niveau de l'implémentation correcte GLX_EXT_texture_from_pixmap avec EXA. Ainsi on pourra enfin avoir un Compiz _et_ des vidéos fluides _et_ un minimum d'usage CPU...    
 
 
 

   
 
C'est important de le remarquer ; en fait, avec les versions récentes de X.org le driver i810 n'est qu'un simple lien vers le driver intel. Cela explique pourquoi certains utilisateurs ne constatent aucune différence en spécifiant "i810" à la place de "intel" dans la section device de leur xorg.conf

C'est pour ça que j'utilise la version "etch" du driver i810, en utilisant cette version la sortie Xv fonctionne avec compiz avec les lecteurs Gxine/mplayer/gmplayer/kplayer (par contre ça bug avec vlc et totem)
 
il sufit de rajouter:

dans /etc/apt/preference pour les utilisateurs de debian et d'avoir les repository de etch dans le sources.list

Pour les problèmes de gestion de l'open GL ce n'est pas un problème de pilotes intel mais un problème complet dans l'architecture de l'accélération opengl sous X.org avec tous les pilotes libres. J'explique :
 
Pour l'accélération 3D, les pilotes X.org libres (intel et ati principalement) utilisent le logiciel mesa qui est une implémentation libre d'openGl et plus particulièrement l'infrastructure DRI (pour direct rendering architecture) qui permet aux pilotes 3D de s'intégrer avec le serveur X, de récupérer l'adresse du framebuffer (une zone mémoire de la carte graphique où est écrit l'image rendue à l'écran) et de dessiner directement sur cette zone (tout ou en partie selon s'il s'agit d'une application plein ecran ou fenètrée).  
De ce fait, le pilote 3D écrit directement sur la carte graphique sans passer par le serveur X ce qui permet cette accélération.
 
Seulement, c'est cette écriture qui cour circuite le serveur X qui pose maintenant problème avec compiz, je vais tâcher de résumer rapidement pourquoi.
 
Pour permettre le fonctionnement de logiciels comme compiz, une nouvelle extension du serveur X a été créée depuis quelques années et commence à arriver à maturité, il s'agit de l'extentension Composite. L'idée est assez simple : historiquement le serveur X affichait directement les données des applications dans le framebuffer. Avec l'extension Composite, chaque application se voit attribuée un espace mémoire dans la carte graphique où elle peut dessiner son contenu (i.e. un "Offscreen pixmap" ), pour afficher le contenu à l'écran, un gestionnaire de composition (donc par exemple compiz) récupère les images de chacune des applications et les affiche à l'écran (soit directement , soit aussi s'il le souhaite en transformant le contenu de ces fenêtre pour ajouter des effets à  l'affichage (comme par exemple la transparence)).  
 
Pour être complet, compiz profite en plus de l'extension GLX_ext_texture_from_pixmap qui lui permet de prendre l'offscreen pixmap de chaque fenetre et de la considérer comme une texture open gl qui est manipulable en 3D à l'aide de l'API OpenGL avant d'être affichée à l'écran.
 
 
Bon maintenant que je pense avoir expliqué un peu l'ensemble le problème est en soi simple à comprendre :
- Les applications 3D qui sont accélérées ne supportent actuellement pas l'extension Composite, ainsi lorsque Compiz s'execute, toutes les fenetres des applications sont redirigées et gérées par Compiz sauf les applications 3D qui écrivent directement à l'écran en outrepassant compiz et ainsi leur contenu s'affiche au dessus de toutes les autres fenêtres et aucun des effets de compiz ne s'applique à ces fenetres.
 
Bien entendu, les développeurs de X.org des pilotes intel et de mesa sont au courant de ce problème mais il demande un travail très important modifiant l'architecture de Xorg qui est en cours depuis plus de 6 mois.
 
Pour plus d'explications :
-> le blog d'un développeur de chez red hat qui travaille sur la correction du problème et qui reexplique (mieu que moi) ce que j'ai tenté de détailler là :
http://hoegsberg.blogspot.com/2007 [...] ering.html
 
-> Le bug permettant de suivre l'évolution du problème :
http://bugs.freedesktop.org/show_bug.cgi?id=8732
 
-> Le détail (très technique) de ce qui est nécessaire pour corriger le problème :
http://dri.freedesktop.org/wiki/Di [...] tedWindows
 
bonne lecture
 
Fabien
 

> fabs0028
 
Merci pour ces précisions intéressantes.    
 
 
J'en profile pour relever un passage assez édifiant sur le blog du développeur Red Hat :

 
Voilà, voilà ; quelque chose me dit que les ventes de chipsets graphiques à destination de GNU/Linux ne sont pas prêtes de baisser du côté de nVidia...    

Wow et bien voilà, le thread est arrivé à mâturité. Merci bcp à fabs pour ces explications et aux autres, au moins maintenant on sait pourquoi ça marche pas et à quoi s'en tenir.
 
Et comme tu dis thrak, en ce qui me concerne il n'y a plus à hésiter à l'avenir, les config linux ça sera du nvidia et rien d'autre. Tout ça pour ça, dommage quand même...

Je pense que vous etes un peu pessimiste tout de même ...  
 
La solution sera mise en place d'ici moins d'un an ... dans la logique elle devrait être mise en place pour X.org 7.5 qui sortira en fin de cette année ... cela demande de gros changements niveau noyau linux deja qui sont en cours de finition (c'est intégré à la branche mm pour le noyau 26.24 et devrait si tout se passe bien s'intégrer au noyau 2.6.25)  
 
Bon c'est sur après les cartes intel restent plus lentes et de loin que les cartes nvidia mais pour cela ça devrait aller ... il faut juste être encore un peu patient  

Effectivement je suis peut être un peu pessimiste... Mais je me basais sur la citation de thrak, le développeur red hat qui dit clairement que ça peut prendre des années avant d'arriver à réaliser tout ça correctement... En fait l'avenir nous le dira, en attendant j'espère ne plus avoir à monter de config linux. Enfin ce que tu nous dit est plus rassurant c'est sûr

From xserver-xorg-core update on Ubuntu Hardy Heron:
 
Version 2:1.4.1~git20080131-1ubuntu8:  
 
  * debian/patches/165_fedora_xserver-1.5.0-xaa-option-inversion.patch:
    - Turn XAA Offscreen Pixmaps off by default, and use
      XaaOffscreenPixmaps "true" to turn them on.  This setting was an
      early pre-EXA HW optimization attempt that didn't pan out; upstream is
      deprecating XAA in favor of EXA generally, and for situations where
      XAA is still in use recommends NOT using this optimization hack, since
      they found it often just made performance worse, and sometimes created
      visualization bugs.  People wishing to gain added performance should be
      experimenting with EXA anyway, not this setting.  (closes LP: #182038)
 
https://bugzilla.mozilla.org/show_bug.cgi?id=411831#c62

 
ouah, ça vaudrait le coup que tu mettes à jour les pages wikipedia correspondantes (X.org, mesa, EXA...)

 
je n'ai rien vu à ce sujet dans la version 2.6.25 du noyau, si ?
http://kernelnewbies.org/Linux_2_6 [...] 501ee4bfab

j'up ce topic car mon nouveau PC n'est qu'intel et je trouve la CG vraiment lente pour le moment...

xorg.conf ?
version du serveur xorg ?
nom exacte du chipset graphique ?

xorg.conf : http://pastebin.com/f4ed4533b
version 7.3 (Debian SID 64bits)
nom exact : x3000.
 
 
Merci

Option          "AccelMethod"           "EXA"
 
passe en XAA

j'ai tente cela sans resultat interessant

je confirme toujours pareil.
Video en plein ecran impossible
Pourtant Dri et tout le toutim fonctionne je ne comprend pas, je pensais justement qu'avec Intel ca passerait tout seul...

comment ça se fait que les drivers EXA sont pas au point sur ce chipset ?

Merci pour les compliments
Si je trouve le temps, je mettrai à jour wikipédia !
 
Sinon le moment ou exa sera vraiment parfait niveau accélération s'approche.
 
En gros il manque surtout le nouveau gestionnaire de mémoire à intégrer au noyau linux (et non ce n'était pas dans le 2.6.25 et je ne sais pas trop non plus si ca sera dans le .26)
A coté de ça, le développement du "modesetting" dans le noyau est aussi en cours ... cela va permettre d'éviter les multiples flash de l'écran au démarrage (car le mode graphique choisi pour l'écran est géré en différents endroits actuellement et qu'ensuite ce sera géré dans le noyau avec un client en espace utilisateur pour décider du mode à appliquer)

Ouais bah la je ne sais pas trop quoi faire.
Mon vieux PC d'il y a 5 ans est clairement plus veloce...

X.Org 7.4 sortira ce mois ci avec support du kernel mode-setting et DRI2 Direct Rendering mais tous deux reservés dans un premier temps aux chips INTEL...
http://www.phoronix.com/scan.php?p [...] g_74&num=1

\o/
Quand tu dis "réservé", c'est pour le moment, il n'y a rien qui empêche les autres de l'implémenter dans le future non? (moto proof)

oui, c'est une question de temps
ça démarre avec le xf86-video-intel http://www.phoronix.com/scan.php?p [...] &px=NjQxMQ
j'édite mon post

En pratique, de quel genre d'avantages cela nous fera-t-il profiter ?

voir ici : http://www.phoronix.com/scan.php?p [...] ting&num=1

merci    
 
Ça pootre  

finalement, les réglages par défaut du GMA950 sont bien sous hardy ?

Perso j'adore vraiment le GMA 950, mais de préférence sans Compiz (ça peut bugger avec des trucs genre Google Earth). Ça me va puisque je n'utilise plus Compiz sur mes PC.
 
Sous Hardy, RAS du temps que je l'utilisais avant de passer à Lenny.
 

j'ai compiz avec le GMA950 c'est bien plus fluide que ma vieille Radeon 8500 LE (qui a couté seule le prix de l'ensemble carte mère/proco/mémoire que je viens d'acheter!)