Thread (67 messages) 67 messages, 8 authors, 2004-04-30

Re: [PATCH] radeonfb(): memmove() fix -- this one works ;-)

From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: 2004-04-22 08:23:50

Possibly related (same subject, not in this thread)

On Wed, 22 Apr 2004, Antonino A. Daplas wrote:
On Thu, 2004-04-22 at 02:13, James Simmons wrote:
quoted
quoted
quoted
quoted
This is true for PCI/AGP, but may not be true for unified memory systems.
Right, but that confirms my opinion that the choice of the technique used
shall be under control of the driver
Agreed. So a hint would be the most appropriate.
Hi Antonino. Haven't heard from you in a while.
Yeah, been busy.
quoted
I agree. What if we add to vmode in struct fb_screeninfo.
We have

FB_VMODE_YWRAP		256
FB_VMODE_SMOOTH_XPAN	512

We can add more fields. Of course we have to figure out what the common
case would be.
We can add:

FB_VMODE_YPAN
FB_VMODE_REDRAW /* will use imageblit */
FB_VMODE_MOVE   /* will use copyarea */

Personally, I think FB_VMODE_REDRAW should be the default as it is
faster than FB_VMODE_MOVE for most PCI cards.

Just to be clear.

1.  If without a ypan or ywrap, fbcon can either do a redraw or a move

2.  If with ypan or ywrap, then fbcon can only do a move.

Ypan + redraw (FB_VMODE_MOVE | FB_VMODE_REDRAW) is not supported, and I
consider this combination to give the fastest and smoothest scrolling
action if driver does not have any hardware acceleration in most cards.
Perhaps this can be added?
Perhaps a different approach in announcing these capabilities is more
appropriate? The above is very console-centric. And since it's set by the
fbdev, conceptually it does not belong in fb_var_screeninfo, but in
fb_fix_screeninfo.

What we really want to know here is whether redrawing is faster than copying,
i.e. whether reading from the frame buffer is fast or slow, and whether
fb_copyarea and fb_imageblit are fast or slow.

Right now we have in fb_fix_screeninfo:
  - [xy]panstep, for hardware panning
  - ywrapstep, for hardware ywrap

We can add a capability field with some flags that indicates that
  - fb_copyarea is accelerated or not
  - fb_imageblit is accelerated or not
  - fb_write is much faster than fb_read
(I don't think it matters much to announce an accelerated fb_fillrect, although
 we may want to do that for consistency)

I chose the above so we have reasonable defaults if the capability field is 0.

All other logic can be derived by fbcon from these capabilities, right?

E.g. wrap and pan are always faster than copying, since (usually) they involve
only one register access, while copying is O(n).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help