Re: [PATCH 17/41] fbdev: Add drawing functions forframebuffers in system RAM

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

On Wed, 2007-05-02 at 21:55 +0100, James Simmons wrote:
> > > > 	Hi Tony,
> > > > 
> > > > > The generic drawing functions (cfbimgblt, cfbcopyarea, 
> > > > > cfbfillrect) assume
> > > > > that the framebuffer is in IO memory.  However, we have 3 
> > > > > drivers (hecubafb,
> > > > > arcfb, and vfb) where the framebuffer is allocated from 
> > > > > system RAM (via
> > > > > vmalloc). Using _raw_read/write and family for these drivers 
> > > > > (as used in
> > > > > the cfb* functions) is illegal, especially in other platforms.
> > > > 
> > > > This is also true for ps3fb. I'll update the support for that once this
> > > > patch has hit mainline.
> > > 
> > > Bloat.
> > 
> > Only the source gets larger.  Only drivers that need it will compile it.
> > 
> > >  It would be much easier to replace the FB_WRITEL and FB_READL 
> > > macros.
> > 
> > Of course it's not as simple as replacing FB_WRITEL and FB_READL. Think
> > very carefully. 
> > 
> > Hint1: #define FB_MAX 32
> > Hint2: sparse
> 
> Yeap. fbwrite/fbread are not flexable enough. The is way I put hooks into
> struct fb_pixmap for writing/reading the framebuffer.

I did try that too, but the drawing functions are part of the innermost
loop, in an extremely hot path.  Replacing those macros with function
pointers will drop the performance considerably.  Remember the
memcpy/for-loop replacement?  The speed degradation was significant and
it's not even in the hottest path.

Secondly, how would you reconcile sparse annotations?

Tony



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/