NVIDIA Developer Talks Openly About Linux Support

[greg]

Why? Standard/kernel developers/community approved way to do things inside the Linux kernel is not important here? Debugging facilities, very small term improvements (i.e. look KMS feature lack time frame on Nvidia), fast community driven bug fix response time, etc...

There is no "approved" or "correct" way, especially when it comes to Linux. APIs and interfaces change *all the time*. And there isn't just Linux, but FreeBSD and Solaris as well, which are interested in GPU support.

On the other side, you haven't agree in the fact PhysX and other really interesting things from Windows drivers don't exists on Linux drivers

PhysX will hopefully go away soon-ish and that's NVidia's fault. What else is missing in the Linux drivers?

[greg]

From my discussion with the X devs pushing KMS, it solves a number of problems ...

More importantly it allows the X server to run without hardware access, i.e. as a user instead of root.

According to NVidia developers the drivers already implement most of the features of what's known in the free drivers as KMS, but a framebuffer driver is missing.

[some-guy]

I only have one real question.

Why can't nvidia release docs on older generations like nv0x-nv3x ?

That would allow them to eventually drop support from their own drivers and just let the nouveau team to keep support for them. Also it's not like there's anything to learn from cards that old.

[mtippett]

Reliable suspend/resume, duh. Since switching to Karmic beta, my laptop (intel GM965) hasn't hardlocked during either operation once, something I can't say about Hardy or Jaunty, which would stop suspending or hardlock sometime during suspend/resume after the 4th iteration. Now only if plasma-desktop was as reliable...

KMS and reliable suspend/resume are not directly related, I'd go so far as to say completely unrelated. I'd hazard a guess that it is simply a better driver (ie: banging the bits of the HW), and not a better architecture.

Yes, I concede it does make it easy that the kernel tells the graphic driver directly that the event has occured. Userland notification is haphazard at best, but with effort can be managed. On discrete cards we may have to deal with 1 or 2 GB of active framebuffer memory that can't be moved to active kernel memory, and you can't page out kernel memory. You *will* need a userland proxy to allow swapping, this is way easier without KMS. Intel will never have this problem due to UMA,

On the AMD side, we have invested a lot of effort recently in getting suspend/resume considerably more solid, and will continue to invest for next few months. My Compaq 8510w hasn't had a suspend or hibernate crash with Karmic for a few months now (and I'm a habitual dist-upgrader). The fruits of this labour should be publicly visible now, and will continue to improve over the next few months.

Regards,

Matthew

[mtippett]

I only have one real question.

Why can't nvidia release docs on older generations like nv0x-nv3x ?

That would allow them to eventually drop support from their own drivers and just let the nouveau team to keep support for them. Also it's not like there's anything to learn from cards that old.

Andy covered it in his response (hmm, me talking on behalf of NV, well, my response isn't really NV specific but more corporate economics)...

There is still a high cost of converting internally facing docs into publicly consumable docs, and then the ongoing support to get people to understand what is going on.

This can easily cost months or years of effort within an org (engineer time, documentation creation time, review time, legal review, ip review). And all this (most likely $100,000+ in cost) for hardware that they don't get revenue for. The economics don't match.

Regards,

Matthew

[dlang]

Can you expand on your view on simplification?

From my discussion with the X devs pushing KMS, it solves a number of problems
o Flicker on boot (desktop experience - RH is investing here)
o BSOD like behaviour (don't laugh, it's coming with KMS)
o Removes the other kernel drivers from the picture (directfb, vesafb/radeonfb, etc). The X devs are open to former kernel fb devs joining them, but don't really care to directly include their interfaces.
o Some say reliable suspend/resume (see my upcoming response for that).

with KMS the X.org code doesn't need to know how to configure every possible video card in existance. Instead it uses a standard interface to ask the kernel to configure things for it. The kernel already needs to know how to do this to support other things like fb, and text consoles. With KMS X.org does not need to duplicate this code, making the X.org code simpler.

In addition, I believe (but could be wrong) that a lot of the differences between different cards boil down to the mode selection and initialization. if that is moved out of X.org into the kernel the X.org drivers get significantly simplified.

That isn't the Linux way. All your devices get moved to the new API or they are dropped from the kernel. Can't suck and blow at the same time.

X.org is not linux, but linux is the most used OS that they are supporting (and X86 hardware by far the fastest changing) so it's not a case of Linux forcing them to do something.

I would not at all be surprised to see that in a few years the *BSD systems (and x86 Solaris if it is still around) add a compatible KMS interface as well, or be in the situation where new video cards are released, the configuration gets added to Linux, and the cards work great with existing X.org drivers (using KMS), but on systems that do not use KMS they won't work for some significant amount of time until the X.org driver gets enhanced to know about that specific card.

[mtippett]

More importantly it allows the X server to run without hardware access, i.e. as a user instead of root.

The 2D part isn't really the problem in that picture banging registers for displays is not much of a problem, it is the client drivers (ie, the OpenGL and OpenCL clients) that can construct instruction packets to copy system memory around. Those clients construct most of those packets up in userland and so potentially can do nasty things.

There is still the risk with SEGV's and other escalation techniques, but that is a code quality issue that is partially addressed via other mechanisms (non-exec stacks, etc).

According to NVidia developers the drivers already implement most of the features of what's known in the free drivers as KMS, but a framebuffer driver is missing.

KMS is an interface (ioctls, kernel calls, etc) , mode-setting in kernel is a feature. It's close but NV definitely doesn't support KMS.

Regards,

matthew

[dlang]

KMS and reliable suspend/resume are not directly related, I'd go so far as to say completely unrelated. I'd hazard a guess that it is simply a better driver (ie: banging the bits of the HW), and not a better architecture.

I think it's a bit more than involved than this. the fact that many video cards have write-only functions where only the process that did the write can know what the state of the card is makes it _very_ hard for the OS to do a reliable suspend/resume because it can't really know the state of the hardware once X has started changing things.

David Lang

[smitty3268]

KMS and reliable suspend/resume are not directly related, I'd go so far as to say completely unrelated. I'd hazard a guess that it is simply a better driver (ie: banging the bits of the HW), and not a better architecture.

Yes, I concede it does make it easy that the kernel tells the graphic driver directly that the event has occured. Userland notification is haphazard at best, but with effort can be managed.

I believe that's the key right there. I'm pretty sure I have seen quotes from the OSS devs saying that it will improve suspend/resume, as a side-effect of having a much simpler hardware management system.

If AMD really thinks they can work out all that tricky interaction stuff, then more power to them. But the OSS devs don't have the manpower when a seemingly better solution existed. It just makes so much more sense to manage hardware from the kernel rather than some userspace program, at least in my head (Disclaimer: not a video driver developer )

KMS isn't something I view as all that important by itself, but I would think the binary drivers would also want to implement their own similar system inside their kernel module, just like they have their own alternative to Gallium3D.

[dlang]

I believe that's the key right there. I'm pretty sure I have seen quotes from the OSS devs saying that it will improve suspend/resume, as a side-effect of having a much simpler hardware management system.

If AMD really thinks they can work out all that tricky interaction stuff, then more power to them. But the OSS devs don't have the manpower when a seemingly better solution existed. It just makes so much more sense to manage hardware from the kernel rather than some userspace program, at least in my head (Disclaimer: not a video driver developer )

KMS isn't something I view as all that important by itself, but I would think the binary drivers would also want to implement their own similar system inside their drivers, just like they have their own version of a Gallium3D system.

the ATI drivers are starting to be moved to KMS. second, immediatly after the Intel (who hired many of the developers) drivers