Re: DRI integration

[ Also a resend ]

On Wed, 2003-11-12 at 16:08, Jon Smirl wrote:

> What do you think about modifying xserver to use Mesa/OpenGL for it's drawing
> API? 
> I've been looking at this model:
> 1) Base layer a DRI kernel driver (tiny driver for non-3D cards)
> 2) next Mesa/OpenGl support (either hardware or software)
> 3) third a window manager based on OpenGL/Mesa (includes font support)
> 4) X compatibility layer written to the OpenGL API 

Not sure what you mean by "includes font support" here ... having the
window manager / compositing manager composite stuff to the screen
using OpenGL is very reasonable, but that's basically an independent
question from how it draws the window manager decorations. 

For fonts, the right drawing API is almost certainly Cairo. If we
can't implement font drawing efficiently in Cairo with whatever
server architecture we come up with, then we need to either fix
Cairo or fix the server architecture :-)

Writing classic X primitives on top of the GL 2D API is virtually
impossible, but luckily, it is also uninteresting. Software is
far more than fast enough to do 2D X these days.

I think it's generally more useful to think of the X server offering
multiple rendering APIs rather than in terms of compatibility layers:

 OpenGL  ==>
 RENDER  ==>  Toplevel ==(CM)==> Screen
 Core X  ==>  Windows 
 Xv      ==> 
 
> The X compatibility layer doesn't have to stick to the exact OpenGL API. Since
> we are also implementing Mesa there can be special entry points.
> 
> Advantages to this scheme are:
> 1) Strong separation of components. Right now XFree86 is a bowl of spaghetti.
> Everything is strongly connected to everything else. These layers can function
> independently.
> 2) Life is easy for Nvidia/ATI with binary drivers.

Note that for this to be useful, we have to get the people
writing binary-only drivers "on board" with the new X server
architecture. The existing drivers attached to the existing 
XFree86 server architecture don't do us any good.

Even if you go fairly radical and say that the only thing that ever
touches the hardware is OpenGL/Mesa, there is a pretty long list of 
server architectural issues that need to be addressed:

 - Video card initialization, mode switching, etc.

 - You need to be able to use GL from the X server, something not
   yet implemented from DRI.

 - Direct rendering GL clients need to render to an offscreen buffer
   that is then fed to the compositing manager as an input.

 - Xv streams need to go to offscreen buffers and get fed to the
   compositing manager as input. (This rules out using video features
   on a good chunk of older hardware.)

> 3) Every window will support OpenGL API with it's corresponding vector API. --
> scalable drawing

OpenGL is a poor excuse for a 2D vector API for applications. Luckily,
we're working toward a better one with Cairo.

I think a GL backend for Cairo would be a really interesting project
for someone to tackle ... interesting in its own right, and also should
give a lot of insight into how we could accelerate RENDER in the
server with OpenGL.

Regards,
						Owen