NVIDIA Pre-Releases A New Linux Driver

[LLStarks]

no, it shouldn't.

supporting optimus' on-the-fly GPU switching is not the problem nor the immediate goal.

the problem is that the nvidia GPU can't be used at all unless developers find a way to reliably feed nvidia GPU output through the intel GPU framebuffer.

[schmidtbag]

i'm a little annoyed about the driver update because now i have to edit my nvidia gpu graphing program AGAIN. every single time nvidia releases a driver they decided to change how nvidia-smi displays its results. i wish they'd just stick with 1 layout.

[schmidtbag]

i'm a little annoyed about the driver update because now i have to edit my nvidia gpu graphing program AGAIN. every single time nvidia releases a driver they decided to change how nvidia-smi displays its results. i wish they'd just stick with 1 layout.

actually as another problem, nvidia-smi now doesn't tell me my gpu usage anymore. why am i LOSING features?

also, i'm not sure if this is xorg 1.10 or the new nvidia drivers but now whenever i shade a window my whole computer locks up for about 2 full seconds. i am not happy with these new updates.

[thefirstm]

There is also at least one change that isn't in the changelog. They fixed the problem that prevented the driver from compiling against the 2.6.39 kernel.

[BlackStar]

also, i'm not sure if this is xorg 1.10 or the new nvidia drivers but now whenever i shade a window my whole computer locks up for about 2 full seconds. i am not happy with these new updates.

Oh great, fglrx used to have this bug a couple of years ago. It will probably get sorted out sooner or later.

[hiryu]

actually as another problem, nvidia-smi now doesn't tell me my gpu usage anymore. why am i LOSING features?

also, i'm not sure if this is xorg 1.10 or the new nvidia drivers but now whenever i shade a window my whole computer locks up for about 2 full seconds. i am not happy with these new updates.

When I drag and stretch a window to the full length of the screen, X crashes and I have to re-login and restart my session. Not sure if this is a xorg 1.10 or nvidia driver issue too (I'm using 270.41.03).

This happens on my laptop (GTX 470m) and desktop (GTX 580).

I can suspend compositing, drag the window, and then restart compositing and all is fine. I can live with this until a fix comes out.

[ArchLinux]

The only other change in this 270.41.03 build compared to the last 270.30 Linux driver is fixing a bug that would cause the X.Org Server to hang every 49.7 days on 32-bit systems.

Actually there was also at least some Gnome Shell stuttering bug and some other 10 years old panel bug fixed.

Those minor changes just won't get mentioned in the change log.

[deanjo]

Well got somewhat of a reply finally from Nvidia (AaronP)

Sorry about the confusion. VDPAU feature set D describes improved capabilities in the hardware. However, supporting these features requires software changes that are not yet available. This means that for now, features sets C and D are indeed the same when it comes to the capabilities available to applications.

Still not a confirmation on if it is WebM support but given that the already supported codecs are fairly feature complete I would still have to venture that it will include WebM support.

[gbeauche]

Still not a confirmation on if it is WebM support but given that the already supported codecs are fairly feature complete I would still have to venture that it will include WebM support.

Well, for me, "This means that for now, features sets C and D are indeed the same when it comes to the capabilities available to applications" means the set of codecs covered by both feature sets C and D are the same. i.e. no new codec added in. Most probable thing could be H.264 4K support, H.264 MVC support or API changes to support slice-level details (akin to VA-API) for better error recovery.

[deanjo]

Well, for me, "This means that for now, features sets C and D are indeed the same when it comes to the capabilities available to applications" means the set of codecs covered by both feature sets C and D are the same. i.e. no new codec added in. Most probable thing could be H.264 4K support, H.264 MVC support or API changes to support slice-level details (akin to VA-API) for better error recovery.

That could be however vdpau c hardware already supports H.264 MVC so that wouldn't be the " improved capabilities in the hardware."