[Xorg] X on OpenGL

Soeren Sandmann sandmann at daimi.au.dk
Sun Jul 11 04:29:10 PDT 2004


Keith Packard <keithp at keithp.com> writes:

> Around 23 o'clock on Jul 9, Adam Jackson wrote:
> 
> > It might be more accurate to say that the goal is to make the X
> > server a DRI client rather than an OpenGL app.
> 
> While that would be possible, that's not my goal -- if GL is available, I'd
> rather just use that for the driver API.  We may want a few extensions, but
> the X server should be able to run on plain unextended GL. David Reveman
> and Peter Nilsson show us with Glitz just how feasible this is; glitz
> provides essentially all of the Render semantics on GLX and AGL (with WGL
> support coming soon).

I am not convinced that OpenGL has everything that applications will
need. Some things I don't see how to support:

- vblank notification

OpenGL doesn't deal with this at all. Applications will want a Sync
counter to block on. To do that the server needs to be notified when
vblank starts. Ideally it would be possible to get notifications when
the beam reaches a given scanline.

- mode setting

Changing the mode of hardware Ideally the graphics backend could
change the mode by itself. Seen from inside the X server the API could
look like

        ListOfModes ListModes ();

        SetMode ();

        SetModeChangedNotification (callback)

The idea is that the X server would register a callback that gets
called when the mode changes. It does everything it has to do in
response to that callback. If the server itself wants a different
mode, it calls SetMode() and if the mode setting succeeds, the
callback gets called.

This should be enough that things like XNest can just be another piece
of 'hardware'.

- reading pixels out of the framebuffer

GetImage needs to be supported, and I'd hope that we could do better
than just synchronize with the hardware, then read the pixels. Some
cards can DMA pixels to main memory. The ideal API would be

        GetPixels (callback)

so that the X server could go on doing other stuff until the pixels
arrived from the card.

- breadcrumb

To do good-looking animations, applications will want to know when a
given request is actually completed by the graphics hardware. So the
API should support that.

- gamma correct compositing

Really good-looking antialiasing will require gamma correct
compositing. Can OpenGL do this?


A common theme for these things is that it has to be integrated with
the X server's select() loop. Basically the driver API needs to be
able to generate events, and OpenGL doesn't really support that.

So I would like to propose that there is an abstraction layer on top
of OpenGL that has support for these things and also knows about the X
server select() loop.



Søren




More information about the xorg mailing list