Re: Looks tempting
@Bombastic Bob,
I too have never found X to be a problem. GTK is a miserable pile of ordur.
I think if one is doing a lot of work that involves a load of texture maps in 3D, the pipe does become a problem. Hence moving away from that architecture. However...
Internal DMA
Of course the only reason why a pipe is problem in that circumstance is that it inherently involves memory copying, a lot of context switches back and forth (especially for large amounts of data flowing), a so forth. However modern Intel CPUs have features that would completely eliminate that problem; internal DMAs. A pipe-like facility could be implemented around internal DMAs, which would be lightning fast (indeed, very fast), and would take far less CPU time to shift data from a client application (e.g. texture maps) to a display server's internals. If mailbox semaphores were possible (I don't know if they are on an Intel platform) the DMA could even ping off a semaphore post to wake up a display server once new data had been provided by the client. Et voila, a client server architecture with far more bandwidth (by definition, the best possible bandwidth) and zero context switches in/out of the kernel.
A thin layer on top would all this to optionally pump client data down a real pipe or socket (for remote servers).
What do you think? A good idea?
It seems that no one involved in replacing X is stopping to think whether or not the client-server model could be retained. I think they've blundered straight on into replacing it with a fairly crude driver architecture without casting an eye around to see what hardware facilities now exist to improve the existing client / server architecture. It'd be a great pity if all that nice DMA silicon that Intel now put in their CPUs ended up not being used by an updated X server for *nix.
Biting the hand that feeds IT
