fbdraw 0.1 available

fbdraw 0.1 available

[Zack]

My changes to permit (optional) in-kernel drawing for applications
are available. It's only version 0.1 at this point, meaning alpha,
but I'm happy with the performance and structure. I've included
a test application that allows benchmarking.

home.comcast.net/~plinius/fbdraw-0.1.tar.gz

To install, move the tarfile to the 2.6.8.1 root dir, and use
tar zxfv fbdraw-0.1.tar.gz.

Constructive criticism is welcome.

Zack



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: fbdraw 0.1 available

[Geert Uytterhoeven]

On Fri, 10 Sep 2004, Zack wrote:
> My changes to permit (optional) in-kernel drawing for applications
> are available. It's only version 0.1 at this point, meaning alpha,
> but I'm happy with the performance and structure. I've included
> a test application that allows benchmarking.
>
> home.comcast.net/~plinius/fbdraw-0.1.tar.gz
>
> To install, move the tarfile to the 2.6.8.1 root dir, and use
> tar zxfv fbdraw-0.1.tar.gz.
>
> Constructive criticism is welcome.

A few comments/questions:

  - Is there any special reason why you implement your own fb_fill_area() and
    fb_copy_area() (which doesn't do anything?), while fb_fillrect() and
    fb_copyarea() already exist?

  - Do you have compared the performance of your fbdraw compared to user space
    mmap()ing the frame buffer and doing all drawings in user space?

BTW, I'm also considering exporting fb_fillrect(), fb_copyarea(), and
fb_imageblit() to userspace, but for a different reason.

Right now applications need to know the exact frame buffer layout. For most
modern PC graphics cards that's OK, since they all do cfb8/16/24/32. But older
(usually unaccelerated) and embedded hardware may use a different layout (e.g.
seperate buffers for even and odd display lines on some set top box hardware,
bitplanes, ...) putting a severe burden on applications.

By letting the application draw to a fixed format cfb8 (pseudocolor) or cfb32
(RGBA) shadow buffer and call the kernel for updating the screen, this can be
solved in a generic way.  Currently now fb_imageblit() already has to do the
conversion from cfb8 to native layout anyway.

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: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: fbdraw 0.1 available

[Zack]

Geert Uytterhoeven wrote:
> 
>   - Is there any special reason why you implement your own fb_fill_area() and
>     fb_copy_area() (which doesn't do anything?), while fb_fillrect() and
>     fb_copyarea() already exist?

Yes, for 3 reasons:
1. I want to be able to clip graphics to a subset of the screen, so that
later the screen will be shareable between processes. In 0.1b, this
clipping works quite effectively.
2. I wanted to increase the speed. My routine's loops are slightly
unfolded to avoid branching and the performance is therefore better.
3. If I later update it for MMX or other changes, it would be
easier for me to do so if it's my code and infrastructure.

>   - Do you have compared the performance of your fbdraw compared to user space
>     mmap()ing the frame buffer and doing all drawings in user space?

Well, no. As I mentioned before the reason for putting things in the
kernel is that it ensures the code will remain small and more
carefully optimized. Most things in userspace tend to become bloated
eventually and often never get optimized.

> BTW, I'm also considering exporting fb_fillrect(), fb_copyarea(), and
> fb_imageblit() to userspace, but for a different reason.

> Right now applications need to know the exact frame buffer layout. For most
> modern PC graphics cards that's OK, since they all do cfb8/16/24/32. But older
> (usually unaccelerated) and embedded hardware may use a different layout (e.g.
> seperate buffers for even and odd display lines on some set top box hardware,
> bitplanes, ...) putting a severe burden on applications.

I agree that odd hardware is a burden, and one which fbdraw can
alleviate by hiding the complexity behind the abstraction.

Speaking of which, I wrote a set of fast 4bpp VGA routines that are
equivalent to the fbdraw routines. The latest version I wrote in
16bit x86 assembly so they are very fast. It will eventually add
these to fb.

> By letting the application draw to a fixed format cfb8 (pseudocolor) or cfb32
> (RGBA) shadow buffer and call the kernel for updating the screen, this can be
> solved in a generic way.  Currently now fb_imageblit() already has to do the
> conversion from cfb8 to native layout anyway.

But that shadow buffer is bloat, and the blit takes time.

If you want to draw an RGB image onto the screen, better to convert
it to native format and draw that quickly. If you have to draw it
again later, you'll hopefully have the native copy available.

Ciao,
Zack


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: fbdraw 0.1 available

[Antonino A. Daplas]

On Saturday 11 September 2004 10:43, Zack wrote:
> My changes to permit (optional) in-kernel drawing for applications
> are available. It's only version 0.1 at this point, meaning alpha,
> but I'm happy with the performance and structure. I've included
> a test application that allows benchmarking.
>
> home.comcast.net/~plinius/fbdraw-0.1.tar.gz
>
> To install, move the tarfile to the 2.6.8.1 root dir, and use
> tar zxfv fbdraw-0.1.tar.gz.
>
> Constructive criticism is welcome.

(Better if you provided an inlined file so it's easier to make comments) 

Here's a few, just from a quick scan:

1. First, you need to follow Documentation/CodingStyle.

2. Do not directly access framebuffer memory, use: 

fb_{read|write}{b|w|l}

3. Do not use copy_{to|from}_user when the destination/source is the
framebuffer.

4. Do not memset the framebuffer.  You can probably create an equivalent
function using fb_read/write.  (Once, we have fb_memset and fb_memcpy, but
they're gone in 2.6).

Tony




-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: fbdraw 0.1 available

[Zack]

Antonino A. Daplas wrote:

> 1. First, you need to follow Documentation/CodingStyle.

OK, I've made some strides in that direction.

> 2. Do not directly access framebuffer memory, use: 
> 3. Do not use copy_{to|from}_user when the destination/source is the
> framebuffer.
> 4. Do not memset the framebuffer.  You can probably create an equivalent
> function using fb_read/write.  (Once, we have fb_memset and fb_memcpy, but
> they're gone in 2.6).

Fixed.

Incidentally I am wondering, with cross-platform compatibility
in mind I have been coding assuming that fb_{read|write}[wl] must be
short/long aligned. Is that assumption correct?

I've also added my copyarea routine. At first I tried to make use
of cfb_copyarea but it proved very buggy in 24bpp.

New code is at http://home.comcast.net/~plinius.
Cheers,
Zack


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: fbdraw 0.1 available

[Geert Uytterhoeven]

On Sun, 12 Sep 2004, Zack wrote:
> > 2. Do not directly access framebuffer memory, use:
> > 3. Do not use copy_{to|from}_user when the destination/source is the
> > framebuffer.
> > 4. Do not memset the framebuffer.  You can probably create an equivalent
> > function using fb_read/write.  (Once, we have fb_memset and fb_memcpy, but
> > they're gone in 2.6).
>
> Fixed.
>
> Incidentally I am wondering, with cross-platform compatibility
> in mind I have been coding assuming that fb_{read|write}[wl] must be
> short/long aligned. Is that assumption correct?

Yes, that's the safest.

> I've also added my copyarea routine. At first I tried to make use
> of cfb_copyarea but it proved very buggy in 24bpp.

What about fixing the bugs in the existing code, instead of adding a new
routine that does the same? ;-)

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: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php