New acceleration architecture

[Thomas Winischhofer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas Winischhofer wrote:
> Thomas Winischhofer wrote:
>>>Zack Rusin wrote:
>>>>>1) include "exa.h" in your driver and load exa,
>>>
>>>
>>>
>>>Could I please have a (global) #define whether exa is available? (So
>>>that I can #include the file only if it's really there)


Never mind, will do this with XORG_VERSION_CURRENT. This requirement is
too specific for my needs to ask for such an effort.


>>>>>2) use the code from XAA primitives for solid-fills and screentoscreen 
>>>>>copies to implement Exa's Solid and Copy hooks. So no real changes at 
>>>>>this point. 
>>>>>3) create an ExaDriverRec structure and fill in the accel hooks.
>>>>>4) call exaCardInit(exaDriver, memory_base, off_screen_base,
>>>>>	memory_size, offscreen_byte_align, offscreen_pitch,
>>>>>	flags, max_x, max_y); to let the system know what are the 
>>>>>capabilities of your card. This is really a convenience macro and you 
>>>>>may fill in all those individually if you prefer that.
>>>
>>>
>>>
>>>Would you mind commenting the structure elements a bit more please?
>>>What's offscreen_byte_align, offscreen_pitch, for example? Is
>>>"memorysize" including the screen area, or the offscreen area only? Is
>>>offscreenbase an offset, or a pointer cast into "unsigned long"? If you
>>>want to make transition/porting easy please don't make me read the
>>>entire code :)

Well, let's see if I got this right:

ExaCardInfo:

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

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

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

- - flags: So far only EXA_OFFSCREEN_PIXMAPS and EXA_OFFSCREEN_ALIGN_POT?


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

Thomas

- --
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net	       *** http://www.winischhofer.net
twini AT xfree86 DOT org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCwmoAzydIRAktyUcRAqVIAJ4ooZys6zJrRdmIE8+apMAhzvxi6gCdE0pE
B6gfKXBjO37siq/+kFKnQy4=
=QFMk
-----END PGP SIGNATURE-----