NVIDIA Developer Talks Openly About Linux Support

[wiresquire]

Thought the people in the Linux forum might be interested in this article from Phoronix.

Interesting, but nothing really surprising.

ws

[crisalide]

Within the next year, .... I expect we'll also expose VDPAU interoperability with OpenGL and CUDA/OpenCL.

Great!

[JaXXoN]

Thanks for the link - interesting read.

So if there seem to be so many problems with different versions of glibc
and libstdc++, then why not compiling&linking statically? That would make the
binary 1 to 2 MBytes larger, but that's not a big issue, IMHO. Concerning
distribution, this also should not be an Issue - there are always some
discussions going on that statically linking against glibc might be an
issue, but this is complete non-sense in my opinion, i.e. you for sure link
in crt*.o statically and also most typically libgcc.a, so why should there
by any difference for libc.a? However, IANAL.

regards

Bernhard

[woelfel]

I really apologize that RandR 1.2+ support on NVIDIA has been so long in coming. When it first came up, the urgency didn't seem very high, because we already had our dynamic TwinView support. Then, numerous other projects came up and took precedence. Since then, RandR has suffered from hovering just below the cut-line.
I really hope we can get back to this soon.

In other words, NVIDIA is still not working on this. What pity!

Does NVIDIA have any intentions to provide Kernel-based Mode-Setting support?
Nothing definite, no, but we do get a lot of requests for it and it is something I hope we can pursue in the future.

Same pity here.

IMO RandR and KMS are the most important not-yet-implemented features for every day desktop users. Much more important than VDPAU or 3D-acceleration. But apparently not a selling argument for graphics cards. The OS AMD driver (radeonhd) has both. Unfortunately, it seems it will still take a couple of months (weeks?) until the radeonhd driver is stable enough for every-day use. But it looks like its time will come. And NVIDIA is stuck with their closed-source beast:

AMD was able to open source and/or document a lot by separating out the parts they couldn't legally disclose.[...] Could nVidia use the same strategy?

A similar strategy might be technically possible for NVIDIA, but for better or worse I think it is quite unlikely.

Funny... until now NVIDIA ruled in the linux world. Soon this will change, and I suspect my next graphics card will be made by AMD. And I don't mind closed-source drivers. But I want drivers that support "standard" features!

[AaronP]

Statically linking to glibc is not an option due to differences in things like the malloc implementation. There are cases where libGL allocates data that it returns to the application, which frees it using Xfree. If the library is statically linked, the malloc tracking information for that allocation may be wrong. There are countless problems like that that make it unfeasible to statically link it.

[dougdeep]

Agreed, XRANDR is the most important feature to everyday desktop users. Without it, nvidia users can't take advantage of OS tools for changing resolution and other settings. It's far more urgent for laptop users, who may need to continually switch between different monitors/outputs.

I'm thrilled to have Nvidia on my HTPC for vdpau support. But on my Thinkpad, I wish I still had plain old Intel GMA, it was much easier to use day to day.

[packermann]

So far, sure it would be a nice to have if RandR and KMS would work, but I really don't see the urgency for this. I'm using a thinkpad, for switching monitors, I installed disper and configured it to be triggered by Fn-F7... works flawlessly. KMS would be nice for faster switching to the console, ok... but seriously, how often do you do this? There are other flaws in the driver, that should be priorised. For example, since some version (somewhere around 180.something) initialization took longer and longer. Now, with 190.40 for example, I'm waiting over 30 seconds for the driver to initialize to get to X. I had to tweak the timeouts for gdm to get to a loginscreen (thx to nvfuchs for the hint). There are still huge slowdowns on resizing windows, tearing is another anoyance. These are known problems, posted here several times by different people. NVidia, please track down these problems first before heading to new features.

[thefirstm]

Originally Posted by woelfel

IMO RandR and KMS are the most important not-yet-implemented features for every day desktop users. Much more important than VDPAU or 3D-acceleration.

If you like KMS and XRandR 1.3, then use Nouveau. It has these, but completely lacks any 3D support or VDPAU support.

[davelaser]

Originally Posted by woelfel

IMO RandR and KMS are the most important not-yet-implemented features for every day desktop users. Much more important than VDPAU or 3D-acceleration. But apparently not a selling argument for graphics cards. The OS AMD driver (radeonhd) has both. Unfortunately, it seems it will still take a couple of months (weeks?) until the radeonhd driver is stable enough for every-day use. But it looks like its time will come. And NVIDIA is stuck with their closed-source beast:

Funny... until now NVIDIA ruled in the linux world. Soon this will change, and I suspect my next graphics card will be made by AMD. And I don't mind closed-source drivers. But I want drivers that support "standard" features!

What a bunch of rubbish. RandR would be nice but KMS vs hardware video acceleration? I don't see how that's even in the same ballpark.

Try using any of the other drivers sometime, the difference between X with the nvidia drivers and X with anything else is night and day. The nvidia driver is an example of probably one of the most successful, stable and well implement closed source applications for linux.

[dougdeep]

Originally Posted by packermann

So far, sure it would be a nice to have if RandR and KMS would work, but I really don't see the urgency for this. I'm using a thinkpad, for switching monitors, I installed disper and configured it to be triggered by Fn-F7... works flawlessly. KMS would be nice for faster switching to the console, ok... but seriously, how often do you do this? There are other flaws in the driver, that should be priorised. For example, since some version (somewhere around 180.something) initialization took longer and longer. Now, with 190.40 for example, I'm waiting over 30 seconds for the driver to initialize to get to X. I had to tweak the timeouts for gdm to get to a loginscreen (thx to nvfuchs for the hint). There are still huge slowdowns on resizing windows, tearing is another anoyance. These are known problems, posted here several times by different people. NVidia, please track down these problems first before heading to new features.

And I've done this. But now you have to setup disper, save off configuration files for each display mode you come up with, and of course edit acpi scripts to call disper from the FN-F7 button. Yeah, that was all seemless.

I hate to make this comparison, but on Windows and OSX, there's always one common way to change resolutions. On Linux, it varies.

[adamk75]

Originally Posted by woelfel

IMO RandR and KMS are the most important not-yet-implemented features for every day desktop users. Much more important than VDPAU or 3D-acceleration. But apparently not a selling argument for graphics cards. The OS AMD driver (radeonhd) has both.

FYI, radeonhd does not support KMS. The open source 'radeon' driver, however, does support both xrandr and KMS.

[ppurka]

Originally Posted by dougdeep

I hate to make this comparison, but on Windows and OSX, there's always one common way to change resolutions. On Linux, it varies.

You forget that someone, usually the vendor from whom you bought your machine, has pre-configured your windows to work like that.

You never get an out-of-the-box experience if you try to do everything yourself, without pre-configured windows.