EXA pixmap alignments.

[Ville Syrjälä]

On Mon, Sep 26, 2005 at 01:04:58PM -0700, Eric Anholt wrote:
> On Mon, 2005-09-26 at 21:48 +0200, Thomas Hellstrom wrote:
> > Eric Anholt wrote:
> > 
> > >On Mon, 2005-09-26 at 09:55 +0200, Thomas Hellstrom wrote:
> > >  
> > >
> > >>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.
> > >>    
> > >>
> > >
> > >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.
> > >  
> > >
> > 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.
> 
> 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.

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.

-- 
Ville Syrjälä
syrjala at sci.fi
http://www.sci.fi/~syrjala/