Xgl server

[Jon Smirl]

On Mon, 08 Nov 2004 10:59:50 -0800, Shrijeet Mukherjee <shm at sgi.com> wrote:
> So .. I am interested in helping and also understanding the design goals
> in the short and long term for multi-pipe support that X.org has
> targetted and also which areas can we contribute the most if we have a
> solution or experience to offer.

If you look at the problem from a high level we have three sets of
drivers for each card: fbdev, xaa and DRM. Big parts of XAA and fbdev
are almost exactly duplicated.

XAA was created in the early days of X when the OS did not have much
in the way of support libraries. So XAA basically ignores the OS and
does everything from PCI probing to munging with device registers from
user space. Now OS's are much more mature and they support all of
these things that XAA does. It's worse in that if XAA messes with PCI
space from X it will actually mess up the OS's management of PCI
space.

Now throw in another trend, the rapid improvement of performance from
graphics cards. These cards have made alpha blended, composited UIs
possible.

One approach would be to continue expanding XAA to include support for
alpha blending and compositing. This has two drawbacks, XAA is already
known to cause conflicts with the underlying OS. Plus extending XAA
requires the GPU vendors to either developer new proprietary XAA
drivers or release the specs for their chips. Extending XAA may go
even further to cover things like shader programs.

An alternative strategy is to change the basic driver model. Both
Microsoft and Apple have chosen this route. The OpenSource version of
this change is to use OpenGL as a base driver and implement X on top
which yields XGL. OpenGL has a well defined, standardized API for
things like alpha blending, compositing and shaders. XGL is
implemented using these APIs. Another advantage is that ATI/NVidia/SGI
already have high performance OpenGL implementations.

In this new model we have three layers:
XGL
OpenGL (mesa, ATI, NVidia, SGI, etc)
Device drivers

I'm working on building a reference implementation for this model
using mesa-solo. mesa-solo is a standalone version of mesa that can
run outside of X. The purpose of the reference model is to figure out
what sort of API we need to implement. It will also serve as a guide
for the GPU vendors to implement their proprietary versions. For
example we obviously need mode setting and cursor APIs which are
missing from OpenGL. This is where the comments about using OpenGL-ES
are comming from. OpenGL-ES has APIs for things like this.

Another large area is making sure other users of the video card (like
Linux console) still work in this new model. In the old system we had:

Xserver + XAA
DRI (mesa)
DRM + fbdev

Xserver mode setting and cursor support came from XAA. This duplicated
the code in fbdev and also causes OS level conflicts over PCI bus
control. The new model looks like this:

XGL
mesa-solo
DRM/fbdev

DRM and fbdev have been integrated together so that they control the
graphics hardware as a single driver. This driver exports mode setting
and cursor control up to the mesa-solo layer. It also provides console
support for things like printk's.

This is where I'm at right now. In the old model XAA supports
multi-head, neither DRM nor fbdev understand multi-head devices. The
plan is to alter these drivers to support each head as an independent
device. The code at  bk://mesa3d@bkbits.net/drm-fb is a work in
progress towards this goal. Right now I'm trying to work out the
multi-head device driver interface.

I'm using the ATI R200 to implement the reference model code since it
is the most advanced card we can get specs for. I'd like to encourage
all developers to help work on this shared code and apply the lessons
learned to their proprietary systems.

-- 
Jon Smirl
jonsmirl at gmail.com