Re: Re: [PATCH] sisfb accel capabilities

On Thursday 03 June 2004 21:26, David Eger wrote:

Quoting Thomas Winischhofer [off-list ref]:

quoted

David Eger wrote:

quoted

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.

quoted

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