What to do now after Xgl and Xegl are gone....

[David Jander]

On Tuesday 16 June 2009 21:32:49 Corbin Simpson wrote:
> On 06/16/2009 11:26 AM, Soeren Sandmann wrote:
> > Adam Jackson<ajax at nwnk.net>  writes:
> >> On Tue, 2009-06-16 at 11:32 +0200, david at protonic.nl wrote:
> >>>> You probably want to start with something like the Xorg fbdev driver
> >>>> and then start bolting on acceleration paths that call down into the
> >>>> EGL driver.  Getting that to interact well with GLX clients should be
> >>>> entertaining.
> >>>
> >>> I was suspecting something like that.... Isn't there anybody else who
> >>> has done this before? How do the folks from Maemo do this?
> >>
> >> Xomap is findable in the maemo sources somewhere, I believe.  I used to
> >> have a URL for it but it seems to no longer work.  It's a kdrive server.
> >> I don't think it uses the hardware GL support at all though.
> >
> > There is also this an xf86-video-omapfb driver:
> >
> >          http://cgit.pingu.fi/xf86-video-omapfb/
> >
> > I don't know anything about it, though.
>
> But I do. :3
>
> xf86-video-omapfb is just fbdev with a bit of hax to make Xv be
> semi-accelerated through the DSP. It's still massive amounts of fail.
>
> IMO the correct answer is to port OMAP DSS2 to true KMS, and then add an
> SGX Gallium driver to make the SGX 3D core do acceleration, but that's a
> long ways off. (Unless anybody's working on SGX reverse-engineering, but
> my search so far has not indicated any progress on that front.)

That sounds like the way to go... although I am not using omap, but a MPC5121e 
from Freescale, which is a PowerPC e300 plus a PowerVR MBX attached to it. 
The MBX is OpenGL-ES 1.1 only, while the SGX supports 2.0.

> As far as using the SGX/TI blob for acceleration, we only say, "Good
> luck." :3

In this case its the "MBX/Freescale" blob ;-)
I have been able to run Clutter on it, and also managed to compile some old 
and abandoned MesaGL version (based on 7.0.1-rc2) that has a "hacked-on" 
OpenGL-ES driver, which I found somewhere, just to find out that I need at 
least Mesa 7.1.0 to be able to compile kDrive with GLX :-(
Anyway, I doubt it would have worked...

Right now I am trying to fix a more concrete performance issue we are having 
with kDrive when the screen is rotated 90 degrees, bit-blitting is quite 
slow. A simple test showed it can be up to 4 times faster when rotating 
blocks of 16x16 pixels, because of the CPU cache, so I want to try and hack 
this into the fbdev fbBlt*() functions.

For GLX, I think I will wait to see if someone manages to come up with 
the "right" solution (i.e. Open-Source implementation of a Gallium-3D driver 
for the MBX).... and use OpenGL-ES with Clutter in the meantime.

Thanks to all for the valuable insight and tips.

Best regards,

-- 
David Jander
Protonic Holland.