Splitting protocol screens from the driver interface

[Aaron Plattner]

On Wed, Apr 06, 2011 at 08:51:52PM -0700, Dave Airlie wrote:
> On Thu, Apr 7, 2011 at 10:59 AM, Aaron Plattner <aplattner at nvidia.com> wrote:
> > Hi Dave,
> >
> > I like the idea of separating the driver from the protocol screens,
> > and am interested in helping out.  I think it might be easiest in the
> > short term to let the overlay functionality I talked about break and
> > then I can add it back later in whatever form makes the most sense
> > with the new architecture (which I hope will let overlays and
> > Composite work together, that would be awesome).  As James mentioned
> > on IRC, the biggest issue is probably going to be access to the window
> > clip lists, which we definitely need for GLX but can probably live
> > without for the core X driver.
> >
> > Is there a design document or something somewhere that we can take a
> > look at to get a better understanding of what your intended target
> > looks like?
> 
> I'm not sure I'd call it much of a design document, but I try to put a
> coherent stream
> of words into lyx this morning,
> 
> the result is at
> 
> http://people.freedesktop.org/~airlied/xredesign.pdf

Awesome, thanks a lot.  I skimmed it and just have a few comments /
questions.

* 3.1, Reasons for redesign, GPU hotplugging

  It's not clear to me how the server is going to choose the visuals to
  expose when the driver back-end could change due to GPU hotplugging, or
  when the GPU handling offloading has a different set of capabilities from
  the one driving the display.  I think this is going to necessarily mean
  that the list of visuals and GLX fbconfigs needs to become dynamic, but I
  fear that making applications deal with that is not going to be pretty.

* 3.2, Reasons for redesign, GPU offloading

  I think we can add this later, but it would be nice to have a
  standardized way for drivers to share buffer information so that we can
  have the NVIDIA driver interoperate with the Intel driver.  E.g., our
  driver would register that it supports GPU offloading and describe the
  layout it needs, and the Intel driver would export surfaces to us through
  this new interface.

* 4.1, Overlays

  Unlike some other window systems that I don't care to mention, X windows
  exist in only one plane at a time.  This means that, at least for
  NVIDIA's architecture, a window is either in the overlay or it's not.  We
  implement this by creating an overlay pixmap, akin to the screen pixmap,
  that represents the pixels actually visible on the screen in the overlay
  plane.  GetWindowPixmap on a window in the overlay returns this special
  pixmap.

  I'm thinking that the proper way to make this work after the rework is to
  let the driver register these pixmaps with the protocol layer.  Then,
  when the proto layer is making clipping decisions, it can assume that no
  two windows interact whenever their window pixmaps differ.  E.g., a
  redirected window would not clip a window in the overlay, which in turn
  would not clip a window in the main plane.  Working through all the
  nitty-gritty details will take some work.

* Misc

  One annoyance with Xinerama is that each back-end screen has its own copy
  of each pixmap, which means that you get N different rendering operations
  to create N identical copies of the image.   That's fine when there are N
  different GPUs doing that work, but it's bad when all of the screens do
  the same software rendering to completely redundant sysmem copies.  It
  would be nice to solve that.