EXA pixmap alignments.

[Eric Anholt]

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.

I would guess that the best thing to do would be, in your
DownloadFromScreen (DFS), check if the in-system alignment is good
enough, and if not, just malloc a new temporary buffer with padding for
your alignment, copy in to that, and memcpy from there to where it needs
to go.  I'm betting that a lot of mallocs out there are going to give
you 16 byte alignment on the original system memory buffer anyway.

-- 
Eric Anholt                                     eta at lclark.edu
http://people.freebsd.org/~anholt/              anholt at FreeBSD.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20050926/53c9117c/attachment.pgp>