[patch] drawing window borders always falls back to software

Michael macallan at netbsd.org
Fri Sep 25 15:13:58 PDT 2009

Hash: SHA1


On Sep 25, 2009, at 4:44 PM, Daniel Stone wrote:

> Hi,
> On Fri, Sep 25, 2009 at 03:28:48PM -0400, Michael wrote:
>> On Fri, Sep 25, 2009 at 6:07 AM, Jonathan Morton <jonathan.morton at movial.com
>>> wrote:
>>> EXA *can* cope with non-mappable framebuffers, provided you either
>>> accelerate every possible operation involving it, or (preferably)  
>>> you
>>> provide a way to retrieve a copy of it to system or mappable memory.
>> Even then I still have the problem that EXA wants to access off- 
>> screen
>> memory in a linear way while many older once fairly high end  
>> graphics chips
>> work with a fixed, hardcoded pitch, usually something like 2048  
>> pixels or
>> 8192 bytes, and no such thing as offsets in bytes - everthing is one,
>> usually fairly large coordinate space.
> Errr ... you know that EXA can handle pitch != (width * bpp), right?

I tried that. If I give EXA the hardware's pitch it will waste most  
off-screen memory by putting all pixmaps at x=0 and do nothing with  
the space to the right of them.

> Most GPUs with EXA drivers that people actually use tend to have pitch
> alignment requirements, and the one for omapfb deals with the case  
> where
> there's a fixed 2048px pitch (when using the hardware rotation  
> engine),
> which works just fine.

See above - is there a way to avoid that which I'm just not aware of?

>> Is there an easy way to replace EXA's off-screen memory manager with
>> something that works like XAA's? If that was the case I'd switch  
>> over to EXA
>> in a heartbeat.
> Well, given that you have complete control of pixmap allocation with
> EXA_HANDLES_PIXMAPS and CreatePixmap2(), you can have one large
> offscreen window which you suballocate if you feel like, and then do  
> the
> requisite co-ordinate transforms in your drawing routines.

So, basically, replace the off-screen memory allocator. I can probably  
recycle XAA's code here or look for prior art in other drivers. Is the  
omapfb driver you mentioned above available on freedesktop.org or do I  
have to look elsewhere? I've never seen it before.

have fun

Version: GnuPG v1.4.7 (Darwin)


More information about the xorg-devel mailing list