framebuffer ioctl (fwd)

framebuffer ioctl (fwd)

[Geert Uytterhoeven]

---------- Forwarded message ----------
Date: Fri, 03 Sep 2004 16:37:16 -0700
From: Zack <plinius@comcast.net>
To: geert@linux-m68k.org, jsimmons@infradead.org
Subject: framebuffer ioctl

Hello,
Would there be any major opposition to my adding
some additional functions to the framebuffer ioctl
interface? I want to add basic drawing functions,
nothing too fancy, but enough to do away with things
like SVGAlib.
Zack


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: framebuffer ioctl (fwd)

[Otto Wyss]

Geert Uytterhoeven wrote:
> 
> Would there be any major opposition to my adding
> some additional functions to the framebuffer ioctl
> interface? I want to add basic drawing functions,
> nothing too fancy, but enough to do away with things
> like SVGAlib.
> Zack
> 
IMO it should only be done if all of the graphic libs like SVGAlib, GGI,
DirectFB can profit from it. IMO it's very important that the future API
of the framebuffer in kernel 2.7.x is discussed before such changes are
done. Maybe a wish list should be started.

O. Wyss

-- 
See a huge pile of work at "http://wyodesktop.sourceforge.net/"


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: framebuffer ioctl

[Zack]

Otto Wyss wrote:

