Sharing surfaces and multiple drivers

[Jon Smirl]

On 4/30/05, Brian Paul <brian.paul at tungstengraphics.com> wrote:
> I think it would be the OpenGL hardware driver that would fall back to
> software rendering in situations like that.  XGL wouldn't control it
> or even know when the driver did it.  I'm not saying that's good or
> bad; it's just the way things would pan out initially.

This works too. I didn't think the hardware stacks supported it.

> A similar thing happens today when an OpenGL feature can't be
> implemented by the hardware driver (such as
> glDrawBuffer(GL_FRONT_AND_BACK)).  The driver falls back to s/w
> rendering without the app knowing.
> 
> Incidentally, the initial implementation of GL_EXT_framebuffer_object
> in the DRI drivers could be done quickly and easily with software
> rendering.  So when a user-created framebuffer is bound, the driver
> would automatically and transparently fall-back to software rendering.

That would be a good plan. We need to get something up so that we can
get XGL running.  We aren't attracting many developers to XGL since it
is difficult to get it running. Running it standalone is almost
impossible, only Dave Airlie has managed to do it.

My goal is to get an easy version of it running by DesktopCon/OLS.
Then demo it there and hopefully attract more development support.
First priority is to get it running, next we can make it more
efficient.

I almost have the fbdev DRI driver running again. It is extremely
simple and would make a good place to start adding egl support to a
DRI driver.

I'll check in what I have right now in case anyone wants to play with
it. It's better than what's in the tree, the code in the tree doesn't
even compile. My code compiles and then breaks when you run it.

-- 
Jon Smirl
jonsmirl at gmail.com