Re: [PATCH] Tile Blitting

[Antonino Daplas <adaplas@pol.net>]

On Fri, 2003-02-28 at 02:25, Michel Dänzer wrote:
> On Don, 2003-02-27 at 15:15, Antonino Daplas wrote: 
> > On Thu, 2003-02-27 at 09:18, James Simmons wrote:
> >  
> > > > Thus, the restriction that the buffer must be completely copied by the
> > > > driver before returning.  And because of this restriction, an extra copy
> > > > which might be unnecessary cannot be avoided (this was noted by Petr).
> > > > 
> > > > Treating the buffer as a ringbuffer, we eliminate these restrictions.
> > > 
> > > I didn't realize that the below was a ringbuffer implementation. The name
> > > threw me off. 
> > 
> > Well, it's not strictly a ringbuffer implementation.  This would require
> > a head and tail pointer where fbcon will adjust the tail and the
> > driver/hardware will adjust the head.  This will be very difficult to
> > implement in a device independent manner.  So we just cheat by issuing
> > an fb_sync() per loop to flush all pending commands.
> 
> That still seems suboptimal though. What the DRM often does is have the
> chip write an age value to a scratch register when it's done processing
> something. Maybe something like that could be used to avoid waiting for
> the chip to go idle at all?
> 

Yes, it is certainly suboptimal. But the fb_sync() will be done only
when the pointer wraps to the beginning of the buffer and only if the
buffer can be DMA'd by the chip.

To support these types of buffers, we can change pixmap.offset to head
and tail. The buffer is empty when head == tail.  Then, fbcon
continually adjusts the tail to tail+size, and when the chip is done
processing that particular bitmap, it will adjust the head to
head+size.  Then instead of doing an fb_sync(), fbcon will just busy
loop waiting for the buffer to have enough space for the next set of
bitmaps.

This will involve per chipset support, the reason why I did not do it
like this.  It can be added, but it will not be default behavior.

PS:  I remember that practically all drivers do some form of syncing
before each operation, and no one complained :-).

Tony  
 




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf