Software rendering docs

[Peter Hutterer]

Hey Adam,

recreational investigation? in the X source code? are you joking? :)

The actual goal I have is render multiple cursors at once. I did some  
modifications to X so that the events being sent from the server look  
like we have independent mice. Works reasonably well so far, with  
apps like GIMP, firefox and abiword responding well to the changes  
(two-handed input in GIMP is quite interesting to work with).

The problem is that at the moment my window manager has to render the  
mice to display multiple cursors. Which of course doesn't work  
properly when a pointer grab is on (and in some other cases).  
According to Aaron Plattner my graphics card (nvidia) doesn't support  
more than one cursor in hardware. So the whole thing has to be in  
software.

I haven't figured out though how to render more than one cursor  
simultaneously to the screen.

The wrapping concept you mentioned is actually what is killing me so  
far. With all the function pointers it's hard to add information  
without breaking the API and rewriting lots of code.

Thanks for your answer though, I'll dig into it.

Cheers,
   Peter


On 01/03/2006, at 1:22 PM, Adam Jackson wrote:

> 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