>Geert Uytterhoeven wrote:
>  
>
>>Would there be any major opposition to my adding
>>some additional functions to the framebuffer ioctl
>>interface? I want to add basic drawing functions,
>>nothing too fancy, but enough to do away with things
>>like SVGAlib.
>>Zack
>>    
>>
>IMO it should only be done if all of the graphic libs like SVGAlib, GGI,
>DirectFB can profit from it. IMO it's very important that the future API
>of the framebuffer in kernel 2.7.x is discussed before such changes are
>done. Maybe a wish list should be started.
>
>O. Wyss
>  
>
Some reasons for moving drawing routines into the kernel include
(correct me if I'm wrong)

1. there is some needless duplication of effort between these
various fullscreen-gui projects (svgalib, ggi, etc)
2. there is afaik presently no good facility for adding acceleration
support for things like drawing lines
3. the chance that any fullscreen-gui project will become broken
due to a new kernel is real (SVGAlib is broken with 2.4.26 & 2.6.7)
4. new features would be optional anyway: fullscreen-guis need not
recognize their existence, but would benefit from doing so
since some fb drivers would override the generic routines
to implement accelerated routines.

Zack




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: framebuffer ioctl

[Antonino A. Daplas]

On Monday 06 September 2004 01:13, Zack wrote:
> 4. new features would be optional anyway: fullscreen-guis need not
> recognize their existence, but would benefit from doing so
> since some fb drivers would override the generic routines
> to implement accelerated routines.
>

One of the limitations of the in-kernel drawing routines is that they were 
never designed to be used in user space.  This has been discussed a long time 
ago so that the upper layer need not know the characteristics of the 
low-level driver. 

Possibly, the only drawing function that can be used by userspace is copyarea 
(bitblt).  Fillrect (color fill) and imageblit (color expand) cannot be used 
since they rely on pseudo_palette which is limited to 16 colors.

I believe that the kernel framebuffer should only support features that cannot 
be done in user space, such as interrupt handling.  I really recommend to 
concentrate on one library (I recommend DirectFB) and enhance that.

Note that the framebuffer ABI is quite consistent since its inception. So you 
can rely on libraries based on fbdev, ie DirectFB, even X, to consistently 
work with whatever version of the kernel.

Tony
  




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: framebuffer ioctl

[Otto Wyss]

"Antonino A. Daplas" wrote:
> 
> On Monday 06 September 2004 01:13, Zack wrote:
> > 4. new features would be optional anyway: fullscreen-guis need not
> > recognize their existence, but would benefit from doing so
> > since some fb drivers would override the generic routines
> > to implement accelerated routines.
> >
> 
> One of the limitations of the in-kernel drawing routines is that they were
> never designed to be used in user space.  This has been discussed a long time
> ago so that the upper layer need not know the characteristics of the
> low-level driver.
> 
I'm neither pro nor contra moving drawing routines into the kernel but
this has to be discussed and written down.

The question is not if its kernel or user space but what functionality
has to be provided by a graphic driver. I don't care if it's a
monolithic solution or if it's divided into user and kernel part but
it's necessary that this is now nailed down so anyone can use this API
and work on a common goal. Also it makes it easier to code drivers when
everything is collected into on place.

O. Wyss

-- 
See a huge pile of work at "http://wyodesktop.sourceforge.net/"


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: framebuffer ioctl

[Otto Solares]

On Sun, Sep 05, 2004 at 10:13:09AM -0700, Zack wrote:
> Some reasons for moving drawing routines into the kernel include
> (correct me if I'm wrong)

Does 'moving drawing routines into the kernel' means 'exporting
to user-space drawing (possibly accelerated)' routines?

> 1. there is some needless duplication of effort between these
> various fullscreen-gui projects (svgalib, ggi, etc)
> 2. there is afaik presently no good facility for adding acceleration
> support for things like drawing lines
> 3. the chance that any fullscreen-gui project will become broken
> due to a new kernel is real (SVGAlib is broken with 2.4.26 & 2.6.7)
> 4. new features would be optional anyway: fullscreen-guis need not
> recognize their existence, but would benefit from doing so
> since some fb drivers would override the generic routines
> to implement accelerated routines.

These are good reasons for a single user-space library, not kernel
bloat.

The only consumer of drawing routines in the kernel is fbcon,
and acceleration should not go into the kernel, user-space libs do
a better and safer job here.

The only --true-- reason drawing routines should go into the kernel
is hw w/o a user-space accesible fb (maybe true for some rare and
for some next-gen cards).

-otto


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: framebuffer ioctl

[Jon Smirl]

On Mon, 6 Sep 2004 12:43:06 -0600, Otto Solares <solca@guug.org> wrote:

Teach him about mesa-solo and he won't want to extend fbdev.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: framebuffer ioctl

[Otto Solares]

On Mon, Sep 06, 2004 at 03:08:40PM -0400, Jon Smirl wrote:
> On Mon, 6 Sep 2004 12:43:06 -0600, Otto Solares <solca@guug.org> wrote:
> 
> Teach him about mesa-solo and he won't want to extend fbdev.

What about the new graphics interface that will unify
fbdev/drm you talk about in kernel summit?

-otto


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: framebuffer ioctl

[Jon Smirl]

It is still being worked on. The have been a lot of changes to DRM
recently. The PCI ROM patch is finished and waiting to go into the
kernel. I'm starting on the VGA driver next. Jess@sgi is working on
the user space reset app.

After all that is done we can start on printk support.


On Mon, 6 Sep 2004 13:24:00 -0600, Otto Solares <solca@guug.org> wrote:
> On Mon, Sep 06, 2004 at 03:08:40PM -0400, Jon Smirl wrote:
> > On Mon, 6 Sep 2004 12:43:06 -0600, Otto Solares <solca@guug.org> wrote:
> >
> > Teach him about mesa-solo and he won't want to extend fbdev.
> 
> What about the new graphics interface that will unify
> fbdev/drm you talk about in kernel summit?
> 
> 
> 
> -otto
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
> 



-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: framebuffer ioctl

[Jon Smirl]

mesa-solo works just fine from user space. It's the in kernel support
and mode setting that is missing.


On Mon, 6 Sep 2004 13:24:00 -0600, Otto Solares <solca@guug.org> wrote:
> On Mon, Sep 06, 2004 at 03:08:40PM -0400, Jon Smirl wrote:
> > On Mon, 6 Sep 2004 12:43:06 -0600, Otto Solares <solca@guug.org> wrote:
> >
> > Teach him about mesa-solo and he won't want to extend fbdev.
> 
> What about the new graphics interface that will unify
> fbdev/drm you talk about in kernel summit?
> 
> 
> 
> -otto
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
> 



-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: framebuffer ioctl

[Zack]

Antonino A. Daplas wrote:

>On Monday 06 September 2004 01:13, Zack wrote:
>  
>
>>4. new features would be optional anyway: fullscreen-guis need not
>>recognize their existence, but would benefit from doing so
>>since some fb drivers would override the generic routines
>>to implement accelerated routines.
>>
>One of the limitations of the in-kernel drawing routines is that they were 
>never designed to be used in user space.  This has been discussed a long time 
>ago so that the upper layer need not know the characteristics of the 
>low-level driver. 
>
>Possibly, the only drawing function that can be used by userspace is copyarea 
>(bitblt).  Fillrect (color fill) and imageblit (color expand) cannot be used 
>since they rely on pseudo_palette which is limited to 16 colors.
>
>I believe that the kernel framebuffer should only support features that cannot 
>be done in user space, such as interrupt handling.  I really recommend to 
>concentrate on one library (I recommend DirectFB) and enhance that.
>
>Note that the framebuffer ABI is quite consistent since its inception. So you 
>can rely on libraries based on fbdev, ie DirectFB, even X, to consistently 
>work with whatever version of the kernel.
>
>Tony
>
I think you may be misinterpreting my intent. I am strictly anti-bloat,
so I don't want a larger kernel. By the same token, I don't use
X because it is bloated--X uses 16 megs minimum on my system,
and that is very much not to my taste.

Directfb seems geared toward being overly impressive,
which says to me that if it's not bloated already, it will be later.

My new routines are small.

>I believe that the kernel framebuffer should only support features that cannot 
>be done in user space, such as interrupt handling.  I really recommend to 
>concentrate on one library (I recommend DirectFB) and enhance that.


For other people reading this, the idea of putting everything into
userspace that can be put there is called an "exokernel" approach.
It's a matter of taste. To me it's just another way bloat is achieved.

Zack



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: framebuffer ioctl

[Jon Smirl]

On Mon, 06 Sep 2004 12:56:26 -0700, Zack <plinius@comcast.net> wrote:
> I think you may be misinterpreting my intent. I am strictly anti-bloat,
> so I don't want a larger kernel. By the same token, I don't use
> X because it is bloated--X uses 16 megs minimum on my system,
> and that is very much not to my taste.

Mesa-solo is not X it is the OpenGL layer. mesa-solo runs standalone
without needing X. Using mesa-solo will give you access the full
acceleration capabilities of many chip families - i810, i830, i915,
radeon, r128, mga, sis, ffb, tdfx.  Nvidia is not supported because
the hardware documentation is secret. There is also a mode for
building an embedded version of mesa-solo which removes about 50% of
the OpenGL functions and makes it smaller if that is really a problem.

Check out the Cairo benchmarks. The OpenGL drivers can beat the
performance of 2D drivers 100:1 and some cases 400:1. OpenGL uses the
GPU to do the drawing instead of the main CPU.

Writing fully accelerated drivers is very complicated and it takes
years of work.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: [OT] framebuffer ioctl

[Otto Solares]

On Mon, Sep 06, 2004 at 05:02:20PM -0400, Jon Smirl wrote:
> Check out the Cairo benchmarks. The OpenGL drivers can beat the
> performance of 2D drivers 100:1 and some cases 400:1. OpenGL uses the
> GPU to do the drawing instead of the main CPU.

Does cairo have been ported to mesa-solo?

-otto


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: framebuffer ioctl

[Antonino A. Daplas]

On Monday 06 September 2004 23:36, Otto Wyss wrote:
> I'm neither pro nor contra moving drawing routines into the kernel but
> this has to be discussed and written down.

On Tuesday 07 September 2004 03:56, Zack wrote:
> I think you may be misinterpreting my intent. I am strictly anti-bloat,
> so I don't want a larger kernel. By the same token, I don't use
> X because it is bloated--X uses 16 megs minimum on my system,
> and that is very much not to my taste.

This is not about pros/cons, but a statement of fact. What I meant was that 
the drawing routines that we actually have (imageblit, copyarea, fillrect) 
cannot be used in userspace.  So, if fbdev is going to support drawing 
routines for userspace, then fbdev will need 2 versions of each of the 
drawing function.  That is a waste of good code.  

This decision has been set quite early during 2.5 development.  At that 
period, I wrote a version of imageblit, copyarea and fillrect that can be 
accessed in userspace via ioctl.  With that, I also provided a patch for the 
XFree86 fbdev driver that takes advantage of these ioctl's resulting to 
certain x11perf benchmarks that are faster than X+native driver.  See:

http://marc.theaimsgroup.com/?l=linux-fbdev-devel&m=102278557515976&w=2

Of course, the above is quite difficult to accomplish now.

Tony




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: framebuffer ioctl

[Michel Dänzer]

On Mon, 2004-09-06 at 17:02 -0400, Jon Smirl wrote:
> 
> Check out the Cairo benchmarks. The OpenGL drivers can beat the
> performance of 2D drivers 100:1 and some cases 400:1. OpenGL uses the
> GPU to do the drawing instead of the main CPU.

Please stop reiterating these bogus (optimized OpenGL vs. unoptimized
software-rendered Render extension) numbers, unless you think bogus
numbers are a good way to make a point.


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click

Re: [OT] framebuffer ioctl

[Jon Smirl]

Someone has already ported it, but I forget who it was. mesa-solo is
not quite ready for prime time yet because it does have mode setting
support. Ask on the cairo list about the port. It was simple to do, it
only took a day or so.


On Mon, 6 Sep 2004 15:11:20 -0600, Otto Solares <solca@guug.org> wrote:
> On Mon, Sep 06, 2004 at 05:02:20PM -0400, Jon Smirl wrote:
> > Check out the Cairo benchmarks. The OpenGL drivers can beat the
> > performance of 2D drivers 100:1 and some cases 400:1. OpenGL uses the
> > GPU to do the drawing instead of the main CPU.
> 
> Does cairo have been ported to mesa-solo?
> 
> -otto
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
> 



-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: framebuffer ioctl

[Zack]

Antonino A. Daplas wrote:

>So, if fbdev is going to support drawing 
>routines for userspace, then fbdev will need 2 versions of each of the 
>drawing function.  That is a waste of good code.  

Looking at drivers/video/cfbfillrect.c it says in the comments that 24bpp mode
is "broken". Perhaps the routine is fast for 8/16/32bpp but for now,
I'd rather rely on my own routine which supports 24bpp since I mainly use that.
Zack




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: framebuffer ioctl

[Antonino A. Daplas]

On Tuesday 07 September 2004 05:58, Zack wrote:
> Antonino A. Daplas wrote:
> >So, if fbdev is going to support drawing
> >routines for userspace, then fbdev will need 2 versions of each of the
> >drawing function.  That is a waste of good code.
>
> Looking at drivers/video/cfbfillrect.c it says in the comments that 24bpp
> mode is "broken". Perhaps the routine is fast for 8/16/32bpp but for now,

That comment is old, 24 bpp is not broken.  It's not the fastest code, but not 
the slowest either.

> I'd rather rely on my own routine which supports 24bpp since I mainly use
> that. Zack
>

And you can (see drivers with their own xxxfb_* routines).  The only thing is 
that you cannot use it in userland.  

Tony




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: [OT] framebuffer ioctl

[Otto Solares]

On Mon, Sep 06, 2004 at 05:39:54PM -0400, Jon Smirl wrote:
> Someone has already ported it, but I forget who it was. mesa-solo is
> not quite ready for prime time yet because it does have mode setting
> support. Ask on the cairo list about the port. It was simple to do, it
> only took a day or so.

As I see it, mode-setting is a job for fbdev and it's current API,
or a new one is being developed for mesa-solo?

-otto


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: [OT] framebuffer ioctl

[Jon Smirl]

Alan Cox has proposed a new unified mode setting mode that uses
hotplug. There are four ways to set modes: user space, vm86/real mode,
in kernel, mix of these. The new scheme supports mode setting for
hardware of these different types. fbdev is all in kernel.

On Mon, 6 Sep 2004 18:01:03 -0600, Otto Solares <solca@guug.org> wrote:
> On Mon, Sep 06, 2004 at 05:39:54PM -0400, Jon Smirl wrote:
> > Someone has already ported it, but I forget who it was. mesa-solo is
> > not quite ready for prime time yet because it does have mode setting
> > support. Ask on the cairo list about the port. It was simple to do, it
> > only took a day or so.
> 
> As I see it, mode-setting is a job for fbdev and it's current API,
> or a new one is being developed for mesa-solo?
> 
> 
> 
> -otto
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
> 



-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: framebuffer ioctl

[Jon Smirl]

The numbers compare two peices of software that exist.  Sure you could
probably write a super optimized library for CPU based drawing in 2D
mode that would be faster, but this library doesn't exist. No matter
what you do using the GPU to draw is always going to beat using the
CPU by a wide margin because of the memory bandwidth difference.

Would Cairo on hardware OpenGL vs Cairo on software only OpenGL be a
better comparison? Those ratios are even worse.

Why does everyone want to write another accelerated drawing library
when we already have a really good one that follows standards and has
excellent documentaition? Why not help integrate DRM and fbdev
instead.


On Mon, 06 Sep 2004 17:24:20 -0400, Michel Dänzer <michel@daenzer.net> wrote:
> On Mon, 2004-09-06 at 17:02 -0400, Jon Smirl wrote:
> >
> > Check out the Cairo benchmarks. The OpenGL drivers can beat the
> > performance of 2D drivers 100:1 and some cases 400:1. OpenGL uses the
> > GPU to do the drawing instead of the main CPU.
> 
> Please stop reiterating these bogus (optimized OpenGL vs. unoptimized
> software-rendered Render extension) numbers, unless you think bogus
> numbers are a good way to make a point.
> 
> --
> Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
> Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_idP47&alloc_id\x10808&opclick
> 
> 
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
> 



-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click

Re: framebuffer ioctl

[Geert Uytterhoeven]

On Tue, 7 Sep 2004, Jon Smirl wrote:
> The numbers compare two peices of software that exist.  Sure you could
> probably write a super optimized library for CPU based drawing in 2D
> mode that would be faster, but this library doesn't exist. No matter
> what you do using the GPU to draw is always going to beat using the
> CPU by a wide margin because of the memory bandwidth difference.
>
> Would Cairo on hardware OpenGL vs Cairo on software only OpenGL be a
> better comparison? Those ratios are even worse.

I think (but I'm not sure) Michel wants you to compare Cairo on OpenGL vs.
traditional 2D accelerated X.

I.e. while X on top of hardware accelerated OpenGL is _much_ faster than X on
top of software OpenGL, what we really care about is whether it's much faster
than traditional 2D accelerated X.

> Why does everyone want to write another accelerated drawing library
> when we already have a really good one that follows standards and has
> excellent documentaition? Why not help integrate DRM and fbdev
> instead.
>
> On Mon, 06 Sep 2004 17:24:20 -0400, Michel Dänzer <michel@daenzer.net> wrote:
> > On Mon, 2004-09-06 at 17:02 -0400, Jon Smirl wrote:
> > >
> > > Check out the Cairo benchmarks. The OpenGL drivers can beat the
> > > performance of 2D drivers 100:1 and some cases 400:1. OpenGL uses the
> > > GPU to do the drawing instead of the main CPU.
> >
> > Please stop reiterating these bogus (optimized OpenGL vs. unoptimized
> > software-rendered Render extension) numbers, unless you think bogus
> > numbers are a good way to make a point.

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 BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click

Re: framebuffer ioctl

[Jon Smirl]

On Tue, 7 Sep 2004 16:26:47 +0200 (MEST), Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Tue, 7 Sep 2004, Jon Smirl wrote:
> > The numbers compare two peices of software that exist.  Sure you could
> > probably write a super optimized library for CPU based drawing in 2D
> > mode that would be faster, but this library doesn't exist. No matter
> > what you do using the GPU to draw is always going to beat using the
> > CPU by a wide margin because of the memory bandwidth difference.
> >
> > Would Cairo on hardware OpenGL vs Cairo on software only OpenGL be a
> > better comparison? Those ratios are even worse.
> 
> I think (but I'm not sure) Michel wants you to compare Cairo on OpenGL vs.
> traditional 2D accelerated X.

That's what the numbers compare. I think he wants me to compare it to
his new render implementation that uses the 3D hardware.  But that's
what I'm against. I don't want to see even more drivers trying to take
control of the 3D hardware and causing even more conflicts.
Implementing X on GL completely removes the need for expanding XAA to
include using the 3D hardware. This pratice of ten different groups
programming the video hardware however they want has got to stop or
Linux is never going to be competitive with Mac/Longhorn.

> 
> I.e. while X on top of hardware accelerated OpenGL is _much_ faster than X on
> top of software OpenGL, what we really care about is whether it's much faster
> than traditional 2D accelerated X.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: framebuffer ioctl

[Jon Smirl]

Here's the paper on Glitz = Cairo on OpenGL

http://www.cs.umu.se/~c99drn/opengl_freenix04.pdf

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: framebuffer ioctl

[Otto Wyss]

Jon Smirl wrote:
> 
> > > Teach him about mesa-solo and he won't want to extend fbdev.
> >
I coudln't find much useful information about mesa-solo, is it the same
as miniglx? Is there any link?

> > What about the new graphics interface that will unify
> > fbdev/drm you talk about in kernel summit?
> >
Is there anyone who could write a resumée what's talked and decided
about framebuffer at the summit? Just send it to me (i.e. plain text)
and I'll put it onto the web in the document section.

> > -otto
Hi Otto, is that me or is that you ;-)

O. Wyss

-- 
See a huge pile of work at "http://wyodesktop.sourceforge.net/"


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: framebuffer ioctl

[Michel Dänzer]

On Tue, 2004-09-07 at 10:17 -0400, Jon Smirl wrote:
> The numbers compare two peices of software that exist.  Sure you could
> probably write a super optimized library for CPU based drawing in 2D
> mode that would be faster, but this library doesn't exist. No matter
> what you do using the GPU to draw is always going to beat using the
> CPU by a wide margin because of the memory bandwidth difference.
> 
> Would Cairo on hardware OpenGL vs Cairo on software only OpenGL be a
> better comparison? Those ratios are even worse.

Examples of fair comparisons would be:

Software rendered OpenGL vs. software rendered Render extension
Hardware-accelerated OpenGL vs. hardware-accelerated Render extension
...

> Why does everyone want to write another accelerated drawing library
> when we already have a really good one that follows standards and has
> excellent documentaition? Why not help integrate DRM and fbdev
> instead.

All I'm saying is that it reflects badly on you if you need to resort to
skewed numbers.


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click

Re: framebuffer ioctl

[Otto Wyss]

Jon Smirl wrote:
> 
> That's what the numbers compare. I think he wants me to compare it to
> his new render implementation that uses the 3D hardware.  But that's
> what I'm against. I don't want to see even more drivers trying to take
> control of the 3D hardware and causing even more conflicts.
> Implementing X on GL completely removes the need for expanding XAA to
> include using the 3D hardware. This pratice of ten different groups
> programming the video hardware however they want has got to stop or
> Linux is never going to be competitive with Mac/Longhorn.
> 
What me concern here is there is a little too much talk about X.
Enhancing the framebuffer has nothing to do with X, it has to do with
providing a common set of functionality for _all_ the graphic libraries
however many there are and X is _just_ one of them.

Please correct me if I miss understood your intention.

O. Wyss

-- 
See a huge pile of work at "http://wyodesktop.sourceforge.net/"


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: framebuffer ioctl

[Jon Smirl]

mesa-solo is under the "fbdev/DRI Environment" link at mesa3d.sf.net.
miniglx is a small glx layer that runs on top of mesa-solo.

Summary of the OLS discussions:
http://lkml.org/lkml/2004/8/2/111

Here is the mode setting proposal, it's somewhere in the fbdev
archives but I can't find it

At OLS we talked about a system like this:
1) user owns graphics devices
2) user sets mode with string (or similar) format using ioctl common to
all drivers.
3) driver is locked to prevent multiple mode sets
4) common code takes this string and does a hotplug event with it.
5) hotplug event runs root context in user space 
6) mode is decoded and verified, this may involve a little process that
maintains the DDC database and reads a file of legal modes. Other
schemes are possible.
7a) mode is set using VBIOS and vm86, signal driver mode is set
7b) the register values needed to set the mode are passed into a root
priv ioctl.
8) driver is unlocked.

