Re: [ PATCH-LINK ] fb accel capabilities - take 2

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

On Sunday 30 May 2004 19:44, Thomas Winischhofer wrote:
> David Eger wrote:
> > I'll add some comments to the patch :)
> >
> > The intent for the FBINFO_HWACCEL_fnName flags is to say that the
> > hardware will be smart about it (i.e., it ought to be fast).  New fb
> > drivers have been filling in copyarea() with cfb_copyarea() (that is, the
> > software version) or more opaquely filling in copyarea() with their own
> > mydriver_copyarea(), and then conditionally calling cfb_copyarea()
> > depending on the noaccel flag.
>
> Evidently.
>
> > With the patch, there are a bunch of these "is X really hardware
> > accelerated?" flags in fbinfo->flags, as well as FBINFO_HWACCEL_DISABLED
> > which should tell the driver to not use its acceleration engine --- and
> > use unaccelerated versions of copyarea(), fillrect(), imageblit(); and
> > FBINFO_MODULE (is the driver loaded as a module?)
>
> So far so good. Can't see a reason for partly disabling acceleration,
> but ok.
>
> >>Erm, I wasn't aware of this. Interesting... Personally, since sisfb does
> >>y-panning I didn't see any speed regressions compared with 2.4 yet.
> >
> > So with my patch, you'd see a regression in speed until you flag that
> > your driver can do hardware panning.  I thought it would be good for our
> > small brains to put all the flags for this in one place instead of
> > testing the (x/y)panstep variables for zero...
>
> There is another issue with panning. How does the new fbcon code decide
> how big the virtual screen shall be (if it cares at all)? Will there be
> a change in behavior?

There shouldn't be a change in behavior.  The console virtual screen 
(display->vrows) is still based on var->yres_virtual, which the driver should 
set.  fbcon also checks if var->ypanstep != 0 if the driver can do panning or 
not.  The main intent of the capability flags is choosing the best scrolling 
mode.  So in pseudo_code:

if (cannot_pan && fb_read_is_very_slow)
	no_pan + redraw;
else if (cannot_pan && fb_read_is_fast)
	no_pan + move;
else if (can_pan && fb_read_is_very_slow)
	pan + redraw;
else /* pan + fb_read_is_fast */
	pan + move;

/* an accelerated copyarea == fb_read is fast */
/* With PCI cards, fb_read is magnitudes slower than fb_write */

Of course, pan+redraw is still not supported by fbcon, so this resolves to 
no_pan + redraw.

>
> Right now, this is more or less a hack: sisfb, unless explicitly told
> not to do so (nomax or noypan), will maximize the virtual y resolution
> on all var's it receives. DirectFB disables this "auto-maximizing"
> feature with a respective ioctl before changing the mode etc. Works
> fine. Dunno if other drivers do the same. Advantage is that users get

I think other drivers do the same.  But syntax might be different, ie (if 
var->yres_virtual == 0, then maximize var->yres_virtual, or something like 
that).

> the fastest possible console by default (without using fbset or the like
> to set the virtual screen size.)
>
> Do I have to expect this mechanism to fail? IOW: (No, not io-write, in
> other words ;)) Will the panning stuff change in the fbcon layer
> breaking this?
>
> >>Are these to set/cleared exclusively by the driver or must the driver
> >>expect them to change? (I mean for example that fbset in 2.4 could be
> >>used to disable acceleration, which is important to DirectFB)
> >

The accel capability bits should be set/cleared exclusively by the driver 
depending on it's capability (duh) or if var->accel_flags is set or not.  
 
> > *really*?  I was wondering about that.  I'll have to go see how that
> > works...
>
> Assumingly simple. Set/clears FB_ACCELF_TEXT. DirectFB uses the same
> technique. Your new flags will break both.
>

The new flags should not break DirectFB if the driver correspondingly sets/
clears the capability bits depending on the setting of var->accel_flags.

> >>Is there any driver already finished so that I can look it up somewhere?
> >
> > There's a patch for radeonfb (my video card ;-) )
>
> I already saw that. Will take a closer look.
>
> >>Will an old driver (status as of now) work at all with the new flags not
> >>being touched? Will it compile? (That *should* work IMHO)
> >
> > /me nods.  It should. I tried compiling all of the drivers, and most of
> > them compiled.  The few drivers that didn't seemed to be pure 2.4 API
> > code that no one has loved for a long time :-/  Ah well..
>
> (Assume you mean 2.5 API...?)
>
> If they should compile you will need the mentioned compat-#define's in
> the long run...
>
> Thomas




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click