Benchmark of Wayland

Sam Spilsbury smspillaz at gmail.com
Wed Nov 17 22:47:54 PST 2010


On Thu, Nov 18, 2010 at 10:39 AM, Corbin Simpson
<mostawesomedude at gmail.com> wrote:
> On Wed, Nov 17, 2010 at 6:28 PM, Toan Pham <tpham3783 at gmail.com> wrote:
>>>>
>>>> This kind of latency due to OS scheduling could be eliminated by
>>>> direct-procedure call. That is, the client passes the GEM buffer to
>>>> the server just like it passes the GEM buffer as an argument to a
>>>> function. In this approach, the compositor is not a process. Rather,
>>>> the compositor is just a function live in the client program. So there
>>>> will be no context switches.
>>>
>>> So ? Move wayland entirely into the kernel ? Then there will be no delay.
>>> And that's probably what MacOSX and Windows NT does. As far as I know,
>>> Darwin uses quantz (AGL?)  as basis of their GUI system , but WIndows NT
>>> uses bullshit GDI .....
>>
>>
>> I thought about this but many people would disagree with us,
>> especially the entire kernel development community.
>> The kernel is designed to enforce policy not mechanism.  However,
>> Direct Rendering, particularly if we use the client/server model in
>> userspace, would suffer from unavoidable latency.  To make linux a
>> better operation system, specially for hardcore gamers, we have to put
>> it in the kernel.  Also, kernel implementation of the
>> compositor/driver and GPU syscalls shouldn't over complicate the
>> existing kernel core API.  I think this is the best solution!
>
> s/wayland/compiz/gi in this conversation, and then read it all again
> and see if you still agree with what you're saying.
>

Corbin is right here.

There is no point fretting over the *slight* performance increase that
you're going to get if you move something in-kernel. If we were to
adopt that ideology then there would be no userspace at all. The thing
to remember here is that wayland is an interface for creating
compositors for memory buffers on the hardware, and each wayland
compositor exposes a memory buffer as a result.

If we are to have things like nested servers, it makes no sense to put
these things into the kernel at all. Especially since this imports
*severe* security issues and stability problems when you are looking
at compositors like compiz which load plugins at run time to do its
work. The kind of performance penalty that you get from a context
switch anyways is largely negligible and *really* the only performance
bottlenecks we need to worry about is how fast we can make EGL go and
how fast the clients are. Also, the number of roundtrips that you are
going to have with wayland is quite a lot lower considering that,
again, all rendering happens from the client straight to a memory
buffer which the wayland compositor then displays on-screen. In
between this process there is hardly any communication with the server
at all because it was designed exactly to minimize this.

Kind Regards,

Sam

> --
> When the facts change, I change my mind. What do you do, sir? ~ Keynes
>
> Corbin Simpson
> <MostAwesomeDude at gmail.com>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



-- 
Sam Spilsbury


More information about the wayland-devel mailing list