On Gwe, 2004-05-14 at 19:40, Jon Smirl wrote:
> Does DirectFB work on anything beside Matrox now?
Most cards, accelerated on quite a few including VIA. This is getting
into detail. If your 3D sucks you dont us OpenGL as the basis of your
whizzo console driver - just as MS plan to support the older
On Fri, May 14, 2004 at 10:51:35AM -0700, Jon Smirl wrote:
> Just look at this picture and you can see the trend of 2D vs 3D (coprocessor
> based) graphics.
> http://www.de.tomshardware.com/graphic/20040504/images/architecture.gif
> Within one or two generations the 2D box is going to be gone.
Sor
Ville Syrjälä wrote:
On Fri, May 14, 2004 at 11:40:04AM -0700, Jon Smirl wrote:
--- Ville Syrjälä <[EMAIL PROTECTED]> wrote:
I said OpenGL is the only accelerated API available on Linux. Can you name
another?
DirectFB.
Does DirectFB work on anything beside Matrox now?
It works on any card with a w
On Thu, May 06, 2004 at 05:50:40PM -0700, Jon Smirl wrote:
> --- James Simmons <[EMAIL PROTECTED]> wrote:
> > 2) Ben suggestion that we mount userland inside the kernel during early
> >boot and use a userland library. If we would use a library then it MUST
> >be OpenGL. This would be the
On Fri, May 14, 2004 at 10:35:56AM -0700, Alex Deucher wrote:
> > Notice that this is not really true, as there is no free OpenGL
> > acceleration for any of the newer graphic cards coming out right now.
> > The fastest graphic card with full free acceleration is the radeon
> > 9000,
> > which is n
On Sat, May 15, 2004 at 09:27:34AM +0200, Holger Waechtler wrote:
> Ville Syrjälä wrote:
> >On Fri, May 14, 2004 at 11:40:04AM -0700, Jon Smirl wrote:
> >
> >>Does DirectFB work on anything beside Matrox now?
> >
> >
> >It works on any card with a working fbdev driver (vga16fb excluded).
> >Hardwa
On Fri, May 14, 2004 at 11:40:04AM -0700, Jon Smirl wrote:
> --- Ville Syrjälä <[EMAIL PROTECTED]> wrote:
> > > I said OpenGL is the only accelerated API available on Linux. Can you name
> > > another?
> >
> > DirectFB.
>
> Does DirectFB work on anything beside Matrox now?
It works on any card w
--- Ville Syrjälä <[EMAIL PROTECTED]> wrote:
> I don't understand you GPU vs. PIO comparisons. You can use the 2D engine
> with DMA as well. And at least with older cards the 2D engine is clearly
> faster than the 3D engine (~100% faster for blits on my G400) so trying to
> bypass it is just stu
--- Sven Luther <[EMAIL PROTECTED]> wrote:
> On Thu, May 06, 2004 at 05:50:40PM -0700, Jon Smirl wrote:
> > --- James Simmons <[EMAIL PROTECTED]> wrote:
> > > 2) Ben suggestion that we mount userland inside the kernel during
> early
> > >boot and use a userland library. If we would use a libr
On Fri, May 14, 2004 at 10:51:35AM -0700, Jon Smirl wrote:
> Just look at this picture and you can see the trend of 2D vs 3D (coprocessor
> based) graphics.
> http://www.de.tomshardware.com/graphic/20040504/images/architecture.gif
> Within one or two generations the 2D box is going to be gone.
>
>
Just look at this picture and you can see the trend of 2D vs 3D (coprocessor
based) graphics.
http://www.de.tomshardware.com/graphic/20040504/images/architecture.gif
Within one or two generations the 2D box is going to be gone.
If Linux wants to stay current with technology we have to start using
> On Mon, May 10, 2004 at 10:39:50PM +, Nicolas Souchu wrote:
> > Do apps manage their swap? No. I think the OS should be responsible for
> > placing the data (vertices, textures, commands) at the right/best place
> > for the HW 3D engine and the client should only fill virtual memory.
>
> >
On Mon, 10 May 2004, Alan Cox wrote:
> On Llu, 2004-05-10 at 17:14, James Simmons wrote:
> > Speaking of bloat in the kernel. When will the crypto and TCP/IP stack be
> > moved to userspace. The networking code alone is over 17 megs in size.
>
> Not on my box. Nothing like it. Although to answer th
> > But we are rendering to draw fonts, clearing a area of the screen,copyarea.
> > If we are to have a universal solution it needs to OpenGL. Either that or
> > mode switching stays in the kernel.
>
> Drawing fonts have _NOTING_ to do with mode switching ! Don't tell me
> that you can't make
On Tue, 2004-05-11 at 02:14, James Simmons wrote:
> > You are mixing things. Mode setting has nothing to do with rendering. OpenGL
> > is a rendering client. It produces commands sent to the low level kernel
> > driver and provides a 3D API, but it's not the only one. In this regard,
> > fbcon is a
On Mon, May 10, 2004 at 10:39:50PM +, Nicolas Souchu wrote:
> Do apps manage their swap? No. I think the OS should be responsible for
> placing the data (vertices, textures, commands) at the right/best place
> for the HW 3D engine and the client should only fill virtual memory.
> http://www.fr
> It's not just bloat, the network code is used millions of times per second.
> Mode setting happens occaisonally.
Using that logic then Sound cards shouldn't be in the kernel at all. I
never use my sound card continuely. I use it as a module. Would it be
acceptable if the mode setting was m
On Mon, May 10, 2004 at 11:29:40AM -0700, Jon Smirl wrote:
> It's not just bloat, the network code is used millions of times per second. Mode
> setting happens occaisonally.
But necessary some times. I think of oops and debugger.
> The other problem is memory management. What is going to happen
On Mon, May 10, 2004 at 07:28:37PM +0300, Ville Syrjälä wrote:
[...]
>
> Rendering and mode switching are completely separate issues.
Indeed and I guess we can even use the VESA mode setting and the HW
engine of recent graphic boards "concurrently".
The console system is responsible for modesett
On Llu, 2004-05-10 at 17:14, James Simmons wrote:
> Speaking of bloat in the kernel. When will the crypto and TCP/IP stack be
> moved to userspace. The networking code alone is over 17 megs in size.
Not on my box. Nothing like it. Although to answer that question with a
definitive example ELKS (
I could be wrong, but is not allocating framebuffers and mmaping memory
diffrent than setting up framebuffers and configuring DACs?
--- Jon Smirl <[EMAIL PROTECTED]> wrote:
> It's not just bloat, the network code is used millions of times per
> second. Mode
> setting happens occaisonally.
>
> Th
It's not just bloat, the network code is used millions of times per second. Mode
setting happens occaisonally.
The other problem is memory management. What is going to happen when fbdev
starts setting the mode for both heads? Who is going to mananage the VRAM when
the buffers get resized? OpenGL
On Mon, May 10, 2004 at 05:14:04PM +0100, James Simmons wrote:
>
> > You are mixing things. Mode setting has nothing to do with rendering. OpenGL
> > is a rendering client. It produces commands sent to the low level kernel
> > driver and provides a 3D API, but it's not the only one. In this regard
> You are mixing things. Mode setting has nothing to do with rendering. OpenGL
> is a rendering client. It produces commands sent to the low level kernel
> driver and provides a 3D API, but it's not the only one. In this regard,
> fbcon is a client too and XFree 2D accel is another one.
But we ar
> 1) Keep mode switching in the kernel. Merge DRI and fb together via
>sysfs interface.
>
> 2) Ben suggestion that we mount userland inside the kernel during early
>boot and use a userland library. If we would use a library then it MUST
>be OpenGL. This would be the forced standard
On Thu, 6 May 2004, Jon Smirl wrote:
> 6) What about low memory embedded systems? mesa has an excellent implementation
> of OpenGL-ES available for free. http://www.khronos.org/opengles/ It already
> supports running out of a dumb framebuffer. OpenGL-ES is small enough that
> Qualcomm is putting it
On Fri, 7 May 2004, Nicolas Souchu wrote:
> On Thu, May 06, 2004 at 02:42:14PM -0700, Jon Smirl wrote:
> > BenH and others have made proposals for pushing the mode setting code into a
> > user space library in order to reduce kernel footprint and ease debugging. Most
> > of the code needed for this
> But who cares? Do you really intend to keep a common BSD and Linux API/code base?
> Offering both solutions under BSD and GPL would be good for suggesting correct
> license usage in the embedded world. GPL is too often bypassed.
What about a dual license.
> > The big reason for merging is mem
> > Another topic that I missed was, why did kgi fail and what can we do to avoid
> > repeating the same path this time around.
>
> IIRC, the main reasons were:
> - GGI wanted to do too much at once and was too intruisive (conclusion:
> always advance in small steps, not big leaps):
>
> What is exactly your question concerning licenses?
>
> > Another topic that I missed was, why did kgi fail and what can we do to avoid
> > repeating the same path this time around.
>
> KGI failed to be accepted by linus/linux. You surely don't want repeating
> this ;) Otherwise, its design is
--- Keith Packard <[EMAIL PROTECTED]> wrote:
>
> Around 17 o'clock on May 6, Jon Smirl wrote:
>
> > A proposal has been made that OpenGL be promoted as the primary base
> graphics
> > API on Linux. Then things like Cairo and the xserver be implemented on top
> of
> > OpenGL.
>
> I respectfully d
Around 17 o'clock on May 6, Jon Smirl wrote:
> A proposal has been made that OpenGL be promoted as the primary base graphics
> API on Linux. Then things like Cairo and the xserver be implemented on top of
> OpenGL.
I respectfully disagree with this plan. OpenGL should be the sole API for
acces
--- James Simmons <[EMAIL PROTECTED]> wrote:
> 2) Ben suggestion that we mount userland inside the kernel during early
>boot and use a userland library. If we would use a library then it MUST
>be OpenGL. This would be the forced standard on all platforms. This
>would mean Mesa would
On Thu, May 06, 2004 at 02:42:14PM -0700, Jon Smirl wrote:
> --- Nicolas Souchu <[EMAIL PROTECTED]> wrote:
> > > A major topic that I missed in the original list was how to handle BSD. DRM
> > > is under the BSD license and FB is GPL. If these two code bases are merged,
> > > what are we going to d
On Thu, 6 May 2004, Jon Smirl wrote:
> Another topic that I missed was, why did kgi fail and what can we do to avoid
> repeating the same path this time around.
IIRC, the main reasons were:
- GGI wanted to do too much at once and was too intruisive (conclusion:
always advance in small steps,
On Thu, May 06, 2004 at 11:16:39AM -0700, Jon Smirl wrote:
> At the X Developers Conference there was a discussion of the issues around
> framebuffer and DRI. Theodore Ts'o suggested that I write it up and post it for
> discussion. I'm going to try and list all of the issues I've heard from all
> s
On Thu, May 06, 2004 at 11:16:39AM -0700, Jon Smirl wrote:
> At the X Developers Conference there was a discussion of the issues around
> framebuffer and DRI. Theodore Ts'o suggested that I write it up and post it for
> discussion. I'm going to try and list all of the issues I've heard from all
> s
--- Nicolas Souchu <[EMAIL PROTECTED]> wrote:
> > A major topic that I missed in the original list was how to handle BSD. DRM
> > is under the BSD license and FB is GPL. If these two code bases are merged,
> > what are we going to do about BSD? I don't know the appropriate BSD lists
> > to post th
38 matches
Mail list logo
