Re: DRI integration

Around 21 o'clock on Nov 12, Keith Whitwell wrote:

> In general this isn't a problem.  Exporting bits of hardware functionality not 
> covered by GL is typically a doddle.  It'd be interesting to know what you're 
> referring to.  It may even just be a case of digging out some little used 
> aspect of GL & properly optimizing the implementation.

Hmm.  I guess I was originally thinking of using the bits underneath Mesa 
that talk directly to the hardware (after all, it would be *faster*, but 
then 2D performance is not critical, so this hardly matters).

If extending GL to support the 2D operations used by the server is 
practical, it sure would eliminate a whole lot of time and energy currently 
directed at writing essentially duplicate rendering code.  And, we'd 
really be able to take advantage of GL with the Composite extension to 
produce some interesting effects.

The rendering operations I need are:

 1)	Stencil with rasterop and planemask (for core X geometric primitives)
 2)	Off-screen drawing (pbuffers or equivalent, I think)
 3)	Per-component alpha compositing (for LCD text)
 4)	Sub-pixel geometry aware compositing (Conjoint/Disjoint)
 5)	Region-based clipping (clip to pixel boundaries)

Of these, 3) and 4) will likely end up in software most of the time, which 
is fine with me.

> I'm not sure about all of this.  It's probably best to view GL as it was 
> intended - as a hardware abstraction.  If you want a hardware abstraction, 
> that's what GL is for.  If there are bits of hardware functionality missing, 
> it's easy to add them.

GL as hardware rendering abstraction is fine, but we still need some way to
configure the hardware underneath GL, selecting video modes, handling power
management, etc.  I think that belongs in a kernel driver that integrates
the functionality of fbdev and DRI, but doesn't force the user to adopt a
frame buffer based console driver as well.

With that, the X server simply opens GL; GL opens the video device and 
somehow configures the hardware appropriately.

I guess I'm a bit concerned about devices without good GL support today, 
but which offer useful 2D acceleration; if you look at my mach64 server, 
you'll find about 500 lines of code that accelerates the two fundmental 
operations necessary for reasonable 2D performance (solid fill *and* 
video->video copy).  If I add simple image compositing, I'll fix the 
remaining performance bottleneck for the Composite extension and still 
have well under 1000 lines of code per chipset, none of which use floating 
point values.

So, I guess I'd like to see a kernel API for this level of functionality 
so that I can get any available DMA and interrupts for cards that don't 
support GL.

> > If fbdev and DRI could get along nicely, this might be a better solution 
> > in the long run.  There are things about ACPI which make kernel support 
> > for device configuration more than just a good idea.
>
> I wouldn't be suprised to see this happening - there's been a little 
> discussion about it already.

Yes, I've been watching that thread on dri-devel quite closely, and have 
chatted with several people off-line about how that might work.  I'm glad 
to see people with a good understanding of the issues working on it.  I 
eagerly await the day when the X server has no video mode selection logic 
at all.

-keith