Xorg glamo update

Thomas White taw27 at cam.ac.uk
Sun Jan 4 20:39:59 CET 2009

> > I'd like to ramp-up to speed ASAP so that I know which parts to
> > focus on.

Hi there - thanks for signing up!  We certainly need as many keen
people as possible for this project.  If I've found out only one thing
since trying to contribute here, it's that it's very difficult to get
information about the insides of X, DRI, and so on.  So I thought it
might help to give a bit of an overview of what's been going on and how
all this fits together.  This is from my perspective, so I'd like
anyone to point out places where I may have got things wrong:

1. DRM

This is the kernel part of things.  The kernel DRM module will mediate
all access to Glamo.  DRM clients send commands and buffer data via a
device node, and the module sorts out all the locking, context switches
and so on to feed multiple concurrent commands to Glamo in a sensible
order.  It will also manage Glamo's internal memory to make sure that
the right things are there for it to work with.  That means that DRM
clients just need to worry about their own business and nothing more.
2D, 3D and video acceleration all need to make use of the DRM module to
coexist happily.  There should be no "icky" locking between kernel and
userspace involved, because DRM takes care of the mediation.

For us, creating a DRM module is complicated by the fact that the DRM
code assumes that it'll only be handling PCI devices. However, this can
be worked around with a little hacking around of the code.  One of the
developers on #dri-devel (on Freenode) assured me that there are no
"nasties" waiting for us further down the line with this approach.  In
any case, the DRI in itself doesn't impose many restrictions on how
things are implemented - we can use our own ioctls and so on to
implement things if they don't fit into what's there already.

2. KMS

Kernel modeswitching (switching framebuffer modes at the kernel level,
rather than under the control of X) must cooperate with the DRM module
to work properly, but KMS is very new.  The first part of this was sent
to Linus only a few days ago:

2. Accelerated 2D

Graeme's current implementation takes control of the Glamo command
queue to do 2D acceleration.  When the DRM module is up and running,
the 2D acceleration module will become "just" a DRM client, with the
DRM module being in control of the command queue.  That means that 2D
acceleration can coexist happily with 3D, KMS and other fun things such
as MPEG decoding (the existing Glamo-accelerated mplayer driver could
use something like libVA to make use of DRI in a very nice way).

3. OpenGL/Mesa

The Mesa backend driver will also be a DRM client.  I've done some
messing about at the kernel level with Glamo's 3D engine:
Basically I've got as far as initialising the engine, getting sensible
values for its status registers, and I've been working on setting up a
surface and drawing something.  This is all done "for fun" - just
poking values into the registers from kernel code to see if I can make
it do something.  In "real life", the kernel code will make hardly any
mention of 3D and will just get on with managing buffers and commands
as mentioned above.

4. People / Where to help

Many people have (rightly) pointed out that 3D acceleration isn't
something that OM themselves should be spending time and money on, so
this part is purely a community project.  Despite the fact that Glamo
won't be being used in future devices, there are people (such as
myself) who'd like to give it a go.  Right now, I'm starting work on a
Mesa driver to get a top-down perspective and because I have a lot of
OpenGL experience to bring.

Andreas mentioned that he has a skeleton DRM module.  I've also had a
go at the beginnings of one.  I got as far as getting /dev/dri/card0 to
exist before deciding I needed a different perspective to understand it

So... there's lots of potential places to join in, starting from
getting the current Xorg driver to work and moving on to all kinds of
kernel fun to enable 3D.

I think it would help a lot to have some shared Git hosting somewhere
for the community-led parts of this, allowing us to "compare notes" on
what's been done so far.  Right now, I've got quite a lot of branches
going on with my DRM modifications to make it handle non-PCI devices,
my "messing about with the 3D engine" stuff, and so on.  Does anyone
have the resources to provide this?

Hope that helps in some way,


More information about the devel mailing list