Understanding kdrive ati driver UploadToScreen function.

[Abhinav Duggal]

ya true.I get it. But what is the purpose of this.If it is copying data one
by one.Why implement UploadToScreen then.Why not do memcpy instead to
transfer the contents to offscreen region.As  the paper  ' High Performance
X Servers in the Kdrive Architecture '  by Eric Anholt says
Finally, a new UploadToScratch hook was added that takes two pixmap pointers
and makes the second a copy of the first, but with the data located in a
scratch area in card memory. This allows temporary migration of a pixmap for
the case where a pixmap not being in offscreen memory is all that is
preventing acceleration. This occurs frequently in drawing of glyphs, which
are not stored in real pixmaps and therefore will not be migrated into
offscreen memory normally.

Thanks for the reply.



On 5/3/07, Dave Airlie <airlied at gmail.com> wrote:
>
> On 5/3/07, Abhinav Duggal <abhinavduggal at gmail.com> wrote:
> > Hi all,
> > I was going through ati kdrive driver.The UploadToScreen gets a src
> pointer
> > to the memory region to copy to the destination.But this address is a
> > virtual space address.This address is used as follows to perform the
> upload
> > operation.
> > ATIUploadToScreen(PixmapPtr pDst, char *src, int src_pitch)
> > {
> > .....
> > .....
> > //code from  hw/kdrive/ati_draw.c
> >  BEGIN_DMA(1);
> >    OUT_RING(((CARD32 *)src)[i]);
> >    END_DMA();
> >  ....
> > ....
> > }
>
> You missed the important part in your paste, the for loop...
>
> It just writes out each 32-bit word into the DMA buffer, from src, it
> doesn't actually write src anywhere..
>
> Dave.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20070503/c9e8d4d7/attachment.html>