Reprise du message précédent :
ça marche!!!!!!!
j'ai trouvé!!!!
Voici un exemple:

 
Avec ça:
Gpu en mode on demand une fois sur secteur. (ça change bien de mode quand je bascule de 3D au bureau)
Gpu en mode autonomie max une fois sur batterie!
Les possibilités sont:

 
A mettre en première page je pense!

Ca ne marche que pour la puce d'un portable ?
 
Avec la ligne de code donnée en première page ma 8800GT change de fréquence à la volée.

Quelle ligne de commande???  

1ère page :
 

Heu non mais ça c'est juste pour activer l'overclocking et changer les fréquences de ces paliers! Moi le problème c'est que ça ne basculais pas entre ces paliers que tu changes et que tu ne peux pas forcer un mode de base. (or pour un gpu mobile en batterie c'est bien de pouvoir bloquer...)
C'est à dire que là ça fait enfin ce que ça a toujours fait sous windows:
Basculer en 2D quand le gpu n'est plus utilisé quand je suis en ondemand. (chose que normalement ça fait de base mais pas sur ma 6600GO...)  
Pouvoir forcer de rester en 2D quand je bascule sur batterie pour économiser de l'énergie même si je fais de la 3D mais je force le gpu à rester à sa fréquence minimale pour économiser.
 
Voilà c'est tout hein. En aucun cas je ne change mes paliers qui sont déjà définis de base.  

Je confirme, les 180.37 résolvent les problèmes de zombie party, de signaux toussa.
Et ça fonctionne bien sous Xorg 1.6 tout frais de ce matin

Est ce que quelqu'un parvient à activer les modes entrelacés 567i 1080i par xrandr ?
je ne peux le faire que par le panneau de config graphique et ça m'embete car je voudrais faire une appli ou un script qui change la résolution et le refresh rate par rapport à une des caractéristiques de vidéos

 
J'ai remarqué une baisse de fluidité dans les effets 3D depuis la màj vers KDE4.2.1. Bizarrement, ça ne se mesure pas par les chiffres (j'ai toujours mes 60fps constants). Mais j'ai cette impression de non-fluidité que je n'avais pas avant quand je fais tourner le cube.
Tu constates un changement de ton côté ?
 
C'est assez subjectif, peut-être que je me fais des idées...

Humm j'ai pas remarqué de baisse notable, j'ai pas énormément d'effets de bureau, j'utilise le desktop plane et scale, et je ne ressens pas de ralentissement.
 
Si tu es sur un chip mobile, des fois, lorsque ta carte est à ses fréquences de repos, le temps que powermizer la réveille en lui mettant un mode 3D plus adéquat, ça ralentit.

Je ne pense pas que powermizer soit le coupable. Chez moi, il réagit en moins d'1sec à une montée en charge (je n'ai que 2 niveaux que j'ai crées en éditant le bios sur une carte fixe). Si on imagine un problème de powermizer (donc de fréquence) ça se traduirait par une baisse de fps. Hors, j'ai juste "l'impression" de non fluidité, mais les fps sont toujours au max.
Enfin bref, soit je délire, soit c'est un bug qui n'a pas grande importance