In this model all of the verification happens in user space. If you
want to set modes other than the ones from DDC you have to add them to
the config file. There is no need for DDC support and mode verification
in the kernel.

To give credit this is Alan Cox's design.


On Tue, 07 Sep 2004 17:48:13 +0200, Otto Wyss <otto.wyss@orpatec.ch> wrote:
> Jon Smirl wrote:
> >
> > > > Teach him about mesa-solo and he won't want to extend fbdev.
> > >
> I coudln't find much useful information about mesa-solo, is it the same
> as miniglx? Is there any link?
> 
> > > What about the new graphics interface that will unify
> > > fbdev/drm you talk about in kernel summit?
> > >
> Is there anyone who could write a resumée what's talked and decided
> about framebuffer at the summit? Just send it to me (i.e. plain text)
> and I'll put it onto the web in the document section.
> 
> > > -otto
> Hi Otto, is that me or is that you ;-)
> 
> 
> 
> O. Wyss
> 
> --
> See a huge pile of work at "http://wyodesktop.sourceforge.net/"
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
> 



-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click

Re: framebuffer ioctl

[Otto Solares]

On Tue, Sep 07, 2004 at 05:48:13PM +0200, Otto Wyss wrote:
> Jon Smirl wrote:
> > 
> > > > Teach him about mesa-solo and he won't want to extend fbdev.
> > >
> I coudln't find much useful information about mesa-solo, is it the same
> as miniglx? Is there any link?

