Jon Smirl has written,
> I've written an article that surveys the current State of Linux
> graphics and proposes a possible path forward. This is a long article
> containing a lot of detailed technical information as a guide to
> future developers. Skip over the detailed par
svgalib is spelled "svgalib"
I have started writing a windowing program which
uses svgalib. The source code is available at,
http://sourceforge.net/projects/svgalib-windows
select "browse cvs". SourceForge is rebuilding their
site, so some things don't work.
___
On Thu, September 1, 2005 4:38 pm, Jon Smirl said:
> We're not putting all of our eggs in one basket, you keep forgetting
> that we already have a server that supports all of the currently
> existing hardware. The question is where do we want to put our future
> eggs.
Amen! All these arguments
On 9/1/05, Jim Gettys <[EMAIL PROTECTED]> wrote:
> Not at all.
>
> We're pursuing two courses of action right now, that are not mutually
> exclusive.
>
> Jon Smirl's argument is that we can satisfy both needs simultaneously
> with a GL only strategy, and that doing two is counter productive,
> pr
On Wed, Aug 31, 2005 at 08:59:23PM -0700, Keith Packard wrote:
|
| Yeah, two systems, but (I hope) only one used for each card. So far, I'm
| not sure of the value of attempting to provide a mostly-software GL
| implementation in place of existing X drivers.
For the short term it's valuable for t
Not at all.
We're pursuing two courses of action right now, that are not mutually
exclusive.
Jon Smirl's argument is that we can satisfy both needs simultaneously
with a GL only strategy, and that doing two is counter productive,
primarily on available resource grounds.
My point is that I don't
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
It's other (non-orientation) texture state I had in mind:
- the texel format (OpenGL has over 30 possible texture formats).
- texture size and borders
- the filtering mode (linear, nearest, etc)
- coordinate
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
> It's other (non-orientation) texture state I had in mind:
>
> - the texel format (OpenGL has over 30 possible texture formats).
> - texture size and borders
> - the filtering mode (linear, nearest, etc)
> - coordinate wrap mode (c
jg wrote @ Thu, 01 Sep 2005 11:59:33 -0400:
> Legacy hardware and that being proposed/built for the developing world
> is tougher; we have code in hand for existing chips, and the price point
> is even well below cell phones on those devices. They don't have
> anything beyond basic blit and, mirac
Alan Cox wrote:
On Iau, 2005-09-01 at 09:24 -0600, Brian Paul wrote:
If the blending is for screen-aligned rects, glDrawPixels would be a
far easier path to optimize than texturing. The number of state
combinations related to texturing is pretty overwhelming.
As doom showed however once yo
On Thu, 2005-09-01 at 09:24 -0600, Brian Paul wrote:
>
> If the blending is for screen-aligned rects, glDrawPixels would be a
> far easier path to optimize than texturing. The number of state
> combinations related to texturing is pretty overwhelming.
>
>
> Anyway, I think we're all in agree
On Iau, 2005-09-01 at 09:24 -0600, Brian Paul wrote:
> If the blending is for screen-aligned rects, glDrawPixels would be a
> far easier path to optimize than texturing. The number of state
> combinations related to texturing is pretty overwhelming.
As doom showed however once you can cut down
Just a few comments...
Keith Packard wrote:
Again, the question is whether a mostly-software OpenGL implementation
can effectively compete against the simple X+Render graphics model for
basic 2D application operations, and whether there are people interested
in even trying to make this happen.
On 9/1/05, Alan Cox <[EMAIL PROTECTED]> wrote:
> On Iau, 2005-09-01 at 08:00 +0200, Antonio Vargas wrote:
> > 2. whole screen z-buffer, for depth comparison between the pixels
> > generated from each window.
>
> That one I question in part - if the rectangles are (as is typically the
> case) large
On Iau, 2005-09-01 at 08:00 +0200, Antonio Vargas wrote:
> 2. whole screen z-buffer, for depth comparison between the pixels
> generated from each window.
That one I question in part - if the rectangles are (as is typically the
case) large then the Z buffer just ups the memory accesses. I guess fo
On Wed, Aug 31, 2005 at 08:11:12PM -0700, Ian Romanick wrote:
| Allen Akin wrote:
| > Jon's right about this: If you can accelerate a given simple function
| > (blending, say) for a 2D driver, you can accelerate that same function
| > in a Mesa driver for a comparable amount of effort, and deliver
On 9/1/05, Ian Romanick <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Allen Akin wrote:
> > On Wed, Aug 31, 2005 at 02:06:54PM -0700, Keith Packard wrote:
> > |
> > | ...So far, 3D driver work has proceeded almost entirely on the
> > | newest documented h
On Wed, 2005-08-31 at 18:58 -0700, Allen Akin wrote:
> On Wed, Aug 31, 2005 at 02:06:54PM -0700, Keith Packard wrote:
> | On Wed, 2005-08-31 at 13:06 -0700, Allen Akin wrote:
> | > ...
> |
> | Right, the goal is to have only one driver for the hardware, whether an
> | X server for simple 2D only e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Allen Akin wrote:
> On Wed, Aug 31, 2005 at 02:06:54PM -0700, Keith Packard wrote:
> |
> | ...So far, 3D driver work has proceeded almost entirely on the
> | newest documented hardware that people could get. Going back and
> | spending months
On Wed, Aug 31, 2005 at 02:06:54PM -0700, Keith Packard wrote:
| On Wed, 2005-08-31 at 13:06 -0700, Allen Akin wrote:
| > ...
|
| Right, the goal is to have only one driver for the hardware, whether an
| X server for simple 2D only environments or a GL driver for 2D/3D
| environments. ...
I count
> "Ian" == Ian Romanick <[EMAIL PROTECTED]> writes:
Ian> I'd really like to see a list of areas where OpenGL
Ian> isn't up to snuff for 2D operations.
Is that OpenVR spec from Khronos a reasonable baseline
for such a list?
-JimC
--
James H. Cloos, Jr. <[EMAIL PROTECTED]>
-
To unsubscribe f
On Wed, 2005-08-31 at 13:06 -0700, Allen Akin wrote:
> On Wed, Aug 31, 2005 at 11:29:30AM -0700, Keith Packard wrote:
> | The real goal is to provide a good programming environment for 2D
> | applications, not to push some particular low-level graphics library.
>
> I think that's a reasonable goal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Allen Akin wrote:
> I believe we're doing well with layered implementation strategies like
> Xgl and Glitz. Where we might do better is in (1) extending OpenGL to
> provide missing functionality, rather than creating peer low-level APIs;
> (2) expres
On Wed, Aug 31, 2005 at 11:29:30AM -0700, Keith Packard wrote:
| The real goal is to provide a good programming environment for 2D
| applications, not to push some particular low-level graphics library.
I think that's a reasonable goal.
My red flag goes up at the point where the 2D programming en
Well, I'm sure you'll keep us honest... ;-).
- Jim
On Wed, 2005-08-31 at 12:06 -0700, Allen Akin wrote:
> On Wed, Aug 31, 2005 at 01:48:11PM -0400, Jim Gettys wrote:
> | Certainly replicating OpenGL 2.0's programmability through Render makes
> | no sense at all to me (or most othe
On Wed, Aug 31, 2005 at 01:48:11PM -0400, Jim Gettys wrote:
| Certainly replicating OpenGL 2.0's programmability through Render makes
| no sense at all to me (or most others, I believe/hope). If you want to
| use full use of the GPU, I'm happy to say you should be using OpenGL.
When expressed tha
On Tue, 2005-08-30 at 23:33 -0700, Allen Akin wrote:
> On Tue, Aug 30, 2005 at 01:26:53PM -0400, David Reveman wrote:
> | On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
> | > In general, the whole concept of programmable graphics hardware is
> | > not addressed in APIs like xlib and Cairo. Thi
On 8/31/05, Jim Gettys <[EMAIL PROTECTED]> wrote:
> Certainly replicating OpenGL 2.0's programmability through Render makes
> no sense at all to me (or most others, I believe/hope). If you want to
> use full use of the GPU, I'm happy to say you should be using OpenGL.
>
Certainly replicating OpenGL 2.0's programmability through Render makes
no sense at all to me (or most others, I believe/hope). If you want to
use full use of the GPU, I'm happy to say you should be using OpenGL.
- Jim
On Tue, 2005-08-30 at 23:33 -0700, Allen Akin
On Tue, 2005-08-30 at 23:33 -0700, Allen Akin wrote:
> On Tue, Aug 30, 2005 at 01:26:53PM -0400, David Reveman wrote:
> | On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
> | > In general, the whole concept of programmable graphics hardware is
> | > not addressed in APIs like xlib and Cairo. Thi
On 8/31/05, Eric Anholt <[EMAIL PROTECTED]> wrote:
> the X Render extension." No, EXA is a different acceleration
> architecture making different basic design decisions related to memory
> management and driver API.
I did start the EXA section off with this: "EXA replaces the existing
2D XAA driv
i have no freaking idea of coding. but going throught this "Discuss
issues related to the xorg tree" talk, made me feel and say "mommy
(coder), daddy (admin), please dont fight you tearing
us(users) apart."
glad its worked out.. all i hope is we(users) , now , get some nice
fast xorg :D.
On Tue, Aug 30, 2005 at 01:26:53PM -0400, David Reveman wrote:
| On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
| > In general, the whole concept of programmable graphics hardware is
| > not addressed in APIs like xlib and Cairo. This is a very important
| > point. A major new GPU feature, pro
On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
> I've written an article that surveys the current State of Linux
> graphics and proposes a possible path forward. This is a long article
> containing a lot of detailed technical information as a guide to
> future develope
Access has been restored. The URL is good again.
http://www.freedesktop.org/~jonsmirl/graphics.html
--
Jon Smirl
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.or
Before you shut my account off I made you this offer:
On 8/31/05, Jon Smirl <[EMAIL PROTECTED]> wrote:
> Quit being a pain and write a response to the article if you don't
> like it. Censorship is not the answer. Open debate in a public format
> is the correct response. If you want me to I'll add
On 8/31/05, Daniel Stone <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-08-31 at 00:50 -0400, Jon Smirl wrote:
> > On 8/30/05, Daniel Stone <[EMAIL PROTECTED]> wrote:
> > > 'As a whole, the X.org community barely has enough resources to build a
> > > single server. Splitting these resources over many pa
On 8/30/05, Daniel Stone <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
> > The article has been reviewed but if it still contains technical
> > errors please let me know. Opinions on the content are also
> > appreciated.
>
> 'As a whole, the X.org community barel
On 8/30/05, Daniel Stone <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
> > The article has been reviewed but if it still contains technical
> > errors please let me know. Opinions on the content are also
> > appreciated.
>
> 'As a whole, the X.org community barel
On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
> The article has been reviewed but if it still contains technical
> errors please let me know. Opinions on the content are also
> appreciated.
'As a whole, the X.org community barely has enough resources to build a
single server. Splitting these
>
> As the author of Xgl and glitz I'd like to comment on a few things.
>
> >From the article:
>
> > Xgl was designed as a near term transition solution. The Xgl model
> > was to transparently replace the drawing system of the existing
> > X server with a compatible one based on using OpenGL as
On 8/30/05, David Reveman <[EMAIL PROTECTED]> wrote:
> > Xgl was designed as a near term transition solution. The Xgl model
> > was to transparently replace the drawing system of the existing
> > X server with a compatible one based on using OpenGL as a device
> > driver. Xgl maintained all of the
On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
> I've written an article that surveys the current State of Linux
> graphics and proposes a possible path forward. This is a long article
> containing a lot of detailed technical information as a guide to
> future develope
I've written an article that surveys the current State of Linux
graphics and proposes a possible path forward. This is a long article
containing a lot of detailed technical information as a guide to
future developers. Skip over the detailed parts if they aren't
relevant to your area of w
44 matches
Mail list logo
