Benchmark of Wayland

Justin Lee justinlee5455 at gmail.com
Thu Nov 18 01:26:20 PST 2010


2010/11/18 Toan Pham <tpham3783 at gmail.com>:
>>>
>>> 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,

Is that typo? I think it should be "The kernel is designed to provide
mechanism not to enforce policy .".

> 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!

The only latency I can tell is that the system call overhead is larger
than ordinary function call. Don't know what's the reasons to cause
Mac/WinNT putting things into kernel, though.


More information about the wayland-devel mailing list