Getting to a GL based X server

[Ian Romanick]

Dave Airlie wrote:
>>Which, last I checked, corresponded roughly to: KAA, fixed function 3D engine,
>>3D with shader hotness.
>>
>>Remind me why on earth I would want to use fb to do core X and Render to a
>>texture, then use a software GL engine to interpolate that across the screen.
> 
> You're a masochist maybe? I'll state here ane now that accelerating
> Mesa to do what we want will never get us anything close to the KAA
> stuff (even KAA with little or none hardware acceleration..), there
> are too many layers of indirection between the top of the OpenGL stack
> and the framebuffer, it works fine with hardware, software rendering
> is sucky.... XAA is better than this....

Herein lies one of the *strengths* of the GL model.  If there is some 
feature that we want to accelerate, but there is no "fast path", we can 
add an extension that will give us the fast path.  For example, the 
EXT_framebuffer_object working-group is working on an extension that 
will enable low-overhead scaled blits between framebuffer objects.  It's 
a simple extension that adds a fast path for a common operation.

Since "we" control Mesa, which will be the only sort of GL available for 
these really old cards, we can easilly add extensions like this as we 
need.  If some IHV starts shipping it too, that's great.  If not, it 
doesn't matter.

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?