xf86-video-savage: fix EXA UploadToScreen()

[Alex Deucher]

On Sun, Apr 6, 2008 at 8:26 PM, Alex Villacís Lasso
<a_villacis at palosanto.com> wrote:
> i r stupid
>
>  The sample replacement loop I sent before was incorrect after all. I was
> incrementing
>  the pointer srcp (which is of type CARD32*) by an amount of src_pitch
> (which is
>  in bytes). Duh. No wonder pixmaps appeared squished.
>
>  Attached is a fixed patch which properly removes the EXA breakage. However,
> I am
>  still looking for a reference of commands available through BCI. Window

Unfortunately, I never got a list from S3.  Your best bet is to look
at the savage_bci.h and the 3D driver.  The BCI is basically just a
packet parser.  It allows you to program the chip in a more efficient
manner than via direct register programming, but you can also do it
via direct programming.  That's what the BCI does on the backend; it
parses the incoming packets and programs the registers appropriately.

> dragging
>  is awfully slow, even with EXA fixed, and I wonder what EXA operations
> should be
>  accelerated in order to fix this. An interesting observation: under EXA,
> using xcompmgr
>  for simple composition actually makes window dragging *faster* than without
> it.

yeah, when you are running a compmgr, damage is tracked and updates
are composited from offscreen pixmaps to the screen.  To really speed
things up, you want to either do everything in SW or HW.  Any
fallbacks and you lose.  Ideally you'd want to do it all in HW :)  To
do that you'd need to implement support for the exa composite hooks
with as few fallbacks as possible.  Take a look at the radeon or intel
drivers for reference.  The composite hooks add support for
src/dst/mask blends and coordinate transform.  You'd need to use the
3D engine to implement this.

Alex

>
>  Changelog:
>  * EXA upload to screen must honor pitch of the source data
>
>