PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : nvidia - linux 256.25 x86/x86_64


krass
2010-05-22, 08:22:18
256.25 (beta) Linux x86/x86_64 vom 21.05


*Added unofficial GLX protocol support (i.e., for GLX indirect rendering) for the following OpenGL extensions:
GL_ARB_blend_func_extended
GL_ARB_draw_buffers_blend
GL_ARB_sample_shading
GL_ARB_timer_query
GL_EXT_draw_buffers2
GL_EXT_separate_shader_objects
GL_NV_explicit_multisample
GL_NV_transform_feedback

*Improved Thermal Settings reporting in nvidia-settings to accurately reflect hardware configurations with multiple thermal sensors.

*Fixed an interaction problem between Compiz and 'screen-scraping' VNC servers like x11vnc and vino that caused the screen to stop updating. Fixes Launchpad bug #353126.

*Enhanced VDPAU to add basic support for Xinerama. VDPAU will now operate on a single physical X screen under Xinerama. See the README for more details.

*Enhanced VDPAU's handling of corrupt clips of all formats on GPUs with VDPAU feature set C to be at least as good as on GPUs with VDPAU feature set B. This significantly improves various clips provided by nvnews.net user eamiller.

*Fixed a bug in Xv attribute handling that caused hue, saturation,brightness, and contrast values to be misapplied when using an Xv overlay adaptor.

*Fixed a bug in the XvMC driver that prevented it from working on systems with AGP graphics cards.

*Enhanced VDPAU to clear all VdpVideoSurfaces to black when allocated.This provides more consistent results when using a surface as a reference when no prior decode operation has written to that surface. In turn, this improves the results of decoding some corrupt streams, such as "p_only_no_play" from ffmpeg bug 1124.

*Implemented new APIs to allow sharing VDPAU surfaces with OpenGL and CUDA. The OpenGL extension is GL_NV_vdpau_interop. For CUDA, please see the documentation in the CUDA toolkit for details.

*Worked around a bug where the combination of a GPU with VDPAU feature set A together with specific motherboard chipsets could cause visible corruption when decoding some MPEG-2 streams

*Fixed a bug that prevented the VDPAU overlay-based presentation queue from being used more than a few hundred times per X server invocation.

*Renamed the driver file libGLcore.so.VERSION to libnvidia-glcore.so.VERSION, as a small step towards reducing the filename collisions between NVIDIA's and MESA's OpenGL implementations.This driver file is used by NVIDIA's libGL.so and libglx.so, and should never be used directly by applications.

*Changed the SONAME of libnvidia-glcore.so.VERSION, libnvidia-tls.so.VERSION, and libnvidia-compiler.so.VERSION to be ".so.VERSION", rather than ".so.1".These driver files are only used by other NVIDIA driver components, and are only intended to be used by components of the matching NVIDIA driver version.

*Removed the "-pkg#" suffix from the NVIDIA Linux .run files.The packages are now simply named "NVIDIA-Linux-ARCH-VERSION.run".On Linux-x86_64, a package which omits the32-bit compatibility libraries is also available: "NVIDIA-Linux-x86_64-VERSION-no-compat32.run"

*Simplified the directory structure of the Linux extracted package; most driver files are now just contained within the top level directory of the package.Pass the '--list' option to the .run file for details.

*Removed precompiled kernel interfaces from the NVIDIA Linux-x86 .run file; these were ancient and had not been updated in years.Going forward, NVIDIA does not plan to provide precompiled kernel interfaces with the Linux .run files.However, nvidia-installer and the .run file will retain the ability for users to add their own precompiled kernel interfaces via the '--add-this-kernel' .run file option.

*Compressed the nvidia-settings, nvidia-installer, and nvidia-xconfig tarballs with bzip2, rather than gzip.


