[patch] drawing window borders always falls back to software

[Michael]

Hello,

On Fri, Sep 25, 2009 at 6:07 AM, Jonathan Morton <jonathan.morton at movial.com
> wrote:

> On Thu, 2009-09-24 at 21:21 -0400, Michael wrote:
> > So, yeah, EXA is unaffected. Unfortunately I can't do that on some of
> > my hardware since there's no mappable (useful) framebuffer. Which is
> > also one reason why I can't switch to EXA - not all hardware made for
> > X11 can work like EXA wants it to.
>
> 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.

Don't get me wrong, I'm not saying EXA is bad or XAA is better whatever - I
even wrote EXA acceleration for the Sun S24 ( the 'blitter' has no concept
of coordinates so EXA's way to access pixmaps in video RAM works just fine )
- I just happen to have a lot of hardware that can't work the EXA way
without major headaches while XAA fits 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.

Also, with CRIME I can map the framebuffer, but it's not linear. It's tiled
in 64kB blocks of 128 lines and depending on the colour depth, 512, 256 or
128 columns, the drawing engine sees it as three coordinate spaces of 16x16
tiles where not all tiles have to be filled in with actual memory. The pixel
format is also weird - it's RGBA with alpha in the lowest byte which freaks
out many X11 apps so my driver pretends it's ARGB and lets CRIME's DMA
engine do the conversion. With this hardware I'd actually prefer EXA if it
could be taught to deal with fixed pitch off-screen memory the XAA way, the
hardware can accelerate xrender ops from VRAM to VRAM just fine, having to
copy alpha maps and such in every time is a waste and probably quite a
performance killer since the CPU is not exactly fast by today's standards.
The only thing it can't read from VRAM are monochrome masks.

have fun
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.x.org/archives/xorg-devel/attachments/20090925/f0ad8729/attachment.htm