On 1106427895 seconds since the Beginning of the UNIX epoch
Allen Briggs wrote:
>

>> I was thinking about this a while ago, and determined that you'd
>> probably need to be able to batch requests into groups for the
>> performance improvement to exceed the system call overhead.
>> Something like a writev(2) interface that defines command packets
>> would be interesting, I think.
>
>I like this idea a lot.  If I recall correctly, X already builds
>lists of rectangles to fill/copy, so I think this should map to
>the X side of things fairly well.
>
>As I said, though, I think it would be best to get things running
>with a bare/raw framebuffer before adding acceleration.  It should
>be pretty straight forward to do at least this, and it would provide
>the basis for future acceleration.

The other idea that I had on the topic was that it could generalise
to a full kernel acceleration framework pretty easily---getting us
out of the `options INSECURE' X problem.  But of course, different
graphics cards have different capabilities---and even when they
have the same capabilities, there are often subtly different in
ways that matter to the Xserver---which leads to problems.  But,
then the kernel does not need to actually know what the card is
doing (beyond the functions that it uses to manipulate the console).
All the kernel needs to do is sanity check the arguments and twiddle
the card.  So, the different graphics card drivers can simply return
a set of capabilities which are understood by a .so in userland
where all the complexity reside and against which the Xserver links.

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/