Benchmark of Wayland

[Russell Shaw]

On 18/11/10 13:28, Toan Pham 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!

Creating drivers for large monolithic kernels is a real bitch.

The kernel should have minimal code such as just for enforcing
security and memory management.

95% of the graphics card driver could be just called as a library
function from the application.

The benefits of having code that is in a normal process that you
can use a debugger like gdb on is very high.

I don't see how putting it all in the kernel will reduce the
latency any more.

X is a daemon just to get network graphics.

The X server could be modified to be linked with Xlib,
and with client-side apps, so the whole X lib infrastructure
exists as a userspace library and could have an api similar
to the way it is now and everything still works. Later additions
can add new APIs that are more suitable than the old Xlib APIs.

To have old X network graphics, a new X2 daemon is created
that accepts network connections, and drives the old X that
is now a userspace library.