Re: Re: [PATCH] sisfb accel capabilities

["Antonino A. Daplas" <adaplas@hotpop.com>]

On Thursday 03 June 2004 21:26, David Eger wrote:
> Quoting Thomas Winischhofer <thomas@winischhofer.net>:
> > David Eger wrote:
> > > The following patch updates sisfb for the new fb accel capabilities
> > > patch I'm sending upstream.  By default, this patch will rely on your
> > > copyarea() and fillrect() accel functions instead of the panning.
> >
> > Could you give me any hint why this should be faster than panning?
>
> The logic to prefer copyarea()/fillrect() to panning is in the main patch. 
> If panning is faster than using these for most cards, then the default when
> both are available should be panning as you say.  But I'll need numbers to
> determine that ;-)  I think many drivers just map a chunk of video ram just
> big enough for the requested resolution, so panning does zero for them :-/

I have benchamarked them before (sometime last year).  Panning (with vyres at 
least 2x yres) is significantly faster than without panning.  If I remember 
correctly, I tested at 1024x768, 8bpp, vyres = 4*yres, all drawing functions 
are accelerated.  Without panning, 'time cat /usr/src/linux/Documentation' 
finished in around 2 seconds.  With panning, it was done in 0.5 sec.

And if vyres = yres, then the driver should disable the panning/wrapping flag.  
Or fbcon should at least recognize that panning may be impossible or not very 
efficient if vyres < yres*2.

>
> > 1) fillrect and copyarea WERE (resp. ARE) being called here despite your
> > previous statement that they were not. Fillrect is used to clear every
> > line after pressing enter, and copyrect was used to copy the buffer to
> > the start of the virtual screen when the end was reached.)
>
> bizarre.  For radeonfb, fillrect() was called to clear the last line as you
> say, but copyarea() never was.  I'll have to dig back through the old code
> to really grok your statement.

Yes, this is true.  Once you've scrolled down to the end of virtual memory, 
the last screenful of data will be copied to the beginning of the 
framebuffer.  Then the whole scrolling process starts all over again. 

(This is what I was trying to point out before, panning will always involve a 
copyarea.  Also, instead of copying, maybe  the last screenful of data can be 
redrawn.  Advantage to framebuffers which has panning but with slow fb reads.  
Currently, the latter is not available).
  
Tony




-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504