[patch] drawing window borders always falls back to software

[Daniel Stone]

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?
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.

> 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.

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-devel/attachments/20090925/22f8f8a3/attachment.pgp