GL|ES Mesa and DRI

Graeme Gregory graeme at
Fri Nov 28 10:53:27 CET 2008

On Thu, 2008-11-27 at 17:37 +0000, Thomas White wrote:
> On Thu, 27 Nov 2008 16:39:33 +0100
> "Andreas Pokorny" <andreas.pokorny at> wrote:
> > Does Mesa already provide an OpenGL|ES API? Is Mesa a good starting
> > point at all?
> Since OpenGL ES is a subset of full OpenGL, I don't think it actually
> makes that much difference.  I haven't had much luck at all looking for
> hardware accelerated implementations of "strict ES" apart from
> proprietary drivers.  Or, for that matter, in finding information about
> whether using Mesa for ES is "sensible" from its point of view.  Does
> anyone know more about this?
> I did find this, however, which is relevant:
> My opinion from the information I have at the moment is that it'd be
> best to use Mesa, even if it isn't meant to be used just for ES. The
> we could just "forget" to handle anything which Glamo won't do - either
> fall back onto software rendering or abort with an error.  The end
> result would be the same - as if we'd written our own implementation of
> the ES API from scratch - and we get the benefit of Mesa, DRI and
> several other drivers to examine for reference.

There are also other things to consider in the stack.

We need a good Xorg driver with DRI (or DRI like support) + the kernel
backend for this. I don't think anyone on arm has done this yet. We also
need to tie glamofb and the 2d EXA driver into this as well as Andy has
identified some locking problems which can only be solved by one common
point of access.

Currently the status with the Xorg driver is I have a skeleton in git
I've been trying to get my head around mode setting to RandR works and
struggling with it. I just can't work out how to tell Xorg we support 4
and exactly 4 modelines.


More information about the devel mailing list