Getting to a GL based X server
Ian Romanick
idr at us.ibm.com
Fri May 27 12:04:50 PDT 2005
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?
More information about the xorg
mailing list