From: David E. <ege...@th...> - 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 |
From: Benjamin H. <be...@ke...> - 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. |
From: Geert U. <ge...@li...> - 2004-03-26 07:14:45
|
On Fri, 26 Mar 2004, Benjamin Herrenschmidt wrote: > 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 ? 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]. > > 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 -- ge...@li... 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 |
From: Benjamin H. <be...@ke...> - 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. |
From: Geert U. <ge...@li...> - 2004-03-26 15:03:29
|
On Sat, 27 Mar 2004, Benjamin Herrenschmidt wrote: > > 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 -- ge...@li... 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 |
From: Benjamin H. <be...@ke...> - 2004-03-27 01:25:13
|
> 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. |
From: Geert U. <ge...@li...> - 2004-03-28 08:16:12
|
On Sat, 27 Mar 2004, Benjamin Herrenschmidt wrote: > > 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 -- ge...@li... 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 |
From: James S. <jsi...@in...> - 2004-03-29 17:50:56
|
> > 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. > > 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. |
From: Benjamin H. <be...@ke...> - 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. |