Nouveau ( http://nouveau.freedesktop.org/wiki/ ) intégré dans fedora 11
http://fedoraproject.org/wiki/Feat [...] uAsDefault

Débarquement, et pis c'est pas le bon topic

j'avais sauté le chapitre qu'il y avait des depot spéciaux pour ubuntu vdpau et mplayer

 
Pas de changement de mon coté sur puce 8200, j'ai toujours l'écran qui clignotte de l'oeil par moment

bah en fait j'avais tenté d'installer les 180.xx dispos@default au lieu de mes 177.xx, mais ça n'avait pas semble 'til fonctionné lors
de l'activation matos. bref, j'avais pas trop poussé la question.
et pis si c'est juste pour regarder arte pour le moment.  
bref, je vais retenté avec les depots de ce post

Nouveaux drivers:
ftp://download.nvidia.com/XFree86/Linux-x86/185.13/
185.13!

Pas de changelog.  

Raf j'installe

 
En fait, c'est le direct rendering qui pourri complètement l'impression de fluidité. J'ai décoché la case et, oh miracle, la fluidité est de retour même si les fps ne changent pas d'un iota.

180.41 for Linux x86/x86-64 released

Et dispo via le dépôt d'Avenard

Hum, je vaias voir si j'y passe bien que j'en ai pas vraiment l'intéret

Il y a une petite erreur dans le titre et le premier post sur les status des versions.
 

 
http://www.nvnews.net/vbulletin/sh [...] p?t=122606
 
Sachant que le terme prerelease n'est pas très parlant, vu que la définition est "The latest FTP driver from the stable branch".
 

 
Postrelease aurait été plus adapté, ahma.

C'est bien le bordel quoi

Le bordel, ce serait si la beta dont la version est supérieure ne contenait pas forcément les correctifs de la prerelease. Ah mais attends... c'est le cas

La ligne prerelease a été ajoutée récemment (avant il n'y avait que beta et release), et n'ayant pas d'info sur le change log de la 185.13 autant ne pas en parler.

le pire je trouve, c'est la version 71.x pour les geforce la version 96.x pour les Gf4, la version 173.x  pour les Gf5  
ça aurait été trop dur de sortir trois packages nvida-geforce-old/nvidia-geforce-fx/nvidia-geforce-new  

edit: enfin eux au moins ils bossent, ils releasent pas  specs dans la nature en comptant sur les bonnes ames charitables pour faire le boulot a leur place

 
tu parles d'Alex Deucher et de John Bridgman ?

http://www.phoronix.com/scan.php?p [...] &px=NzEzMg
fmpeg supporte vdpau!!!
DOnc mythtv aussi et tout ce qui l'utilise!! YEPPPA.

 (EE) NVIDIA(0): The NVIDIA GPU at PCI:1:0:0 is not supported by the 180.41
 
  on trouve ou le log de ceci ? j'ai le message, mais je ne sais ou est le log  

/var/log/nvidia-installer.log
ou dans  
/var/log/dkms_installer

merci, mais rien, ca doit etre là dedans .
 
[patrick@localhost ~]$ cd /var/lib/dkms/nvidia-current/180.41-1mdv2009.1/build/
[patrick@localhost build]$ ls
conftest.sh*         Module.markers  nv-linux.h   os-agp.c
cpuopsys.h           modules.order   nv-memdbg.h  os-agp.h
dkms.conf            Module.symvers  nv-misc.h    os-interface.c
gcc-version-check.c  nvacpi.c        nvreadme.h   os-interface.h
makefile             nv.c            nv-reg.h     os-registry.c
Makefile@            nv.h            nvtypes.h    README
Makefile.kbuild      nv-i2c.c        nv-vm.c      rmretval.h
Makefile.nvidia      nv-kernel.o     nv-vm.h
[patrick@localhost build]$

Vu que t'as pas utilisé l'installateur de nvidia, t'as pas le log qu'il génère. C'est logique.
Pour le reste, t'as sans doute une geforce6 ou 7. Le bug que tu rencontres a déjà été rapporté par plusieurs personnes.

oui une 6600 LE .  
http://www.nvnews.net/vbulletin/sh [...] p?t=130440

Tien je viens de tester via smplayer et en regardant la vidéo libre big bunny, que j'ai du tearing sur les vidéos malgrès la synchro verticale activée avec les 180.37.

Moi aussi, ya une option dans les drivers, syncho verticale sur [Moniteur] ou [TV], et comme je regarde en général sur la tv, sur l'écran pc ça décroche

J'avais pas remarqué parce que je ne regardais plus de vidéo. Mais là c'est flagrand.
Je viens d'en tester plusieurs et même pb. Pourtant c'est forcé dans les drivers niveau synchro que ça soit opengl et video. Et j'utilise xv comme sortie. Peut-être un pb avec ffmpeg5.  
Sur mon serveur, c'est un crt donc pas de pb, mais sur mon pc portable c'est flagrand. J'ai testé les 180.37, les 185.13 et ça fait pareil... Retour au 180.29 mais bon rien de bien transcendant...  
 
EDIT: si je choisis xvmc ça ne marche pas tien... Je vais remettre les 180.37 et retester.

il faut désactiver composite
 

Xfce se sert de cette option quand on active le composite via le peaufinage de fenêtre non?

sans nvidia composite de xfce marchait .

Perso j'ai le composite explicitement sur enable et j'ai pas de problème de vsync.
Du moins pas tant que je suis en direct rendering. En indirect, c'est plus rapide, mais ça ne respecte plus du tout la vsync.

Je ne sais pas, en fait avec vdpau sans compiz et avec composite j'avais une occupation cpu anormalement élevée et des déchirements.
avec vdpau sans compiz et sans composite j'ai gagné genre 20% d'occupation cpu, et les problemes de déchirement ont disparus.

Tu utilises pas vdpau mais pour xv et composite le probleme est peut être le même.
Et peut être sur les modèles récents genre 9400gt.