Software rendering docs

[Adam Jackson]

On Tuesday 28 February 2006 21:07, Peter Hutterer wrote:
> Hi,
>
> Are there any good docs out there on how software rendering is done
> in X or do I need to get it from the sources?

Mostly from the source, sadly, although you can get some clues from the DDX 
porting doc (ddx.PS.gz).  The DDX doc describes the "GC" concept in enough 
detail that the fb code will make slightly more sense.

>  From debugging so far I noticed mipointer.c, misprite.c, midispcur.c
> are involved, then it dives off into the XAA sources. Is there
> anything important I've missed (except the damage stuff)?

You should also be looking in fb/.

mi contains an extremely generic implementation of the core X rendering 
operations, which relies on decomposing each operation into a set of span 
operations that must then be provided by a framebuffer core.  fb provides 
these for the slow and uninteresting operations (wide arcs, etc).  fb also 
provides optimized versions of the interesting operations like blits and 
solid fills.  Finally fb is where software rasterisation of the Render 
extension happens (see fbpict.c and fbcompose.c), which obeys somewhat 
different rules than the core GC ops.

(There are other framebuffer cores in X, including cfb and afb in the 
currently release; don't look at them, they suck, and cfb in particular is 
slated for deletion as soon as possible.)

The core concept of hardware acceleration in X is the notion of "wrapping".  
Conceptually mi+fb is the bottom layer that absolutely has to implement 
everything no matter how slow it goes.  Above that you can wrap each dispatch 
path with specialised code that can be implemented in hardware.  So for 
example, when EXA sees that it's being asked to do a ->CopyArea GC request, 
and it sees that the source and destination of the request are both already 
in card memory, it translates the request into a call to a hardware blit 
routine provided by the 2D driver; if the blit succeeds, then EXA's 
implementation of ->CopyArea will return without ever calling down into fb, 
hence skipping the software path.

As a practical matter most of the core protocol doesn't really get used for 
rendering these days though, and that which does get used is largely 
accelerated in hardware.  Is this more of a recreational investigation, or do 
you have a particular project in mind?

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20060228/d829e893/attachment.pgp>