<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Ville Syrjälä wrote: <blockquote cite="mid20050927050559.GA21770@sci.fi" type="cite"> <pre wrap="">On Mon, Sep 26, 2005 at 01:04:58PM -0700, Eric Anholt wrote: </pre> <blockquote type="cite"> <pre wrap="">On Mon, 2005-09-26 at 21:48 +0200, Thomas Hellstrom wrote: </pre> <blockquote type="cite"> <pre wrap="">Eric Anholt wrote: </pre> <blockquote type="cite"> <pre wrap="">On Mon, 2005-09-26 at 09:55 +0200, Thomas Hellstrom wrote: </pre> <blockquote type="cite"> <pre wrap="">Hi! EXADriverPtr->card.pixmapOffsetAlign = ? EXADriverPtr->card.pixmapPitchAlign = ? Is there a chance to have the above parameters defined also for system to frame-buffer transfers? For example Unichrome / Unichrome Pro currently requires both to be 16 for PCI DMA to work, and as briefly discussed on the dri-devel list, system / frame-buffer bounce buffers to fix alignments may be very undesirable. </pre> </blockquote> <pre wrap="">I'm not quite clear on what you're asking about -- you said something about dst_addr%4 == src_addr%4. EXA doesn't have anything to help you with that -- it can only ensure that the offset in card space is aligned to a multiple of some number, and/or the pitch of the pixmap is aligned to some number. However, simply having the on-card offset aligned to 16 and then doing a fixup on the system memory buffer (if necessary, which it usually wouldn't be, I bet) after copying out seems reasonable to me. </pre> </blockquote> <pre wrap="">I'm not sure how EXA uses system memory buffers, but if they are used as temporary storage, then it would be desirable to be able to prescribe pitch and padding alignments. However, if they always are set up by other parts of the X server or shm clients it is clear that they cannot take alignment constraints into account. </pre> </blockquote> <pre wrap="">On CreatePixmap, EXA gets a pixmap that's filled out with a pointer to the location of the pixmap in system memory (and a pitch, etc.). It can then wrap that -- in EXA's case, it optionally replaces that info with a pointer to framebuffer memory with a (probably) different pitch. So only the on-card addresses are aligned. We could probably free those pointers and make up some new ones with appropriate alignment, but I'm dubious of adding more EXA code until we show that more than one chipset is going to want it. </pre> </blockquote> <pre wrap=""> What chipset doesn't want it? All chipsets I'm somewhat familiar with (mga, mach64, r128) have alignment constraints for system memory. On mach64 and r128 the source address's two lower bits are used for both source and destination. The lack of scatter-gather ability on mga would mean emulating it by using one page to hold one (or more) line(s). And even if mga had scatter-gather ability it would still require aligned system memory buffers since it handles system memory exactly as it handles video memory. </pre> </blockquote> Is there an EXA driver that implements system-to-framebuffer or framebuffer-to-system memory copy using DMA today? Furthermore, Does EXA consider this a pipelined operation requiring an explicit sync or is the operation expected to have finished when the driver function returns? /Thomas </body> </html>