Sharing surfaces and multiple drivers

[Brian Paul]

Jon Smirl wrote:
> On 4/30/05, Brian Paul <brian.paul at tungstengraphics.com> wrote:
> 
>>>I was looking at EGLDisplay as having at least two devices, the
>>>hardware one and the software renderer.
>>
>>Not sure I understand.  The Mesa software renderer is included in each
>>hardware driver.  Do you see a need to specifically create
>>software-based rendering contexts/surfaces when there's hardware
>>rendering available?
> 
> 
> When all of your windows are being drawn to surfaces and then being
> composited at a later stage it is easy to run of VRAM if you open 500
> windows.

Right.


> XGL can fallback to software rendering when it runs out of
> hardware surfaces.

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.

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.

-Brian