User: Password:
|
|
Subscribe / Log in / New account

The way to Wayland: Preparing for life After X

The way to Wayland: Preparing for life After X

Posted Nov 18, 2010 14:26 UTC (Thu) by ortalo (subscriber, #4654)
Parent article: The way to Wayland: Preparing for life After X

Seriously. From what I remember of KGI as an unsuccessful attempt at improving the state of graphics on Linux/Unix, graphics hardware support was a seriously difficult issue:
- documentation was not available;
- these pieces of hardware were huge, with numerous and variable features (combined with the fact that the most advanced features were deliberately left non-documented).

Kernel fb support may not necessarily imply that the graphics hardware is documented enough to support advanced features (esp. wrt performance). OpenGL ES some 3D support, but doesn't it also implies a restricted set of advanced graphics operation?

Maybe I am underestimating KMS + OpenGL/ES. That's a really pretty good start certainly: but is it *enough* to provide the experience that people like Shuttleworth seems to expect?

If no, how are we going to convince manufacturers to provide better documentation of their hardware? (X as a project was doing a decent job at that - probably in part due to its maturity and overall success.)

We need to ensure that life after X will provide us with something really worth the effort to switching (not even counting the network transparency feature drop - which I would personnally linger for).


(Log in to post comments)

The way to Wayland: Preparing for life After X

Posted Nov 19, 2010 4:53 UTC (Fri) by drag (subscriber, #31333) [Link]

Think about it:

Are you going to be happy that Linux cannot use the processor in your computer and get the same level of performance as other OSes without proprietary drivers?

The things to remember is:

The GPU is now part of the computer architecture. It's not just about driving graphics acceleration anymore. It's increasingly used for a wider variety of workloads and GPUs are now being integrated into processors themselves. Both AMD and Intel now are releasing processors that include GPUs on die. The idea that Linux cannot support the processors being shipped natively and requires proprietary drivers to get acceptable performance is, hopefully, unacceptable for most people.

So GPU drivers are still needed. Newer solutions like Gallium3D are needed. Were the drivers can support multiple APIs effectively. This is different from X model were you have to have a DDX driver for 2D and 3D DRI driver for 3D. This is really quite a broken design, especially since modern hardware no longer has any 2D acceleration except through emulation support and that is going away eventually, too.

> Maybe I am underestimating KMS + OpenGL/ES. That's a really pretty good start certainly: but is it *enough* to provide the experience that people like Shuttleworth seems to expect?

That is just what is needed to drive Wayland itself. Minimal requirements.

With this approach the display manager is just another application and is not very special in terms of what it requires to operate. Other applications can use different APIs for acceleration. Wayland is just a application that collects their output and puts it into a single image that is displayed on the screen.

> If no, how are we going to convince manufacturers to provide better documentation of their hardware? (X as a project was doing a decent job at that - probably in part due to its maturity and overall success.)

Intel is supplying open source drivers. That's right about 70-80% of the desktop market right there. If all we gave a crap about was providing support for the majority of potential users they could stop right there.

AMD/ATI are not providing their own open source drivers and are also giving out documentation. And Nvidia is being asshats as usual about being open, but the open source driver is progressing at a good pace regardless.

For the desktop and server market that covers 99% of all situations. Via is still lurking in the wings, but that's about it.

For embedded systems it is much more difficult. But the Wayland model offers significant advantages for them in terms of efficiency and memory footprint over X.

Think about why Android does not use X.

> We need to ensure that life after X will provide us with something really worth the effort to switching (not even counting the network transparency feature drop- which I would personnally linger for).

X and Wayland are not mutually exclusive.

Remember X is a network protocol and the X server just displays the output from X clients. Would you like it if your web browser had to control the hardware directly to render Web pages?

Anyways. X is not very good when compared to more modern protocols like ICA or Spice.

Nobody can do anything like:
http://www.gotomypc.com/remote_access/remote_access

With X Windows. It's just impossible. It's far too inefficient.

Look at the name at the bottom of the page. Notice that: Citrix?

They make a huge amount of money providing support for thin clients and remote applications for corporations all over the planet. Do you know why they can make so much money?

Partially because X sucks so badly. There are ways to deal with remote applications that are probably better.

With SPICE they can get performance better with Linux-KVM then ICA through the use of virtualization and special 'virtual' hardware. So they are going at a level much lower then X, VNC, RDP, or ICA runs at and they are getting better results.

http://www.youtube.com/watch?v=nRliEV7GnF0
http://www.youtube.com/watch?v=uvfkj8V6ylM

I don't know how that can be applied to Wayland, but certainly something can be figured out. They made ICA and RDP work for Windows after all! Anything is possible!

The way to Wayland: Preparing for life After X

Posted Nov 19, 2010 9:08 UTC (Fri) by ortalo (subscriber, #4654) [Link]

If we can really cover 99% of users concerns with Wayland and KMS+OpenGL/ES, I agree the evolution is required.
It's just that I am a little doubtfull about that 99%. I would feel better with a double check of hardware feature vs. register-level documentation for all important targets(even for so-called well-documented or well-supported chipsets like Intel). Code availability is important, but documentation is too IMHO.

Concerning VNC/RDP/ICA etc. Well, from my own experience (I have been working for +5 years in an organization that made a general switch to Citrix 10 years ago), Citrix success is not only tied to the display client efficiency.
It is primarily the administration infrastructure for Citrix servers and the (supposedly good) idea of "thin clients" (ie. no administration overhead on client PCs) that seems to be the key issue for IT managers selecting such architectures. (In some sense, it is also a sort of reversing the movement towards distributed computing of the nineties to go back to centralized computing.)
The display client efficiency was a requirement, but from what I have observed, it was not alone the key feature for selecting that solution.

The way to Wayland: Preparing for life After X

Posted Nov 19, 2010 10:44 UTC (Fri) by job (guest, #670) [Link]

I expect SPICE to perform well over low latency, high bandwidth links. I'm not sure it's a good idea for high latency, low bandwidth links such as WANs, but I've not actually looked at it so please take this as idle speculation.

The way to Wayland: Preparing for life After X

Posted Nov 20, 2010 18:02 UTC (Sat) by mfedyk (guest, #55303) [Link]

will these same spice demo work over a dsl connection? please come back when it does.

also lets stop talking about x twiddling bits on the hardware. with KMS that's not happening anymore and wayland won't work without KMS anyway.

I think we are going to regret our wayland future.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds