Accelerated frame buffer functions

Accelerated frame buffer functions

[Haakon Riiser]

How can I use a frame buffer driver's optimized copyarea, fillrect,
blit, etc. from userspace?  The only way I've ever seen anyone use
the frame buffer device is by mmap()ing it and doing everything
manually in the mapped memory.  I assume there must be ioctls for
accessing the accelerated functions, but after several hours of
grepping and googling, I give up. :-(

Any help is greatly appreciated!

-- 
 Haakon

Re: Accelerated frame buffer functions

[linux-os]

On Wed, 2 Feb 2005, Haakon Riiser wrote:

> How can I use a frame buffer driver's optimized copyarea, fillrect,
> blit, etc. from userspace?  The only way I've ever seen anyone use
> the frame buffer device is by mmap()ing it and doing everything
> manually in the mapped memory.  I assume there must be ioctls for
> accessing the accelerated functions, but after several hours of
> grepping and googling, I give up. :-(
>
> Any help is greatly appreciated!
>

X-Windows already does this. Execute `/usr/bin/X11/x11perf -all` to watch.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

Re: Accelerated frame buffer functions

[Haakon Riiser]

[Dick Johnson]

> On Wed, 2 Feb 2005, Haakon Riiser wrote:
> 
>> How can I use a frame buffer driver's optimized copyarea, fillrect,
>> blit, etc. from userspace?  The only way I've ever seen anyone use
>> the frame buffer device is by mmap()ing it and doing everything
>> manually in the mapped memory.  I assume there must be ioctls for
>> accessing the accelerated functions, but after several hours of
>> grepping and googling, I give up. :-(
> 
> X-Windows already does this.

Yeah, I thought the X11 fbdev driver supported acceleration, but not
according to its manpage:

  fbdev is an Xorg driver for framebuffer devices.  This is a
  non-accelerated driver [...]

-- 
 Haakon

Re: Accelerated frame buffer functions

[Xavier Bestel]

Le mercredi 02 février 2005 à 15:21 +0100, Haakon Riiser a écrit :

> How can I use a frame buffer driver's optimized copyarea, fillrect,
> blit, etc. from userspace?  The only way I've ever seen anyone use
> the frame buffer device is by mmap()ing it and doing everything
> manually in the mapped memory.  I assume there must be ioctls for
> accessing the accelerated functions, but after several hours of
> grepping and googling, I give up. :-(

Did you try DirectFB ?

	Xav

Re: Accelerated frame buffer functions

[Haakon Riiser]

[Xavier Bestel]

> Le mercredi 02 février 2005 à 15:21 +0100, Haakon Riiser a
> écrit :

>> How can I use a frame buffer driver's optimized copyarea,
>> fillrect, blit, etc. from userspace?  The only way I've ever
>> seen anyone use the frame buffer device is by mmap()ing it
>> and doing everything manually in the mapped memory.  I assume
>> there must be ioctls for accessing the accelerated functions,
>> but after several hours of grepping and googling, I give up. :-(

> Did you try DirectFB ?

Thanks for the tip, I hadn't heard about it.  I will take a look,
but only to see if it can show me the user space API of /dev/fb.
I don't need a general library that supports a bunch of different
graphics cards.  I'm writing my own frame buffer driver for the
GX2 CPU, and I just want to know how to call the various functions
registered in struct fb_ops, so that I can test my code.  I mean,
all those functions registered in fb_ops must be accessible
somehow; if they weren't, what purpose would they serve?

-- 
 Haakon

Re: Accelerated frame buffer functions

[Gábor Lénárt]

On Wed, Feb 02, 2005 at 03:21:55PM +0100, Haakon Riiser wrote:
> > X-Windows already does this.
> 
> Yeah, I thought the X11 fbdev driver supported acceleration, but not
> according to its manpage:
> 
>   fbdev is an Xorg driver for framebuffer devices.  This is a
>   non-accelerated driver [...]

Yepp, it would be cool, to move every low level graphical operation to the
 framebuffer devices ... So no more 'I would like to use framebuffer
console _AND_ X at the same time without disturbing each other' problem,
and also if X segfaults or such, consolse will not remain in unusable state.
Also a solid low level graphical operation layer should provide even 3D
acceleration for fbdev capable (but not X!) apps and of course for the
X server ... without conflicting each other :) DirectFB seems to be a good
idea anyway ...

- Gábor

Re: Accelerated frame buffer functions

[Jon Smirl]

On Wed, 2 Feb 2005 16:41:39 +0100, Haakon Riiser
<haakon.riiser@fys.uio.no> wrote:
> Thanks for the tip, I hadn't heard about it.  I will take a look,
> but only to see if it can show me the user space API of /dev/fb.
> I don't need a general library that supports a bunch of different
> graphics cards.  I'm writing my own frame buffer driver for the
> GX2 CPU, and I just want to know how to call the various functions
> registered in struct fb_ops, so that I can test my code.  I mean,
> all those functions registered in fb_ops must be accessible
> somehow; if they weren't, what purpose would they serve?

You should look at writing a DRM driver. DRM implements the kernel
interface to get 3D hardware running. It is a fully accelerated driver
interface. They are located in drivers/char/drm

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Accelerated frame buffer functions

[Haakon Riiser]

[Jon Smirl]

> On Wed, 2 Feb 2005 16:41:39 +0100, Haakon Riiser
> <haakon.riiser@fys.uio.no> wrote:
>> Thanks for the tip, I hadn't heard about it.  I will take a look,
>> but only to see if it can show me the user space API of /dev/fb.
>> I don't need a general library that supports a bunch of different
>> graphics cards.  I'm writing my own frame buffer driver for the
>> GX2 CPU, and I just want to know how to call the various functions
>> registered in struct fb_ops, so that I can test my code.  I mean,
>> all those functions registered in fb_ops must be accessible
>> somehow; if they weren't, what purpose would they serve?
> 
> You should look at writing a DRM driver. DRM implements the kernel
> interface to get 3D hardware running. It is a fully accelerated driver
> interface. They are located in drivers/char/drm

Have the standard frame buffer drivers been abandoned, even
for devices that have no 3D acceleration (like the Geode GX2)?
I took a quick look at the DRM stuff, and it looked like extreme
overkill for what I need, if it even can be used for what I want
to do.  At first glance it looked like this is only relevant for
OpenGL/X11 3D-stuff, which I have absolutely no use for.

GX2 is an integrated CPU/graphics chip for embedded systems.
We have third party applications that use the framebuffer device,
and I was hoping to make things faster by writing an accelerated
driver.  The only thing I need answered is how to access fb_ops
from userspace.  If that is impossible because all the framebuffer
code is leftover junk that no one uses anymore, or even /can/
use anymore because the userspace interface is gone, please let
me know now so I don't have to waste any more time.

-- 
 Haakon

Re: Accelerated frame buffer functions

[James Simmons]

> > Le mercredi 02 février 2005 à 15:21 +0100, Haakon Riiser a
> > écrit :
> 
> >> How can I use a frame buffer driver's optimized copyarea,
> >> fillrect, blit, etc. from userspace?  The only way I've ever
> >> seen anyone use the frame buffer device is by mmap()ing it
> >> and doing everything manually in the mapped memory.  I assume
> >> there must be ioctls for accessing the accelerated functions,
> >> but after several hours of grepping and googling, I give up. :-(
> 
> > Did you try DirectFB ?
> 
> Thanks for the tip, I hadn't heard about it.  I will take a look,
> but only to see if it can show me the user space API of /dev/fb.
> I don't need a general library that supports a bunch of different
> graphics cards.  I'm writing my own frame buffer driver for the
> GX2 CPU, and I just want to know how to call the various functions
> registered in struct fb_ops, so that I can test my code.  I mean,
> all those functions registered in fb_ops must be accessible
> somehow; if they weren't, what purpose would they serve?

The reason for the accelerated functions is for the framebuffer console.
Drawing pixel by pixel is to slow.

Re: Accelerated frame buffer functions

[James Simmons]

> > You should look at writing a DRM driver. DRM implements the kernel
> > interface to get 3D hardware running. It is a fully accelerated driver
> > interface. They are located in drivers/char/drm
> 
> Have the standard frame buffer drivers been abandoned, even
> for devices that have no 3D acceleration (like the Geode GX2)?

No. It is still around. 

> I took a quick look at the DRM stuff, and it looked like extreme
> overkill for what I need, if it even can be used for what I want
> to do.  At first glance it looked like this is only relevant for
> OpenGL/X11 3D-stuff, which I have absolutely no use for.

This is usually the case for embedded chips. This is the reason the fbdev 
userland interface is still around.

> GX2 is an integrated CPU/graphics chip for embedded systems.
> We have third party applications that use the framebuffer device,
> and I was hoping to make things faster by writing an accelerated
> driver.  The only thing I need answered is how to access fb_ops
> from userspace.  

You can mmap the mmio address space and program the registers yourself.
A bonus is the example code is in the driver :-) 

> If that is impossible because all the framebuffer
> code is leftover junk that no one uses anymore, or even /can/
> use anymore because the userspace interface is gone, please let
> me know now so I don't have to waste any more time.

The userspace interface is still there.

Re: Accelerated frame buffer functions

[Geert Uytterhoeven]

On Wed, 2 Feb 2005, Haakon Riiser wrote:
> > On Wed, 2 Feb 2005 16:41:39 +0100, Haakon Riiser
> > <haakon.riiser@fys.uio.no> wrote:
> >> Thanks for the tip, I hadn't heard about it.  I will take a look,
> >> but only to see if it can show me the user space API of /dev/fb.
> >> I don't need a general library that supports a bunch of different
> >> graphics cards.  I'm writing my own frame buffer driver for the
> >> GX2 CPU, and I just want to know how to call the various functions
> >> registered in struct fb_ops, so that I can test my code.  I mean,
> >> all those functions registered in fb_ops must be accessible
> >> somehow; if they weren't, what purpose would they serve?
> > 
> > You should look at writing a DRM driver. DRM implements the kernel
> > interface to get 3D hardware running. It is a fully accelerated driver
> > interface. They are located in drivers/char/drm
> 
> Have the standard frame buffer drivers been abandoned, even
> for devices that have no 3D acceleration (like the Geode GX2)?

No.

> GX2 is an integrated CPU/graphics chip for embedded systems.
> We have third party applications that use the framebuffer device,
> and I was hoping to make things faster by writing an accelerated
> driver.  The only thing I need answered is how to access fb_ops
> from userspace.  If that is impossible because all the framebuffer
> code is leftover junk that no one uses anymore, or even /can/
> use anymore because the userspace interface is gone, please let
> me know now so I don't have to waste any more time.

mmap() the MMIO registers to userspace, and program the acceleration engine
from userspace, like DirectFB (and XF*_FBDev 3.x for Matrox and Mach64) does.

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

Re: Accelerated frame buffer functions

[Haakon Riiser]

[Geert Uytterhoeven]

> mmap() the MMIO registers to userspace, and program the
> acceleration engine from userspace, like DirectFB (and XF*_FBDev
> 3.x for Matrox and Mach64) does.

Right, this was how I originally intended to do it.  The reason
why I started to obsess about the accelerated fb_ops functions was
that I hoped that, by creating a driver that registered accelerated
versions of these functions, other frame buffer-using applications
would instantly take advantage of it, requiring no changes in those
applications.  I thought the frame buffer device was supposed to
serve as an an abstraction layer between the graphics card and
the application, allowing for 2D acceleration without having to
know anything about the underlying hardware.  But if no one uses the
frame buffer device in this way, I might as well do as you suggest
and mmap() the registers to userspace.

Anyway, thanks to everyone who participated in this thread.  Even if
I didn't get the answers I was hoping for, at least now I can put the
matter to rest.

-- 
 Haakon

Re: Accelerated frame buffer functions

[Helge Hafting]

Haakon Riiser wrote:

>[Geert Uytterhoeven]
>
>  
>
>>mmap() the MMIO registers to userspace, and program the
>>acceleration engine from userspace, like DirectFB (and XF*_FBDev
>>3.x for Matrox and Mach64) does.
>>    
>>
>
>Right, this was how I originally intended to do it.  The reason
>why I started to obsess about the accelerated fb_ops functions was
>that I hoped that, by creating a driver that registered accelerated
>versions of these functions, other frame buffer-using applications
>would instantly take advantage of it, requiring no changes in those
>applications.  
>
The only framebuffer interface I know of is the framebuffer console.
It uses the fbdev acceleration when writing character strings
and scrolling.  So if your app writes data on the console and/or
scroll regions, then it certainly uses framebuffer acceleration.

>I thought the frame buffer device was supposed to
>serve as an an abstraction layer between the graphics card and
>the application, allowing for 2D acceleration without having to
>know anything about the underlying hardware.  But if no one uses the
>frame buffer device in this way, I might as well do as you suggest
>and mmap() the registers to userspace.
>  
>
I believe you also can write a small driver that connects to the
framebuffer the same way the fbconsole does.  It could then
export all the operations so userspace actually can call them.  This
have the advantage that your app can work on more than just one kind of
framebuffer.  Perhaps you run on one kind of hardware only today,
but who knows what hardware the future will bring?  Nice not having
to rewrite it all. . .

Helge Hafting