Getting to a GL based X server

[Ian Romanick]

Adam Jackson wrote:
> On Thursday 26 May 2005 19:00, Ian Romanick wrote:
> 
>>So, here's my question:  what are the common, 2D operations that aren't
>>easilly accelerated by GL on 2D cards but are accelerated by the
>>hardware?  It should be easy enough to craft fast paths for the common
>>clear, fill, and line-draw operations.   Screen-to-screen and
>>off-screen-to-screen blits will be simple enough with the aforementioned
>>extension.  Is there anything else "big" that I'm missing?
> 
> KAA basically just accelerates blits and solid fills (and Render blends, but 
> we're assuming no hardware alpha).  I really wouldn't worry about line 
> drawing at all; it never gets used by real apps and it almost assuredly won't 
> conform to the X spec.

That's *it*?  To do this, how many functions does the driver expose? 
The idea of adding one or two trivial GL extensions that expose fast 
paths for all the KAA functionality is sounding better and better to me.

> If I'm reading this right, you do still need a degenerate DRI driver.  It 
> won't do much more than swrast and accelerated buffer swaps, but it still 
> needs to know which registers to poke, when the engine goes idle, etc.

Basically, yeah.  There are basically 4 classes of cards in the wild, 
and we currently only support one of them.  We may want to slightly 
modify the client-side driver architecture to better support the other two.

1. Full 3D cards.  This covers all the cards that we currently support. 
  These are the cards where you send triangles to the hardware, and the 
hardware takes care of everything.

2. Scanline cards.  Cards like the Virge and G100 fall into this 
category.  These are cards where the driver has to rasterize triangles 
and send information about each scanline to the card.  Not all cards in 
this category support texturing (e.g., pre-G100 Matrox cards and 3dlabs 
300SX), so this /may/ need to be divided into two categories.  Either 
way, there is no easy way to make Mesa accelerate anything on cards like 
this.

3. 2D-only cards.  These cards will be software Mesa for everything 
except a tiny handful of functions, including the fast path extensions 
that we add.  With the exception of a (very) few low-level functions, 
each of these drivers will be nearly identical.  We should be able to 
come up with some common infrastructure code that can be shared across 
most or all of these drivers.

4. Dumb framebuffers.  Not as common as they used to be (heh...), but 
cards for which there is no documentation also end up here.

There are three bits of information that would be interesting to gather. 
  I think this will help guide where effort should be applied first.

1. Which cards are in which categories based on available drivers & 
documentation *today*?  The Permedia2 is technically a category 1 card, 
but is in category 3 today.

2. Which cards would be in different categories with additional 
documentation?  The FireGL2 is in category 4, but could be in category 1.

3. How much do we "care" about each card?