In reality is not hard to program for mesa-solo, just the init code
is the trickiest part as you must initialize the fbdev and *magically*
find a working video mode (which is always hard regardless you are
using mesa-solo).  Anything else is pure OpenGL.  If you need the init
code I have a working one but I don't use miniglx but driUtil routines.

> > > -otto
> Hi Otto, is that me or is that you ;-)

Probably you but sounds like me :)

-otto


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: framebuffer ioctl

[Jon Smirl]

On Tue, 07 Sep 2004 11:52:00 -0400, Michel Dänzer <michel@daenzer.net> wrote:
> All I'm saying is that it reflects badly on you if you need to resort to
> skewed numbers.

I don't think they are skewed. Most desktops today have hardware
OpenGL and software Render. The ratios are an accurate reflection of
what a normal user would see when comparing Cairo on X vs Cairo on
OpenGL. You may try to change the platform in the future but hardware
Render is not deployed anywhere currently.

Even KeithP says he would rather be on OpenGL than to continue
accelerating Render functions and he designed Render. The argument is
not about the technical merits of Render vs OpenGL, it's about the
fact that OpenGL is a widely available standard that is well
documented. Thousands of people can program to the OpenGL APL while
only very few know about Render. Let's stand on the shoulders of other
programmers (you're one of them since you helped with mesa) rather
than build everything again.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click

Re: framebuffer ioctl

[Ville Syrjälä]

On Wed, Sep 08, 2004 at 01:43:42AM -0400, Jon Smirl wrote:
> On Tue, 07 Sep 2004 11:52:00 -0400, Michel Dänzer <michel@daenzer.net> wrote:
> > All I'm saying is that it reflects badly on you if you need to resort to
> > skewed numbers.
> 
> I don't think they are skewed. Most desktops today have hardware
> OpenGL and software Render. The ratios are an accurate reflection of
> what a normal user would see when comparing Cairo on X vs Cairo on
> OpenGL. You may try to change the platform in the future but hardware
> Render is not deployed anywhere currently.

AFAIK neither is Cairo.

If I had too much time on my hands I might port glitz to DirectFB so you 
could quote some more meaningful benchmarks ;)

