On Mon, 22 Feb 1999, Brian Paul wrote:
> I'd like to set up an email address like [EMAIL PROTECTED] to which
> people can send their bug reports, instead of sending them to me.
>
> I'm tempted to alias it to mesa-dev so those of us who develop/maintain
> the code can see the reports and take car
On Mon, 1 Mar 1999, charlie wallace wrote:
> one comment to add
>
> Lint!!!
Most modern compilers produce better warnings than lint anyway...
presuming you use ANSI-stlye function prototypes and don't switch
to K&R mode.
Steve Baker(817)619-2657 (Vox/Vox-Mail)
Raytheon System
On Wed, 24 Mar 1999, Brian Paul wrote:
> Keith W,
>
> I was browsing the latest code to see where assembly language
> optimizations will hook into the transformation code. It wasn't
> obvious to me where this would happen.
>
> Someone from Intel wrote me today that they've been testing PIII
>
On Wed, 24 Mar 1999, Brian Paul wrote:
> Marc Jauvin wrote:
> >
> > Hi,
> >
> > I have some work to do with respect to MIP mapping and I would like to know
> > where I can find information on how the texture selection works and where
> > exactly in the code it can be found.
>
> The OpenGL spec
On Wed, 24 Mar 1999, charlie wallace wrote:
> is dlopen available on every platform that mesa is ? If it
> is then i can`t see why not, if not then it wouldn`t work
> and we`d have to roll our own.
dlopen is available on most (maybe all) UNIX/Linux/IRIX/Solaris
type boxes - but not under Windo
On Thu, 25 Mar 1999, Brian Paul wrote:
> > Since there are rumours of a couple of the IHV's getting geared up
> > to putting geometry hardware onto low end cards (in the next year or
> > so), it may be time to anticipate what that would do to the
> > Mesa core. It's kindof a similar problem to t
On Thu, 25 Mar 1999, Marc Jauvin wrote:
> Brian Paul wrote:
> >
> > Marc Jauvin wrote:
> > >
> > > Hi,
> > >
> > > I have some work to do with respect to MIP mapping and I would like to know
> > > where I can find information on how the texture selection works and where
> > > exactly in the code
On Fri, 26 Mar 1999, Brian Paul wrote:
> Sorry Steve, I just had to test this out. :-)
>
> I ran the mipmap.c program on my IMPACT, IR and O2 systems and saw
> straight transition lines.
Really?
I find that rather suprising. Do you agree with my explanation as
to why the lines should be *expec
On Wed, 31 Mar 1999, Brian Paul wrote:
> Just got a note from Zoid at Id. He's working on Quake3 with Mesa
> for Linux. Evidently there's a big performance problem when using
> the glPolygonOffset feature. He said Mesa 2.6 works fine but 3.0
> is really slow.
Of course, it doesn't work at al
On Wed, 31 Mar 1999, Brian Paul wrote:
> An update from Zoid: He disabled the polygon offset calls in Q3
> and it ran fast and looked correct using Mesa 3.0.
So why is he using glPolygonOffset if the image looks OK without it?
I find that hard to believe.
> This clearly isn't a perfect solut
On Wed, 31 Mar 1999, Holger Waechtler wrote:
> > Add -DUSE_3DNOW_ASM to your CFLAGS to enable it.
> >
> Perhaps it's a good Idea to create a new target linux-3dnow-elf in the
> Makefile ??
We would start to get into a combinatorial nightmare though. We already
have GLIDE/non-GLIDE and Voodoo-2
Hi,
I just found this on the web:
http://hermes.terminal.at
...it's a library containing optimised routines for
converting pixels from one format (eg 8+8+8) into
another (eg 5+6+5). It appears to be highly optimised
for a bunch of different CPU's and a bunch of OS's
and can do things
On Sat, 3 Apr 1999, Brian Paul wrote:
> I'm unable to
> use gdb because when the crash occurs the X server is grabbed by
> Quake so mouse & keyboard are dead. If I don't use gdb the
> segfault terminates Quake and X server is unlocked. I've been
> using asserts and printf's to track it this f
On Thu, 8 Apr 1999, Brian Paul wrote:
> I haven't read the 3dfx newsgroups in quite a while. What was the
> problem?
>
> I don't know if I'd like Mesa to print a warning if you don't have
> MESA_GLX_FX set.
The problem is that we see about a half dozen messages a week
(on various Quake/Linux
On Fri, 9 Apr 1999, Brian Paul wrote:
> I see. If the message is only printed when the 3Dfx driver is compiled
> in then that's not too bad. I guess we can try that and see if we get
> any negative complaints.
I'd sure hope it was only emitted when 3Dfx code is compiled in *AND*
usable 3Dfx h
On Thu, 29 Apr 1999, C.J. Beyer wrote:
> Btw. Is there anyone working on adding polygon_offset support for FX Mesa.
> It's used in Quake3. It doesn't seem to hard to implement at all.
>
> Any toughs where/how should it implemented?
I can expect some hidden 'gotcha's.
The *obvious* thing is jus
On Fri, 30 Apr 1999, Keith Whitwell wrote:
> Stephen J Baker wrote:
> >
> > 1x1 textures are allowed in OpenGL and they do have uses. They can be
> > used to globally change the colour of a bunch of polygons with a single
> > texel texture download for example.
>
On Fri, 30 Apr 1999, Keith Whitwell wrote:
> I've just committed a one-line fix to a problem in
> gl_test_texture_object_completeness() which rejected 1x1
> LINEAR_MIPMAP_NEAREST textures used by q3test at the lowest
> level-of-detail settings.
>
> You could see this problem clearly in the fo
On Fri, 30 Apr 1999, Mikl[ISO-8859-1] ós Fazekas wrote:
> Hello!
>
> > Certainly too costly to do per triangle. The options open to us for the
> > FX driver both require us to calculate the area of each triangle, and
> > either use this value to nudge the Z coordinates, or trust glide and
> > c
On Thu, 6 May 1999, Brian Paul wrote:
> This extension is still in Mesa. It's regarded as obsolete in favor
> of GL_ARB_multitexture. I think the only app that really uses this
> is Quake2.
>
> Keith W. had asked about removing it since it's both obsolete and it
> introduced some ugliness into
On Tue, 18 May 1999, Kendall Bennett wrote:
> Anyway, the more I thought about this and the more we discussed it
> amongst ourselves here at SciTech, the more we realised that the
> problem is that there is currently no mechanism for any commercial
> organisation to put funding behind Mesa.
I
On Wed, 19 May 1999, Kendall Bennett wrote:
> Yes, I agree that this is one of the best ways for people to get paid
> for their work. This is how we sponsor development of Mesa, by having
> out paid employees work on the code and contribute it back to the
> community. This is also really how K
On Fri, 21 May 1999, Christopher R. Bowman wrote:
> >/* Copyright (c) Mark J. Kilgard, 1994, 1995, 1996, 1998. */
> >
> >/* This program is freely distributable without licensing fees and is
> > provided without guarantee or warrantee expressed or implied. This
> > program is -not- in the p
On Fri, 21 May 1999, Brian Paul wrote:
> In the case of Glide, version 3.x has a fairly flexible vertex array
> interface which will hopefully help with this problem. I expect we'll
> use Glide 3.x exclusively (instead of 2.x) as soon as it's available
> on Linux.
Does GLIDE 3.x run on the enti
On Mon, 24 May 1999, Thomas Tanner wrote:
> what do you think about using GNU autoconf/automake/libtool for Mesa?
>
> These tools are used by most modern open source packages,
> simplify and standardize the installation process
> (configure; make; make install) and make it much easier
> to
On Mon, 24 May 1999, Brian Paul wrote:
> > what do you think about using GNU autoconf/automake/libtool for Mesa?
> 1. As you point out, there's probably a few non-Unix systems that
> don't have autoconf but work with the existing Makefiles. Traditional
> Makefiles will probably still be neede
On Tue, 25 May 1999, Thomas Tanner wrote:
> > For the long term though I think autoconf probably is the right way
> > to go.
So many OpenSource packages use it now, I think Mesa should switch to
it soon or risk looking very out of date.
> > A few concerns:
> >
> > 1. As you point out, there's
on Wed, 26 May 1999, Kendall Bennett wrote:
> "Stephen J Baker" <[EMAIL PROTECTED]> wrote:
>
> > The configure script does rely on some UNIX tools like "sed" - so
> > to use this scheme under Windoze, you need the CygWin tools - or
> > somethi
On Wed, 26 May 1999, charlie wallace wrote:
> why not just standardize makes across as many platforms as
> possible, ie dmake . which is available on almost every platform
> mesa is.
>
> projects files are useful too, makefiles can be incredibly esoteric,
> each to their own. I dont see why the
On Tue, 8 Jun 1999, Brian Paul wrote:
> > The real question is whether Brian wants the next release version to
> > include the new code or not.
>
> I don't have a date in mind for the next beta release.
>
> I'd like to keep the mainline code pretty much stable. After Keith
> has tested and deb
On Tue, 8 Jun 1999, Holger Waechtler wrote:
> Who says, that our super driver is not able to load it's subdrivers
> dynamically ??
>
> (could you explain, how dlopen() is used ?? - works it on non-Unix
> platforms (MacOS, Dos, Windows) ?? -- if not, we could put some #ifdef's
> around it and lin
On Tue, 8 Jun 1999, Holger Waechtler wrote:
>
>
> On Mon, 7 Jun 1999 [EMAIL PROTECTED] wrote:
>
> > On Mon, 7 Jun 1999 14:04:49 -0700, Keith Whitwell wrote:
> >
> > >Can't we have a prebuilt ./configure in the repository?
> >
> > This is generally considered to be a Bad Idea, since configure
On Thu, 10 Jun 1999, Thomas Tanner wrote:
> > 2. There is the public interface which connects OpenGL/Mesa to the
> >OS / window system. This interface, by definition, is unique to
> >each system. These are the GLX, WGL, OS/Mesa, SVGA, Glide, etc
> >interfaces.
>
> Yes. That's what
On Thu, 10 Jun 1999, Jon Taylor wrote:
> > 1. Linux (Unix) and Windows are, by far, the most popular platforms for
> > Mesa/OpenGL. The GLX and WGL interfaces are very well established.
> > Nobody will use a Mesa-specific interface instead of GLX/WGL since
> > they'd be limiting themselves to Me
On Mon, 28 Jun 1999, Thomas Tanner wrote:
>
> On 24-Jun-99 Holger Waechtler wrote:
> >> > Should the final release generate a stripped library, which is smaller ?
> >> Yes, but automake 1.4 doesn't support it, only the latest CVS snapshots
> >> of automake and libtool do :-(
> > Is there a pro
On Sun, 4 Jul 1999, Keith Whitwell wrote:
> > And another question, when will Mesa switch to Glide3, might it happen
> > before 3.1 release?
>
> Daryll seems to have a fair bit on his plate - and he's never put any sort of
> date on a glide 3 release.
The last time I talked to Daryll about thi
On Thu, 8 Jul 1999, Mikl[ISO-8859-1] ós Fazekas wrote:
> I'm just wondering if it's always necessary to maintain a copy of the
> texture in Mesa?
> Couldn't it avoided in some ways?
I think we had this discussion before - and the answer is that the
driver really does have to keep a copy.
If
On Tue, 3 Aug 1999, Keith Whitwell wrote:
> I've checked in some code which I think fixes the 2 outstanding bugs reported by
> Miklos.
>
> It's been a little hard to keep track of what's happening with bugs, so at the
> risk of starting a deluge I'm going to ask everyone who's (1) got a bug in
On Wed, 18 Aug 1999, Brian Paul wrote:
> I have a feeling, however, that we'll have to rebuild the src/
> CVS files from scratch. I've seen several badly corrupted files.
> Whoever had a recent snapshot from before the crash should volunteer
> to upload all their files.
What was that quote fro
On Sat, 28 Aug 1999, Thor Henning Amdahl wrote:
>
> I have found a bug with mip-map texturing only present using Voodoo
> hardware. If you use the X11 driver everything is OK. Also if you use
> other than mip-map type filtering for GL_TEXTURE_MIN_FILTER the bug
> disapear.
> To see the proble
On Wed, 1 Sep 1999 [EMAIL PROTECTED] wrote:
> First, one might well ask why texture memory is treated differently
> from framebuffer memory in the first place. Why not have just one
> chunk of memory that you can use for both texture and rendering?
> Loosely, the answer is that you can often ge
(Arguments with Allen are *so* informative...and also hard to win!)
On Wed, 1 Sep 1999 [EMAIL PROTECTED] wrote:
> | > You'd need to figure out which odd corner-cases could arise
> | > and how you want to handle them. What if you use a texture
> | > while you're renderin
On Fri, 3 Sep 1999 [EMAIL PROTECTED] wrote:
> | ...It's not
> | guaranteed to be true (Think multitexture for example - all N
> | textures have to be resident at the same time - but the proxy
> | command didn't know that the other 4 textures you ar
On Tue, 7 Sep 1999, Brian Paul wrote:
> Here's another issue. There's an effort underway to standardize
> the OpenGL environment on Linux. One aspect of that is version
> numbering for the libGL.so file (used to be libMesaGL.so).
>
> I propose this lib name for the 3.1 release: libGL.so.1.2.3
On Tue, 7 Sep 1999, Brian Paul wrote:
> I'd like to make a 3.1 beta 3 release by the end of next week.
> Fellow developers, any concerns?
Is anyone going to put in the glGetFuncAddressEXT stuff before
then so we are essentially compliant with the new Linux OpenGL
Base spec?
Steve Baker
On Wed, 8 Sep 1999, Joe Waters wrote:
> On the other hand, I think nvidia's reference implementation for linux *did*
> include its own glu library -- are these the same? Should people continue to
> look to Mesa for the de facto standard glu implementation?
GLU is supposed to be a pure layer on
On Wed, 8 Sep 1999, Jon Taylor wrote:
> > Here's another issue. There's an effort underway to standardize
> > the OpenGL environment on Linux.
>
> ...Which explicitly states that this "standardization effort" is
> predicated on the existence and use of X/GLX, and hence is not relevant
>
On Fri, 10 Sep 1999, Keith Whitwell wrote:
> I hadn't even considered fat lines (or stipples). I was just thinking about how
> to define the two triangles which define the line - for points it's easy as the
> offsets will be axis-aligned, but for lines I'm not sure you can get away with
> just a
On Wed, 15 Sep 1999, Keith Whitwell wrote:
> I think that the long development cycle for 3.1 was justified (I have to say that
> really...), but it'd be nice to cycle more rapidly for the next few iterations.
Yes - the dev cycle for 3.1 was justified - but it highlights
the need to go to an odd
On Wed, 15 Sep 1999, Brian Paul wrote:
> I think we all agree that the library name should be
> "libGL.so.1.2.something"
>
> Josh's suggestion for something=030100 is good, even though I doubt
> there'd be more than 9 patch levels to a given release.
>
> If we don't encode the Mesa version in t
On Wed, 15 Sep 1999, Brian Paul wrote:
> > One place where this would be of immediate and enormous use
> > would be in detecting the XMesaSetFXmode call...but that doesn't
> > obviously fall into any of the scope of this stuff.
> >
> > Could this call now be considered a GLX extension so I can
>
On Sat, 11 Sep 1999, Brian Paul wrote:
> [cross-posting]
>
> I've implemented this extension in Mesa 3.1 and checked it into
> the CVS repository. I also implemented GLU_EXT_get_proc_address
> and GLX_EXT_get_proc_address. Only the core extension has been
> documented in the Mesa/docs/ directo
On Sat, 11 Sep 1999, Brian Paul wrote:
> [cross-posting]
>
> I've implemented this extension in Mesa 3.1 and checked it into
> the CVS repository. I also implemented GLU_EXT_get_proc_address
> and GLX_EXT_get_proc_address. Only the core extension has been
> documented in the Mesa/docs/ directo
On Wed, 15 Sep 1999, Keith Whitwell wrote:
> People tell me there are problems with TuxAQFH. Has anyone distilled these
> problems to a soundbite sized description?
All programs basd on my PLIB library seem to suffer from this one.
The text rendering routines (which use textured triangle strip
On Thu, 16 Sep 1999, Stephen J Baker wrote:
> On Wed, 15 Sep 1999, Keith Whitwell wrote:
>
> > People tell me there are problems with TuxAQFH. Has anyone distilled these
> > problems to a soundbite sized description?
OK, I just tested PLIB and Tux_AQFH on a Voodoo-2 wit
On Fri, 17 Sep 1999, Theodore Jump wrote:
>
> >the book/anti.c demo is incredibly coloured and the transparent help
> >screen in the 3dfx/demos/tunnel.c demo is not transparent.
>
> I can't speak to the book/anti.c demo as it seems to run fine on Windows,
> however the 3dfx/demos/tunnel.c demo
On Mon, 20 Sep 1999, Jeff Slutter wrote:
> Thanks for the sample program, I compiled it in both my Linux and
> Windows to compare them. In Linux (but not Windows) I get the same problem
> as what is in Descent 3 with the perspective texture mapping once I hit the
> '4' key to switch to use g
On Wed, 13 Oct 1999, Brian Paul wrote:
> I've renamed the memory macros I created a few days ago. I removed
> the GL_ prefix on each one in order to prevent future name-space
> collisions with future GL enums/tokens.
>
> The new macros are
> MALLOC
> CALLOC
> MALLOC_STRUCT
> CALLOC_STRUCT
> FRE
On Fri, 22 Oct 1999, Ralph Giles wrote:
> Hi,
>
> I'm curious about the status of the Mesa-is-not-OpenGL issue. I've gotten
> the impression that things are a little more relaxed with the library name
> change, etc.
>
> Specifically, this came up in the context of adding the mga GLX module to
>
On Wed, 3 Nov 1999, Brian Paul wrote:
> Jean-Francois Panisset wrote:
> >
> > <[EMAIL PROTECTED]>Brian Paul writes
> > >
> > >For Mesa 3.3 (the new development) I'll extend the new imaging
> > >code (in image.[ch]) into glDrawPixels, glCopyPixels and
> > >glColorTable. Those functions might no
On Sun, 7 Nov 1999, Jean-Francois Panisset wrote:
> I imagine that there is a good reason for using enums instead of
> #defines in the the Mesa gl.h and glu.h?
The other reason is that we'll want to be compliant with the
Linux OpenGL Base stuff - and for that it will be necessary to
use a stand
On Thu, 11 Nov 1999, Kendall Bennett wrote:
> Hi Brian,
>
> > > 1. #define MESA_MINOR_VERSION 1
> > > Shouldn't this be "3" instead of "1"? (GL\gl.h)
> >
> > The MESA_MAJOR_VERSION and MESA_MINOR_VERSION defines in gl.h are
> > going away. I'm trying to make Mesa's headers more compatible with
On Thu, 11 Nov 1999, Kendall Bennett wrote:
> Forwarded message:
> From: Self
> To: Brian Paul <[EMAIL PROTECTED]>
> Subject: Re: [Mesa-dev] branching plans
> Date: Wed, 10 Nov 1999 19:41:16 -0800
>
> Hi Brian,
>
> > I plan on creating the 3.2 development branch today.
> > The branch tag w
On Fri, 12 Nov 1999, Heriberto Delgado wrote:
> My name is Heriberto Delgado. I'm new at this list, and pretend to
> participate frequently on it. My current interest with Mesa is to
> begin developing an -like API for the Palm (Pilot, as it was known some
> time ago). By now, I have some worki
On Mon, 15 Nov 1999, Brian Paul wrote:
> However, as I understand it, the system is limited to 32KB code
> and data segments. Mesa's code is much larger and often
> allocates buffers larger than 32KB.
>
> It may be pretty hard to squeeze Mesa into the Palm. Also, I really
> don't want to see t
On Wed, 1 Dec 1999, JONATHAN DINERSTEIN wrote:
> As an example of the kind of rendering errors I want to get rid of,
> check out:
> http://www.npl.com/~jon/
>
> It is a jpeg so some amount of loss has happened, but you can still easily see
> the problem. All I did was have GLUT
On Thu, 2 Dec 1999, Doug Rabson wrote:
> > Per-pixel lighting ("per fragment lighting" in OpenGL parlance) is the
> > solution - but hardware rendering engines don't do that (yet) because it's
> > a LOT more math. Phong shading and per-pixel lighting are really just the
> > same thing.
>
> Phong
On Mon, 6 Dec 1999, Tim Little wrote:
> RGB space also adds to the problem. The linear interpolation causes
> different hues and saturation to appear across the triangle as well. I
> have implemented a software rasterizer that works in HLS space and the mach
> banding is greatly reduced ther
On Tue, 7 Dec 1999, Brad Grantham wrote:
> You think this work will be trivial, and it will be be easy to
> implement the *specific* functionality you want, but weaving it into
> the rest of the OpenGL state machine will take a lot more work than
> you're expecting. In order to make this useful
On Mon, 10 Jan 2000, Bernd Kreimeier wrote:
> Jim Kutter writes:
> > i.e. 512x384 just displays in part of the screen, or worse yet, it falls
> > back to mesa software.
>
> On a related note, is there any way to prevent the fallback
> to software, and have glXCreateContext fail instead?
> The
On Tue, 11 Jan 2000, Bernd Kreimeier wrote:
> Stephen J Baker writes:
> > In the application, you can do a glGetString(GL_RENDERER)
> > and detect that it's fallen back to software - and if you
> > don't like that - pop up a cute message and abort.
>
> I
So, what does this:
http://www.quicken.com/investments/news/story/pr/?story=/news/stories/pr/2126/sfw052.htm&symbol=SGI
...mean for the future of Mesa?
Steve Baker(817)619-2657 (Vox/Vox-Mail)
Raytheon Systems Inc. (817)619-2466 (Fax)
Work: [EMAIL PROTECTED] htt
I was wondering about whether we should consider
dropping GLUT from the next major Mesa distribution
(3.4 I guess) and replacing it with 'freeglut':
http://freeglut.sourceforge.net
...which has an Xfree license rather than GLUT's
"free for distribution but not public domain"
license.
Freegl
On Wed, 26 Jan 2000, Adam D. Moss wrote:
> Stephen J Baker wrote:
> > I was wondering about whether we should consider
> > dropping GLUT from the next major Mesa distribution
> > (3.4 I guess) and replacing it with 'freeglut'
>
> FWIW I think that this
On Wed, 26 Jan 2000, Brad Grantham wrote:
> > From [EMAIL PROTECTED] Wed Jan 26 11:24:14 2000
> > So, what does this:
> >
> >
>http://www.quicken.com/investments/news/story/pr/?story=/news/stories/pr/2126/sfw052.htm&symbol=SGI
> >
> > ...mean for the future of Mesa?
>
> I imagine (but
On Wed, 26 Jan 2000, Brian Paul wrote:
> I didn't even know that freeglut existing until this morning.
Yep. It hasn't been well advertized - and it's very new.
> What exactly are the terms of Mark's copyright on GLUT?
It's in the file 'NOTICE' in the top of the GLUT distro.
It says:
"NOTI
On Wed, 26 Jan 2000, JONATHAN DINERSTEIN wrote:
> I think that open source OpenGL will eventually replace Mesa for the simple
> fact that vendors will trust SGI's OpenGL over Mesa. I'm not saying that Mesa
> is a poor library, but that SGI's OpenGL has the SGI name attached.
>
> For the best be
On Wed, 26 Jan 2000, JONATHAN DINERSTEIN wrote:
> >I don't like the idea of giving Mesa away for SGI to act as gatekeeper.
> >
> >I think we have to think more in terms of pulling stuff out of SI and
> >into Mesa - if the license can be straightened out in *that* direction.
>
> I can agree with
On Wed, 26 Jan 2000, mitch wrote:
> I think that the good parts of Opengl should be merged to the bad parts
> of mesa. Also, is there anyway to squeeze some more speed out of mesa?
> It seems that mesa is a good 8 to 10 FPS slower than Opengl with most
> apps and is much slower for low resolution
On Thu, 27 Jan 2000, Jacob (=Jouk) Jansen wrote:
> [EMAIL PROTECTED] wrote on 26-JAN-2000 18:40:01.60
> >Stephen J Baker wrote:
> >>
> >> On Wed, 26 Jan 2000, Adam D. Moss wrote:
> >>
> >> > Stephen J Baker wrote:
> >> > > I was wo
On Tue, 14 Mar 2000, Brian Paul wrote:
> Last night I finished my antialiased triangle code for Mesa 3.3.
> It seems to work pretty well. It could stand some performance
> tuning but it'll always be considerably slower than non-
> antialiased triangles.
>
> I believe this was the last bit of Op
81 matches
Mail list logo