x86 (http://www.nvidia.com/object/linux-display-ia32-256.25.html)

x86_64 (http://www.nvidia.com/object/linux-display-amd64-256.25.html)

Lord_X
2010-05-22, 09:26:18
Weiss jemand, ob es für Nvidia Treiber auch KMS Support geben wird?

puntarenas
2010-05-22, 10:35:56
Weiss jemand, ob es für Nvidia Treiber auch KMS Support geben wird?
Wird nicht passieren, da für KMS Kernelfunktionen genutzt werden müssen, die als "GPL only" nach außen geführt sind. Quelle: Hab ich leider keine zur Hand. :(

Ich freue mich auf den Treiber, nachdem meine Systemfreezes (https://bugzilla.redhat.com/show_bug.cgi?id=589007) noch immer und hartnäckiger als gedacht Bestand haben, kann ich mal wieder blinde Hoffnung schöpfen. Ganz allgemein freut mich auch, dass nicht nur Fermi unterstützt wird, da gab es ja im Windowsbereich kurz entsprechende Bedenken, was ältere Karten anbelangt.

Edit: Ich habe den Treiber jetzt mal auf eine Testinstallation gepackt und warte auf den nächsten Systemfreeze. :ulol:
Hier schonmal die auffälligsten Änderungen in Nvidia-Settings:

http://www.abload.de/thumb/bildschirmfoto-nvidiax0xr7.png (http://www.abload.de/image.php?img=bildschirmfoto-nvidiax0xr7.png)http://www.abload.de/thumb/bildschirmfoto-nvidiaxldga.png (http://www.abload.de/image.php?img=bildschirmfoto-nvidiaxldga.png)http://www.abload.de/thumb/bildschirmfoto-nvidiax8f8s.png (http://www.abload.de/image.php?img=bildschirmfoto-nvidiax8f8s.png)

Der PowerMizer hat offensichtlich einen Dachschaden, ich vermute es handelt sich schlicht um einen Anzeigefehler.

Gast
2010-05-22, 20:06:44
Hast du den Treiber unter Fedora 13 oder Rawhide laufen, Puntarenas? Wenn ja, wie bist du vorgegangen? Hast du dir ein RPM gebaut oder den Nvidia-Installer verwendet?

puntarenas
2010-05-22, 20:14:52
Ich habe ein Image von einer sauberen F13RC3-Installation genommen und den Treiber dann einfach schmutzig per Installer draufgebügelt.

Das Experiment war erfolgreich, System ist nach nicht einmal 15 Minuten eingefroren. Auf Nvidia brauche ich also erst einmal nicht zu hoffen, mal sehen ob sich an der Kernelfront was tut...

krass
2010-05-31, 11:57:19
...
Ich freue mich auf den Treiber, nachdem meine Systemfreezes (https://bugzilla.redhat.com/show_bug.cgi?id=589007) noch immer und hartnäckiger als gedacht Bestand haben ...

scheisse punta ;( ... ich dachte deine freezes gehören der vergangenheit an.


hier der nächste beta

nvidia - linux 256.29 x86/x86_64 vom 28.05.


Fixed a bug which prevented use of high performance PowerMizer levels on systems with certain ACPI configurations.


x86 (ftp://download.nvidia.com/XFree86/Linux-x86/256.29/)

x86_64 (ftp://download.nvidia.com/XFree86/Linux-x86_64/256.29/)

puntarenas
2010-06-01, 10:04:37
scheisse punta ;( ... ich dachte deine freezes gehören der vergangenheit an.
Da sagst du was.

I believe this issue was fixed in kernel-2.6.33.2-57.fc13

Das war genau das was ich hören wollte und als das im Bugreport gesagt bekam, war ich überglücklich. Ironischerweise war das auch just während eines Zeitraums, in dem das System mal wieder stabil und ohne einzufrieren vor sich hinzuckelte. Heimtückische, ver@*+kte Sch#@(e, um so härter hat mich dann der nächste Freeze getroffen.

Wie es aussieht, sind wohl auch nicht alle P965-Boards betroffen. Womöglich hat Gigabyte mal wieder im BIOS gezaubert, was weiß ich. Auf jeden Fall scheint die Gesamtkostellation derart selten, dass ich nicht so recht an große Bugfixing-Anstrengungen glaube. Zu allem Überfluss jammere ich ja mit einem "Tainted Kernel" herum und mit dem freien Treiber gibt es keine Probleme.

Naja, früher musste ich mein System für neue Windowsversionen updaten (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=484618), heute also für neue Fedora-Releases. Ich betrachte das als Fortschritt. :smile: :usad:


hier der nächste beta

nvidia - linux 256.29 x86/x86_64 vom 28.05.

Den habe ich gleich mal installiert. Es gibt oberflächlich wieder was Hübsches zu sehen, man darf jetzt das Monitoring gezielt deaktivieren:

http://www.abload.de/thumb/bildschirmfoto-nvidiaxuqza.png (http://www.abload.de/image.php?img=bildschirmfoto-nvidiaxuqza.png)