> Even KeithP says he would rather be on OpenGL than to continue
> accelerating Render functions and he designed Render. The argument is
> not about the technical merits of Render vs OpenGL, it's about the
> fact that OpenGL is a widely available standard that is well
> documented. Thousands of people can program to the OpenGL APL while
> only very few know about Render. Let's stand on the shoulders of other
> programmers (you're one of them since you helped with mesa) rather
> than build everything again.

No one is preventing you from doing that. But other people have other 
priorities and you constantly ignoring that fact doesn't help matters. You 
can dream of world domination all you want but in the world of open source 
people tend to do what they find interesting.

I welcome you work on the drm since it appears to reduce the amount of 
unnecessary user space init code. When the drm gets easier to use other 
projects may adopt it.

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


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click

Re: framebuffer ioctl

[Jon Smirl]

On Wed, 8 Sep 2004 16:59:35 +0300, Ville Syrjälä <syrjala@sci.fi> wrote:
> I welcome you work on the drm since it appears to reduce the amount of
> unnecessary user space init code. When the drm gets easier to use other
> projects may adopt it.

Direct use of DRM will satisfy the goal of keeping all of the drivers
from stomping on each other. I would encourage you to consider using
mesa but there is no requirement to do so. There is a 300KB open
source OpenGL-ES implementation that could be ported to DRM if the
size of mesa is a problem.

I would encourage people with the skills to write video drivers to
come help with DRM instead of creating more conflicting drivers. A
short term goal for DRM is to integrate enough of fbdev in order to be
able to draw the console from kernel space. We also need help
implementing Alan's universal mode setting API since it doesn't exist
yet in any driver.

Most of the conflicts between DRM don't occur from base functionality
in fbdev and DRM, they originate in the chip specific drivers. It's
the chip specific drivers that need to be merged.

Merging DRM into fbdev instead of fbdev into DRM was also considered,
but the complexity of the DRM video memory manager made that too hard.
On the other hand, if I had known what I know now about how many
political problems merging fbdev into DRM was going to cause I would
have just rewritten the DRM memory manager for fbdev and done the
merge the other way. End result would be the same either way.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click

vga softboot code repository

[Richard Smith]

Jon,

Reciently theres been a lot of talk on the LinuxBIOS list on the 
softbooting of vga cards and all the various forks there are of the 
x86emu code.  X, LinuxBIOS, DRI and probally a few others.  What works 
with what card, etc.

Its Egbert Eich's wish that we try to unify these things into a 
libsoftboot that all projects could use.  That way fixes and improvments 
will be shared by all rather than just each specific project.

A GNU Arch repository is being created on openbios.org to host 
developement.

You seem the be the man for the DRI x86emu.  Interested in trying to 
merge your stuff into the project?  I know that your ROM map and  setup 
stuff is quite different than X or LB but you still use basically the 
same core right?




-------------------------------------------------------
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: vga softboot code repository oops

[Richard Smith]

Richard Smith wrote:

> Jon,
> 
> Reciently theres been a lot of talk on the LinuxBIOS list on the 
> softbooting of vga cards and all the various forks there are of the 

Oops sorry about that.  I negelected to notice that the reply to is to 
the list rather than to the individual.

Of course the offer extendeds to anyone in x86emu stuff and not just Jon.




-------------------------------------------------------
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: vga softboot code repository

[Jon Smirl]

There is a big thread on lkml right now called radeon-pre-2. Alan Cox
is going to redesign the base fbdev and DRI layers.  This includes the
DOSEMU part for reset. I'd attach your issues to the end of that
thread so that Alan can see them.

This is the root of the thread
http://lkml.org/lkml/2004/9/10/206
There are about 100 messages in it. The part about the VGA driver is
at the very end.


On Mon, 13 Sep 2004 10:54:56 -0500, Richard Smith <rsmith@bitworks.com> wrote:
> Jon,
> 
> Reciently theres been a lot of talk on the LinuxBIOS list on the
> softbooting of vga cards and all the various forks there are of the
> x86emu code.  X, LinuxBIOS, DRI and probally a few others.  What works
> with what card, etc.
> 
> Its Egbert Eich's wish that we try to unify these things into a
> libsoftboot that all projects could use.  That way fixes and improvments
> will be shared by all rather than just each specific project.
> 
> A GNU Arch repository is being created on openbios.org to host
> developement.
> 
> You seem the be the man for the DRI x86emu.  Interested in trying to
> merge your stuff into the project?  I know that your ROM map and  setup
> stuff is quite different than X or LB but you still use basically the
> same core right?
> 
> -------------------------------------------------------
> 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
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
> 



-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
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