New acceleration architecture

[Eric Anholt]

On Wed, 2005-06-29 at 11:29 +0200, Thomas Winischhofer wrote:
> - - memorySize/memoryBase: Does this refer to the card's entire video
> memory, or only the *off*screen memory? While the comments in exa.h
> suggest the former, usage of these values in exaPixmapIsOffscreen() and
> this very routine's name suggest the latter. The latter doesn't really
> make sense since you use exaPixmapIsOffscreen also for checking if the
> *destination* is "offscreen" in order to eventually sync the accelerator
> (which looks somewhat odd for fills - or do these always go into
> *off*screen?). If the former, the name is at least misleading.

The offscreen allocator will allocate linear areas between
(card->memorybase + card->offscreenbase) to (card->memorybase +
card->size).  Your visiable screen (and 3d back buffer) are expected to
be somewhere between (card->memorybase) and (card->memorybase +
card->memorysize).

Imagine renaming exaPixmapIsOffscreen to exaPixmapIsInFramebuffer.
It'll return true for the visible screen's pixmap as well.  It's just
for asking "is everything on the card so I can accelerate?"

> - - offscreenByteAlign: Boundary for pixmap data, ie to what boundaries
> data to be blitted is to be aligned to (in bytes)
> 
> - - offscreenPitch: Alignment of pitch of pixmaps to be blitted/filled (in
> bytes)

Yep, got those right.

> - - maxX, maxY = maximum width/height (and not strictly "coordinate
> limitations", since in exaTryDriverComposite() you compare the
> width/height to these values)? Haven't check all occurances of maxX/maxY
> usage, but I would assume these values really mean
> 
>   maxX = min(card's maximum X coordinate, card's maximum width)
> 
> and likewise for Y.

I'm concerned about how maxX/maxY are handled.  I definitely thought
they should be the coordinate limitations: the maximum offset in X and Y
from the beginning of a pixmap (the offset, aligned to
offScreenByteAlign) for anything touched by an operation.  Instead, they
seem to be the maximum width/height requested for an operation, which
isn't quite what we need.

I imagined the maxX/maxY as slicing all pixmaps at those intervals
(which should make POT alignment happy, assuming the limit is a power of
2 itself), and then doing composites with rectangles of those slices
according to how the src/mask/dst x/y offsets fell.  The driver would
adjust its offset for rendering by intervals of maxX/maxY on these
operations, not having to worry then about whether it would hit the
coordinate restrictions.  It didn't sound like fun to write, but at
least a pretty sane way of going about it while respecting the various
alignment restricitons on cards and without having your Render
acceleration just stop accelerating on large screens (say, a MergedFB
desktop).

I'm ignoring here the issue of ordering of copies if we were to scroll
to the right, which is broken in software render (at least, last I
heard/saw) anyway.  And that CopyArea and SolidFill don't respect it,
which will be an issue on older cards more than it is on Radeons.

> - - flags: So far only EXA_OFFSCREEN_PIXMAPS and EXA_OFFSCREEN_ALIGN_POT?

Yeah, looks like (and that matches KAA).  You want
EXA_OFFSCREEN_PIXMAPS.  EXA_OFFSCREEN_ALIGN_POT will make your pixmap
pitch POT-aligned, for the purposes of using your 3d hardware (which in
nearly all cases requires a POT pitch) for Composite calls.

Note that pitch alignment does not get applied to your visible screen,
if that's important for you.  It's your driver's responsibility to fix
up the screen's pitch for acceleration.  Luckily, drivers that have been
doing XAA know how to do that already.

> >>>>>5) exaDriverInit(pScreen, exaDriver); once you connected yours hooks and 
> >>>>>setup your card.
> >>>>>6) replace xf86AllocateOffscreenArea with calls to ExaOffscreenAlloc
> >>>
> >>>
> >>>What about a wrapper for AllocLinear, since this is what's mostly used?
> 
> Please disregard this statement. By "area" you obviously already mean
> "linear" area, not "area" in the sense of the old fbmanager's FBArea.

Yep, everything's linear these days.

-- 
Eric Anholt                                     eta at lclark.edu
http://people.freebsd.org/~anholt/              anholt at FreeBSD.org