EXA pixmap alignments.

[Thomas Hellstrom]

Ville Syrjälä wrote:

>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.
>
>  
>
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20050927/9c468658/attachment.html>