Enabling Hardware acceleration in existing framebuffer driver

Enabling Hardware acceleration in existing framebuffer driver

[Keith Williams]

Hi, all,

I have an embedded board with a s1d13506 epson display chip.  There is a 
s1d13xxxfb driver that was written for the '806 that generally works 
well for the '506.

The '506 does have some 2D hardware acceleration capabilities.  Last 
night I wrote a fillrect routine as an initial test of how much 
performance improvement I could potentially see from enabling acceleration.

However, neither DirectFB nor fbset is picking up on the enabled 
acceleration.  I'm not sure if there is something more that I need to do.

Below are portions of the driver that I modified:

        info->par = default_par;
        info->fbops = &s1d13xxxfb_fbops;
        info->flags = FBINFO_DEFAULT | FBINFO_HWACCEL_YPAN | 
FBINFO_HWACCEL_FILLRECT;

--The above should set the fb_info flags to show that fillrect 
acceleration is available


void s1d13xxxfb_fillrect (struct fb_info *p, const struct fb_fillrect *rect)
{
        u32 destination_address;
        struct s1d13xxxfb_par *par = p->par;

        if (p->state != FBINFO_STATE_RUNNING)
                return;

        destination_address = (((rect->dy)*480*2)+(rect->dx)*2);

                s1d13xxxfb_writereg(par, S1DREG_BBLT_DST_START0, 
(destination_address & 0xff));
                s1d13xxxfb_writereg(par, S1DREG_BBLT_DST_START1, 
((destination_address >> 8) & 0xff));
                s1d13xxxfb_writereg(par, S1DREG_BBLT_DST_START2, 
((destination_address >> 16) & 0xff));

/// SNIP ///

--This is the beginning of the fillrect acceleration routine (right now 
just hardcoded for my particular set-up)



/* framebuffer information structures */

static struct fb_ops s1d13xxxfb_fbops = {
        .owner          = THIS_MODULE,
        .fb_set_par     = s1d13xxxfb_set_par,
        .fb_setcolreg   = s1d13xxxfb_setcolreg,
        .fb_blank       = s1d13xxxfb_blank,

        .fb_pan_display = s1d13xxxfb_pan_display,

        /* to be replaced by any acceleration we can */
        .fb_fillrect    = s1d13xxxfb_fillrect,
        .fb_copyarea    = cfb_copyarea,
        .fb_imageblit   = cfb_imageblit,
};

--This is I've added the s1d13xxxfb_fillrect to the fb_ops structure.

Is there anything else that I need to do?

Thanks for any insight.

Keith



-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

Re: Enabling Hardware acceleration in existing framebuffer driver

[Krzysztof Helt]

On Fri, 04 Jul 2008 11:56:02 -0400
Keith Williams <espian@linuxinstruments.com> wrote:

> Hi, all,
> 

> The '506 does have some 2D hardware acceleration capabilities.  Last 
> night I wrote a fillrect routine as an initial test of how much 
> performance improvement I could potentially see from enabling acceleration.
> 
> However, neither DirectFB nor fbset is picking up on the enabled 
> acceleration.  I'm not sure if there is something more that I need to do.
> 

The fillrect acceleration is probably used but rarely. 
One sure way to trigger it is to issue the "clear" command on the 
frame buffer console. Try "time clear" on a big resolution screen with and 
without your change. You should see a difference from few to few tens times
in speed.

The more useful is both the copyarea and imageblit acceleration. Both are
used during console scrolling (the imageblit is preferred but on some cards
the copyarea is faster).

I don't know about the DirectFB so I cannot comment.

Regards,
Krzysztof

----------------------------------------------------------------------
Nie ma jak Hold'em. Zagraj w pokera!
Kliknij >>> http://link.interia.pl/f1e68


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

Re: Enabling Hardware acceleration in existing framebuffer driver

[Keith Williams]

> The fillrect acceleration is probably used but rarely. 
> One sure way to trigger it is to issue the "clear" command on the 
> frame buffer console. Try "time clear" on a big resolution screen with and 
> without your change. You should see a difference from few to few tens times
> in speed.
>
> The more useful is both the copyarea and imageblit acceleration. Both are
> used during console scrolling (the imageblit is preferred but on some cards
> the copyarea is faster).
>
> I don't know about the DirectFB so I cannot comment.
>
>   

Thanks for the reply.

The fillrect was the simplest to implement.  I agree that the others
will be much higher value.

In DirectFB there are a set of benchmarks that run through all of the
different drawing types including filled rectangles.  That is what I am
using as my baseline.

However, even with the above code I don't see a change in the benchmark
numbers leading me to believe that the acceleration is not being used.

Additionally, fbset shows accel to be false.  Even if I do a "fbset
-accel true", it still reports false.

This is why I don't believe that the acceleration is being picked-up.
Any other ideas with the driver code/things that I am missing?

Thanks,

Keith



-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

Re: Enabling Hardware acceleration in existing framebuffer driver

[Krzysztof Helt]

On Fri, 04 Jul 2008 12:33:57 -0400
Keith Williams <espian@linuxinstruments.com> wrote:

> The fillrect was the simplest to implement.  I agree that the others
> will be much higher value.
> 
> In DirectFB there are a set of benchmarks that run through all of the
> different drawing types including filled rectangles.  That is what I am
> using as my baseline.
> 

I don't know DirectFB. I am not sure if the DirectFB uses the frame buffer
acceleration or its own. 

> However, even with the above code I don't see a change in the benchmark
> numbers leading me to believe that the acceleration is not being used.
> 

Please do simple test: give "time clear" command from the command line.

> Additionally, fbset shows accel to be false.  Even if I do a "fbset
> -accel true", it still reports false.
> 

AFAIK, the fbset tool uses the obsolete FB_ACCELF_TEXT flag. 
If your driver does not set this flag and does not use it you won't
see any difference.

> This is why I don't believe that the acceleration is being picked-up.

The only sure way is to put printk inside the fillrect function and
watch if it appeared in the dmesg output. The "clear" command
is good at useing the fillrect acceleration.

Regards,
Krzysztof


----------------------------------------------------------------------
Pogoda na dzis.
Sprawdz >>> http://link.interia.pl/f1e42


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

Re: Enabling Hardware acceleration in existing framebuffer driver

[Ville Syrjälä]

On Fri, Jul 04, 2008 at 07:32:26PM +0200, Krzysztof Helt wrote:
> On Fri, 04 Jul 2008 12:33:57 -0400
> Keith Williams <espian@linuxinstruments.com> wrote:
> 
> > The fillrect was the simplest to implement.  I agree that the others
> > will be much higher value.
> > 
> > In DirectFB there are a set of benchmarks that run through all of the
> > different drawing types including filled rectangles.  That is what I am
> > using as my baseline.
> > 
> 
> I don't know DirectFB. I am not sure if the DirectFB uses the frame buffer
> acceleration or its own. 

DirectFB has it's own low level gfx drivers. It can use fbdev for mode
switching but that's all.

In fact there is no way to call fbdev accel code from userspace.

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

Re: Enabling Hardware acceleration in existing framebuffer driver

[Robert Reif]

[-- Attachment #1: Type: text/plain, Size: 926 bytes --]

Ville Syrjälä wrote:
> On Fri, Jul 04, 2008 at 07:32:26PM +0200, Krzysztof Helt wrote:
>   
>> On Fri, 04 Jul 2008 12:33:57 -0400
>> Keith Williams <espian@linuxinstruments.com> wrote:
>>
>>     
>>> The fillrect was the simplest to implement.  I agree that the others
>>> will be much higher value.
>>>
>>> In DirectFB there are a set of benchmarks that run through all of the
>>> different drawing types including filled rectangles.  That is what I am
>>> using as my baseline.
>>>
>>>       
>> I don't know DirectFB. I am not sure if the DirectFB uses the frame buffer
>> acceleration or its own. 
>>     
>
> DirectFB has it's own low level gfx drivers. It can use fbdev for mode
> switching but that's all.
>
> In fact there is no way to call fbdev accel code from userspace.
>
>   
I'm adding hardware acceleration to the sparc leo driver and this is 
what I am using for user space testing:

[-- Attachment #2: fbmem.diff.txt --]
[-- Type: text/plain, Size: 1645 bytes --]

diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 776f7fc..14d5586 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1023,6 +1023,9 @@ fb_ioctl(struct inode *inode, struct fil
 	struct fb_con2fbmap con2fb;
 	struct fb_cmap_user cmap;
 	struct fb_event event;
+	struct fb_copyarea area;
+	struct fb_fillrect rect;
+	struct fb_image image;	
 	void __user *argp = (void __user *)arg;
 	int i;
 	
@@ -1103,6 +1106,27 @@ #endif /* CONFIG_KMOD */
 		info->flags &= ~FBINFO_MISC_USEREVENT;
 		release_console_sem();
 		return i;
+	case FBIOFILLRECT:
+		if (copy_from_user(&rect, argp, sizeof(rect)))
+			return -EFAULT;
+		acquire_console_sem();
+		fb->fb_fillrect(info, &rect);
+		release_console_sem();
+		return 0;
+	case FBIOCOPYAREA:
+		if (copy_from_user(&area, argp, sizeof(area)))
+			return -EFAULT;
+		acquire_console_sem();
+		fb->fb_copyarea(info, &area);
+		release_console_sem();
+		return 0;
+	case FBIOIMAGEBLIT:
+		if (copy_from_user(&image, argp, sizeof(image)))
+			return -EFAULT;
+		acquire_console_sem();
+		fb->fb_imageblit(info, &image);
+		release_console_sem();
+		return 0;
 	default:
 		if (fb->fb_ioctl == NULL)
 			return -EINVAL;
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 72295b0..a369d0f 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -38,6 +38,9 @@ #define FBIOGET_GLYPH           0x4615
 #define FBIOGET_HWCINFO         0x4616
 #define FBIOPUT_MODEINFO        0x4617
 #define FBIOGET_DISPINFO        0x4618
+#define FBIOFILLRECT		0x4619
+#define FBIOCOPYAREA		0x461A
+#define FBIOIMAGEBLIT		0x461B
 
 
 #define FB_TYPE_PACKED_PIXELS		0	/* Packed Pixels	*/

[-- Attachment #3: fbtest.diff.txt --]
[-- Type: text/plain, Size: 1823 bytes --]

Index: fb.c
===================================================================
RCS file: /cvsroot/linux-fbdev/FBdev/utlilities/fbtest/fb.c,v
retrieving revision 1.7
diff -r1.7 fb.c
30c30
< static int fb_fd = -1;
---
> int fb_fd = -1;
Index: include/fb.h
===================================================================
RCS file: /cvsroot/linux-fbdev/FBdev/utlilities/fbtest/include/fb.h,v
retrieving revision 1.2
diff -r1.2 fb.h
19a20
> extern int fb_fd;
Index: tests/test001.c
===================================================================
RCS file: /cvsroot/linux-fbdev/FBdev/utlilities/fbtest/tests/test001.c,v
retrieving revision 1.1
diff -r1.1 test001.c
11a12
> #include <errno.h>
12a14,16
> #include <stdlib.h>
> #include <string.h>
> #include <sys/ioctl.h>
23a28,29
> #define FBIOFILLRECT	0x4619
> 
28a35,38
>     u8 * screen;
>     u32 bytes;
>     struct fb_fillrect rect;
>     enum test_res res = TEST_OK;
37a48,74
> 
>     bytes = (fb_var.xres * fb_var.yres * fb_var.bits_per_pixel) / 8;
>     if (!(screen = malloc(bytes)))
>         Fatal("malloc %d: %s\n", bytes, strerror(errno));
>     memcpy(screen, fb, bytes);
> 
>     for (i = 1, y0 = 0; i <= Y_BLOCKS; i++, y0 = y1) {
> 	y1 = i*fb_var.yres/Y_BLOCKS;
> 	for (j = 1, x0 = 0; j <= X_BLOCKS; j++, x0 = x1) {
> 	    pixel = (i+j) & 1 ? white_pixel : black_pixel;
> 	    x1 = j*fb_var.xres/X_BLOCKS;
> 	    rect.dx = x0;
> 	    rect.dy = y0;
> 	    rect.width = x1 - x0;
> 	    rect.height = y1 - y0;
> 	    rect.color = (i+j) & 1 ? 15 : 0;
> 	    rect.rop = ROP_COPY;
> 	
> 	    if (ioctl(fb_fd, FBIOFILLRECT, &rect) == -1) {
> 	        Fatal("ioctl FBIOFILLRECT: %s\n", strerror(errno));
> 	    }
> 	}
>     }
> 
>     if (memcmp(screen, fb, bytes) != 0)
> 	res = TEST_FAIL; 
>     free(screen);
39c76
<     return TEST_OK;
---
>     return res;

[-- Attachment #4: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

[-- Attachment #5: Type: text/plain, Size: 182 bytes --]

_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel