NVIDIA Presents Plans To Support Mir and Wayland On Linux

An anonymous reader writes: AMD recently presented plans to unify their open-source and Catalyst Linux drivers at the open source XDC2014 conference in France. NVIDIA's rebuttal presentation focused on support Mir and Wayland on Linux. The next-generation display stacks are competing to succeed the X.Org Server. NVIDIA is partially refactoring their Linux graphics driver to support EGL outside of X11, to propose new EGL extensions for better driver interoperability with Wayland/Mir, and to support the KMS APIs by their driver. NVIDIA's binary driver will support the KMS APIs/ioctls but will be using their own implementation of kernel mode-setting. The EGL improvements are said to land in their closed-source driver this autumn while the other changes probably won't be seen until next year.

Comments

Seems incorrect

[Richy_T]

Seems more like NVidia should be providing some kind of generic global driver and the display software (whichever it may be) should interface with it. I thought we were past the point of each piece of software needing special drivers to interface with hardware. Isn't this the whole point of a modern OS? What happens when "the next big thing" comes alone?

Re:Seems incorrect

[Kjella]

That makes as much sense as saying Intel should provide a magic generic driver so it can run ARM software. nVidia, AMD and Intel all have different hardware implementations, the only thing most people care about is high level DirectX/OpenGL support which is the equivalent of Java on the CPU side. You have an expected functionality but how it's actually implemented in assembler differs from hardware to hardware. To be fair, there is a "thinnest possible overlay" created with Gallium3D which is something like what you ask for. Basically it's something like C for graphics card, one unified interface for shaders. As I understand it in theory the community could create support for OpenGL 4.5 and hardware accelerate it on AMD and Intel chips given the information that's available now. But the open source drivers are ~4 years behind the state of the art at OpenGL 3.3. And that's just for support, the closed source drivers go through tons of optimization for popular games so in practice they're way further behind on performance parity. Why don't they give it away? Competition mainly, just like AMD with Catalyst. Why give Intel a free optimized driver way more advanced than their current one?

Re:Seems incorrect

[spitzak]

I think this is more or less what is happening.

As opposed to how X works now, new drivers will pretty much support "use EGL to draw all over the screen". The window system is *atop* that, it uses EGL to take texturemaps of window contents and draw and compose them into the right places on the screen.

The application making those texturemaps uses EGL as well, to draw into the texture maps. This means the texture map is already in the correct graphics memory for the window system to use it and everything syncs up and you will get results that are close or equal to the speed you would get if you wrote a single program that drew an entire display of overlapping windows.

In X it was more like the window system was the bottom level and EGL would draw into a window. Compositing window managers that want to use EGL have to create a big fake window that covers the entire screen, and had to add a lot of other kludges to work around the millions of assumptions that a window and any changes to it's pixels was instantly visible on the screen.

Re:Seems incorrect

[kenaaker]

It seems like there's a strong possibility that the replacement for remote X-Windows could be something conceptually simpler but could require one massive block of processing. (And I think Nvidia is most of the way there).

The remote presentation could all be done with an mpeg 4 stream, direct from the GPU. That chooses one standardized mechanism for presentation, and I think it should be sufficient for almost any sort of application. The presentation space in the GPU would be written with a number of APIs, but as the time came to present that image to the user, the GPU would transform the presentation space into an appropriate mpeg 4 frame and push it out some serialization interface for delivery to the end device.

The only additional interface required is for the user input device, which is non-trivial, but doesn't require the brute processing capacity that presentation requires.

Speculation, I know.

Re:Ob

[Anonymous Coward]

Does systemd have its own display stack?

Shh! They'll hear you and think it's a good idea.

Hopefully the Steambox will Help

[Mr_Wisenheimer]

Linux driver support has always been a huge weakness for home users. Apple fans tend to use mostly Apple-approved hardware and everyone makes a driver for Windows. Linux support has always been an afterthought or a non-thought, often with enthusiasts hacking together support for a device months or even years after it is on the market.

I don't know too many people who use Linux as a primary home OS, but for those that do, good driver support is a must. It probably won't get Linux any more share of the OS pie, but it will mean less pulled out hair for the 1% or so of people who run it on laptops or workstations.

Re:Hopefully the Steambox will Help

[rahvin112]

Not in my experience, when was the last time you used Linux? My experience is that Linux often has the driver first and longer than windows. There are only a few areas in hardware where this isn't true. For example, windows server 2012 ripped out the entire scsi driver system. Try to install it on older SCSI based hardware and you will need a driver disk for 2008 because the abolished the entire driver tree for the older hardware. This isn't the only example, only the most recent I've run into. These days Linux often supports hardware or features months or even years before Windows.

Bluish People

[eric31415927]

I remember watching blue people in flash videos.
At the time, I blamed NVIDIA / vdpau.
However it was really Adobe Flash crossing red and blue that caused me to see smurfs everywhere.

Re:Bluish People

[sconeu]

If I saw blue people, I just figured it was an Intel ad.

Re:Ob

[UnknownSoldier]

/Oblg. "Good 'ol Emacs" http://xkcd.com/378/ :-)

Examples, please

[Sycraft-fu]

Because I haven't seen a hardware release where Windows drivers didn't ship with the product. I see a reasonable bit of hardware too, what with doing IT support for a living.

Re:Ob

[Anonymous Coward]

Don't kid yourself: the plan is to move the terminal emulation layer for the virtual terminals from inside the kernel into systemd. This new support will likely use OpenGL for accelerated text rendering. So you're not that far from the truth.

Re:Ob

[styrotech]

I think systemd should go and develop its own kernel.

Re:Time to fork Wayland...

[WorBlux]

GPLv2 isn't broken. And how do you stop wayland from using non-free *GL implementations. The very idea of wayland was to offload as much as possible to drivers via KMS and EGL. You would have to stop end-users from installing these kms and EGL binary implementations. In fact waylands done a great thing by convincing proprietary driver writters to partially port to open interfaces, which should make the open driver effort easier.