Wayland performance [LWN.net]

Wayland performance

Posted Apr 16, 2012 19:55 UTC (Mon) by rvfh (subscriber, #31018)
In reply to: LFCS 2012: X and Wayland by renox
Parent article: LFCS 2012: X and Wayland

> Where did you see this pointed out?

In the article.

Basically, X does some buffer copying, so if your screen is 1920x1080@60Hz and assuming 32-bit RGB, this means copying about 8MB every 16 ms, or 480 MB/s of traffic. That's for one copy only, of course.

Wayland will just allocate a buffer straight from the graphics stack (DRM) which will be filled by the application and rendered by the graphics card with zero-copy.

(Log in to post comments)

Wayland performance

Posted Apr 16, 2012 20:33 UTC (Mon) by renox (subscriber, #23785) [Link]

>> Where did you see this pointed out?
>
>In the article.

Where in the article?

>Basically, X does some buffer copying,

Not with the DRI2 extension AFAIK: X allocates a buffer in the GPU video memory which can be used by a client without copying like Wayland (not 100% sure: DRI2's documentation is hard to read).

Wayland performance

Posted Apr 16, 2012 20:51 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

X now uses texture_from_pixmap extension to transparently (for applications) move pixmaps into GPU. But it's not entirely transparent, so we get ugly tearing in video and overhead of compositing is noticeable.

Wayland performance

Posted Apr 17, 2012 17:15 UTC (Tue) by rvfh (subscriber, #31018) [Link]

> Where in the article?

Third paragraph:
> From an application's perspective, there aren't that many changes. It still talks to the server for geometry handling and still talks to the kernel or server to create its graphics. But the protocol is different, which will save a bunch of time, system complexity, and memory, Packard said.

> Not with the DRI2 extension AFAIK: X allocates a buffer in the GPU video memory which can be used by a client without copying like Wayland (not 100% sure: DRI2's documentation is hard to read).

I think you're right, though I am no expert in DRI (only coming these days on SoCs, after years of re-inventing the wheel.)

Wayland performance

Posted Apr 17, 2012 19:56 UTC (Tue) by renox (subscriber, #23785) [Link]

Thanks for the indication of the paragraph, I think what he's talking about is that Weston integrates the window manager (well a part), the display server and the compositor so there will be less IPC so it's more efficient from this point of view, AFAIK nothing prevents an X server to be implemented in the same way if this is really a big performance improvement..

Wayland performance

Posted Apr 17, 2012 20:28 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

It means getting rid of X window manager as a separate entity and embedding it into the X-server process.

At which point you might start thinking that it's easier to throw away X-server completely out of your core and instead relegate it to the status of ordinary application. That's what Wayland does.

Wayland performance

Posted Apr 27, 2012 7:16 UTC (Fri) by Duncan (guest, #6647) [Link]

Also from the article, current (tho incomplete) wayland code is ~10KLines, xorg is half a million. Now surely the klines of wayland code will increase, but a lot of that xorg code is legacy stuff that (approximately) no one uses any more. So even allowing for a 10X increase in lines of code (the first 90% of the implementation's only 10% of the code, or 80/20, or whatever), wayland should still be far smaller, thus being far more memory efficient.

And even where memory isn't a problem on today's multi-gig-memory machines, smaller code means more of it fits in caches closer to the processor, where it's MANY times more efficient to access and thus faster running! =:^)

Of course, the biggest benefit there will only happen once most/all normally running apps are wayland, not X. But with a 50:1 or even if wayland's code grows by 10X, a 5:1 size difference, it won't take replacing /much/ of that legacy X code with wayland, to break-even and start the reduction, even while the majority of apps are still X. So we may begin to see memory benefits sooner than one might have expected, even while most apps remain X.

Not that this will be the major benefit, but it's one of them.

I think the biggest user visible improvement will likely be in stability, tho. There's a LOT of legacy code in X, and thus a lot of dingy corners for bugs to lurk in. Additionally, wayland is designed from the ground up to current kernel driver and mode-setting reality, while that functionality has sort of been bolted on to X. The more "direct drive" nature of wayland as well as the vastly smaller code should make tracing and eliminating bugs FAR easlier, at least for the first half-decade or so. After that, I guess we'll have to see, as X really HAS been great at adapting to the changes underneath and around it, and for any replacement to last as X has for over three decades and continue functioning as well as X still does today, despite all that legacy, is going to be quite a challenge indeed, to match!