[Libdlo] [RFC 2.6.30 1/1] defio fbdev displaylink implementation

[Bernie Thompson]

Thanks so much Roberto, Jaya, and others for all this progress.  By the way,
all of this work was very visible at both the Linux Plumbers conference and
X Developers conference last week.  We were able do so several multiseat
demos (recreatable with the steps at
http://libdlo.freedesktop.org/wiki/MultiSeatTerminal). People were very
impressed with it working plug-and-play and with the good performance.
Several good discussions were triggered.  So all this work is being seen,
thank you!

So now the trick is answering these questions on right way(s) forward.  My
assumption has been we need to get down to a single kernel mode driver
codebase, that we'd like to get included by default in the distros -- and
right now we have three (older udlfb and newer displaylink-mod from Roberto,
displaylinkfb from Jaya). And there's the question of how much smarts should
stay above/below the kernel line. So how do we consolidate?

Jaya's list of goals from the start of this thread all look very positive.
 Because the framebuffer interface is (at the surface at least) such a good
match to the DisplayLink hardware, keeping as much capability in the
framebuffer driver as possible is good (lets us support standard fbdev
user-mode clients who aren't displaylink aware) -- while also keeping it
simple and allowing user-mode clients to take over displaylink-specific
rendering in a controlled fashion if they really want to optimize (and we
still need to settle on that mechanism).

One interesting area of performance concern for Jaya's driver (once
compression is added) is the 4KB granularity of defio - sending any
unnecessary pixels over USB will hasten our most important bottleneck.

There have been two solutions talked about:

1) (For X at least) provide an interface to supply damage information in
addition to the touched pages:
http://marc.info/?l=linux-fbdev-devel&m=123288616213965&w=2
Jaya - did your patches work out?  What is the latest news on them?
2) Enhance defio to provide "shadow page" support, such that when a PTE is
touched and backed, we also alloc a second page and take snapshot of the
soon-to-be-dirty page before the client has changed it. Then we pass both
before/after pages to the defio-supporting driver to do a more precise
detection of differences. This consumes a little more memory (but less than
the full shadow of the framebuffer we keep today), and a little more CPU.

My loose preference is for #1, as X is such an important client.  But both
possibilities are interesting. Is there one best answer?

Also, at XDC there was some discussion of benchmarks (to help compare and
guide our choices here).  It got some good laughs in the room, as good X
benchmarks are a dismal science.  Chris Wilson is helping to look into some
Cairo-based benchmarks, but until then for any comparisons I'm doing, I'll
be simply using gtkperf and glxgears at default-window and full-screen sizes
- and I'd like to add a mplayer -fb test with a standard piece of content.

Again, thanks so much to everyone contributing to this.  Any thoughts on any
of it?

Best wishes,
Bernie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/libdlo/attachments/20091007/7a8b6d8b/attachment.htm