From: David Eger <hidden> Date: 2004-03-26 00:27:04
are scrollmode or accel_flags meaningful to anyone here?
Paging through fbcon.c, I've realized why the radeonfb driver is still
slow -- the accelerated functions are never being called!
Hardwiring scrollmode to __SCROLL_YMOVE in updatescrollmode() makes my
console go a lot faster :)
So within fbcon.c why is there a "scrollmode" variable which can be set
to: __SCROLL_YWRAP, __SCROLL_YPAN, __SCROLL_YREDRAW, or __SCROLL_YMOVE?
Also accel_flags actually useful to anyone? I see in the fb code some
half-hearted attempts to test for FB_ACCELF_TEXT, but it's not clear at
all to me where these accel flags are supposed to be set... are they even
relevant with the new accel interface? It seems all this is properly
replaced by filling in the fbops to either the driver's custom fillrect()
or cfb_fillrect(), no?
-dte
-------------------------------------------------------
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
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-03-26 02:22:03
On Fri, 2004-03-26 at 11:14, David Eger wrote:
are scrollmode or accel_flags meaningful to anyone here?
Paging through fbcon.c, I've realized why the radeonfb driver is still
slow -- the accelerated functions are never being called!
Hardwiring scrollmode to __SCROLL_YMOVE in updatescrollmode() makes my
console go a lot faster :)
Heh, good catch ;)
So within fbcon.c why is there a "scrollmode" variable which can be set
to: __SCROLL_YWRAP, __SCROLL_YPAN, __SCROLL_YREDRAW, or __SCROLL_YMOVE?
Never been too sure about those. James ?
Also accel_flags actually useful to anyone? I see in the fb code some
half-hearted attempts to test for FB_ACCELF_TEXT, but it's not clear at
all to me where these accel flags are supposed to be set... are they even
relevant with the new accel interface? It seems all this is properly
replaced by filling in the fbops to either the driver's custom fillrect()
or cfb_fillrect(), no?
I think they are irrelevant, I removed most of the stuff using that
in radeonfb, it would not work properly. I'm not sure what to do with
the scrollmode though. I'll have to experiment.
Ben.
-------------------------------------------------------
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
On Fri, 26 Mar 2004, Benjamin Herrenschmidt wrote:
On Fri, 2004-03-26 at 11:14, David Eger wrote:
quoted
are scrollmode or accel_flags meaningful to anyone here?
Paging through fbcon.c, I've realized why the radeonfb driver is still
slow -- the accelerated functions are never being called!
Hardwiring scrollmode to __SCROLL_YMOVE in updatescrollmode() makes my
console go a lot faster :)
Heh, good catch ;)
quoted
So within fbcon.c why is there a "scrollmode" variable which can be set
to: __SCROLL_YWRAP, __SCROLL_YPAN, __SCROLL_YREDRAW, or __SCROLL_YMOVE?
Never been too sure about those. James ?
These are hints for fbcon to use different types of scrolling. Using special
hardware features is usually faster than doing dumb copies.
Examples:
- Many drivers implement panning in a large virtual screen. This can be used
to scroll and avoid copying in most copies.
- With amifb you can not only pan, but also wrap the display by N lines
(i.e. visible line i = physical line (i+N) % yres).
- Some frame buffers are very slow to read, so it can be faster to just
redraw the display instead of copying.
More info in drivers/video/console/fbcon.[ch].
quoted
Also accel_flags actually useful to anyone? I see in the fb code some
half-hearted attempts to test for FB_ACCELF_TEXT, but it's not clear at
all to me where these accel flags are supposed to be set... are they even
relevant with the new accel interface? It seems all this is properly
replaced by filling in the fbops to either the driver's custom fillrect()
or cfb_fillrect(), no?
I think they are irrelevant, I removed most of the stuff using that
in radeonfb, it would not work properly. I'm not sure what to do with
the scrollmode though. I'll have to experiment.
It is (was?) mainly a flag to indicate the fbdev uses and thus owns the accel
engine. Userspace cannot mmap the MMIO registers and use the accel engine
unless it first clears this flag. It can also be used just to disable the accel
engine.
These days it seems like vt_cons[vc->vc_num]->vc_mode == KD_TEXT seems to
indicate the fbdev owns the accel engine, right James?
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
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-03-26 14:43:07
These are hints for fbcon to use different types of scrolling. Using special
hardware features is usually faster than doing dumb copies.
Yes, that all make sense, but there isn't a simple way for the fbdev
to set that now in 2.6 since it's in struct display which is now local
to fbcon. fbcon itself will initialize that to some value picked based
on the default var accel flags but I don't like that, espeically since
I think those flags should be deprecated.
It is (was?) mainly a flag to indicate the fbdev uses and thus owns the accel
engine. Userspace cannot mmap the MMIO registers and use the accel engine
unless it first clears this flag. It can also be used just to disable the accel
engine.
I know, I used them this way in 2.4, but with the 2.6 changes, they
becaome mostly unmanageable.
These days it seems like vt_cons[vc->vc_num]->vc_mode == KD_TEXT seems to
indicate the fbdev owns the accel engine, right James?
Yes.
Ben.
-------------------------------------------------------
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
On Sat, 27 Mar 2004, Benjamin Herrenschmidt wrote:
quoted
These are hints for fbcon to use different types of scrolling. Using special
hardware features is usually faster than doing dumb copies.
Yes, that all make sense, but there isn't a simple way for the fbdev
to set that now in 2.6 since it's in struct display which is now local
to fbcon. fbcon itself will initialize that to some value picked based
on the default var accel flags but I don't like that, espeically since
I think those flags should be deprecated.
Ywrap/ypan capabilities are announced in fb_fix_screeninfo, so fbcon knows.
W.r.t. redraw vs. copy for scrolling, perhaps some heuristics like PCI/AGP are
known to be slow for reading? Fbcon can find out whether a fbdev is on a
PCI/AGP bus by checking the device (once new driver model/sysfsication is
complete), right?
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
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-03-27 01:25:09
W.r.t. redraw vs. copy for scrolling, perhaps some heuristics like PCI/AGP are
known to be slow for reading? Fbcon can find out whether a fbdev is on a
PCI/AGP bus by checking the device (once new driver model/sysfsication is
complete), right?
But an fbdev that implements an accelerated copyarea ?
I don't want such heuristics in fbcon, they are just asking for trouble,
I think we should redraw on non-accelerated and copy on accelerated,
but then, it should be under more direct driver control. Also, fbcon
keeps "losing" the accel_flags for me.
One thing I don't like in the new fbcon is the way it deals with the
var structure anyway. I think it should have one var per VC.
Ben.
-------------------------------------------------------
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
On Sat, 27 Mar 2004, Benjamin Herrenschmidt wrote:
quoted
W.r.t. redraw vs. copy for scrolling, perhaps some heuristics like PCI/AGP are
known to be slow for reading? Fbcon can find out whether a fbdev is on a
PCI/AGP bus by checking the device (once new driver model/sysfsication is
complete), right?
But an fbdev that implements an accelerated copyarea ?
I don't want such heuristics in fbcon, they are just asking for trouble,
I think we should redraw on non-accelerated and copy on accelerated,
You mean, if ywrap/ypan is not available/not possible (e.g. partial screen
scrolls)? Yes, that makes sense.
but then, it should be under more direct driver control. Also, fbcon
Which means additional flags to fb_fix_screeninfo...
keeps "losing" the accel_flags for me.
One thing I don't like in the new fbcon is the way it deals with the
var structure anyway. I think it should have one var per VC.
I agree.
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
From: James Simmons <hidden> Date: 2004-03-29 17:50:55
quoted
But an fbdev that implements an accelerated copyarea ?
I don't want such heuristics in fbcon, they are just asking for trouble,
I think we should redraw on non-accelerated and copy on accelerated,
You mean, if ywrap/ypan is not available/not possible (e.g. partial screen
scrolls)? Yes, that makes sense.
Sounds like we need to update update_scrollmode. So what do we have so
far.
1. test for ywrap/ypan. This test should see if the screen is more than
two whole screens in size.
2. Test if xxxfb_copyarea is accelerated. If it is set to YMOVE.
3. If xxxfb_copyare is not accelerated then redraw the screen.
If I'm missing anything let me know.
Which means additional flags to fb_fix_screeninfo...
:-( I'm hoping we can develope some kind of nice logic. Often I seen
a driver writer use the wrong flag.
quoted
One thing I don't like in the new fbcon is the way it deals with the
var structure anyway. I think it should have one var per VC.
I agree.
Why do we need a var for ever VC. The card is on one hardware state at
all times. The only times we nned to be concern with changes is for
setfont, resize and VC switching. These are not common occurs. If the
fbcon layer can't get the data it needs from struct vc_data then the upper
console layer is broken.
-------------------------------------------------------
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
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-03-29 22:35:41
On Tue, 2004-03-30 at 03:50, James Simmons wrote:
Why do we need a var for ever VC. The card is on one hardware state at
all times. The only times we nned to be concern with changes is for
setfont, resize and VC switching. These are not common occurs. If the
fbcon layer can't get the data it needs from struct vc_data then the upper
console layer is broken.
I don't agree. If I set a special mode with fbset in one console I
wnat this mode to say in that console and only that console unless
I use -a. The vc_data doesn't carry enough informations to set a
mode. It would also make things a lot simpler for fbdev apps that
use a different mode.
Anyway, for the current mecanism to work, we need picking a mode
properly when resized or mode switched, which isn't the case right
now. The "var" that fbcon_resize pass to the fbdev is at best bogus
currently. The FB_ACTIVATE_FIND thing I did helps if the fbdev can
properly lookup for a mode (though there are still some issues in
radeonfb implementation of this as you have noticed).
Ben.
-------------------------------------------------------
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