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. <div>On 5/3/07, Dave Airlie <<a href="mailto:airlied@gmail.com">airlied@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On 5/3/07, Abhinav Duggal <<a href="mailto:abhinavduggal@gmail.com">abhinavduggal@gmail.com </a>> 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. </blockquote></div>