mesa3d-dev

[Mesa3d-dev] www.mesa3d.org address change

[Brian P. <br...@va...>]

The mesa3d.org domain name now points to the mesa3d.sourceforge.net
website.  I think I've updated all the links and URLs appropriately
but if anyone finds a problem, let me know.

-Brian

[Mesa3d-dev] Re: [Dri-devel] machtest

[<pk...@ed...>]

On Thu, 7 Sep 2000, Marcelo E. Magallon wrote:

>     a colleague here has written a benchmarking system for OpenGL which
>  I think is of interest to people doing development work for these
>  projects as well as their respective users.
> 


Seemed to crash my box nicely again :) 

Fscks..

(G400 and dri)

- Pasi Kärkkäinen
       
                                   ^
                                .     .
                                 Linux
                              /    -    \
                             Choice.of.the
                           .Next.Generation.

[Mesa3d-dev] machtest

[Marcelo E. M. <mar...@bi...>]

Hi,

    a colleague here has written a benchmarking system for OpenGL which
 I think is of interest to people doing development work for these
 projects as well as their respective users.

 Currently there are results available for several NVidia cards (some of
 them using old versions of utah-glx, some of them using the Linux
 drivers from NVidia, some of them using Windows drivers) as well as
 some SGI hardware.  I'm sure Matthias would appreciate results for
 other configurations (I personally would love to see results for non
 NVidia hardware, I have to give him the results for my own G400)

 The homepage is http://wwwvis.informatik.uni-stuttgart.de/machtest/ and
 the sources (GPL) can be found there as well as binaries for some
 configurations.

 Just to tickle your curiosity, a partial results lists looks like:
 
 Log file                                         IR2
 
 Gfx card                                   InfiniteReality2

 Machtest Version                           0.8 [3] / f-0.3
 
 CPU and system info                        Onxy2 14x R10000 195MHz
 
 Basic vertex transformations /s            10.06M +
                                            pointarray /2
 
 Fill rate, Flat Smooth, pixel/s            466.4M
                                            466.4M
 
 Triangles /s                               1.725M
                                            trimulti /2
 
 Triangles, 64x stripped /s                 5.078M
 
 Lit vertex transformations, 1 Light /s     4.63M
                                            pointarray /1
 
 Lit vertex transformations, 5 Light /s     2.821M
                                            pointarray /1

 Cheers,

                                   Marcelo

Re: [Mesa3d-dev] Call for more general hardware API

[Brian P. <br...@va...>]

"Marcelo E. Magallon" wrote:
> 
> >> Brian Paul <br...@va...> writes:
> 
>  > By popular demand I added the OSMesa feature into XFree86/DRI
>  > 4.0.1.  [...]  They share common dispatch code and coexist as
>  > expected (i.e.  an app can use both interfaces at once).
> 
>  A naive question.  OSMesa does off-screen *software-only* rendering,
>  right?

Right.

-Brian

Re: [Mesa3d-dev] Anyone know why: Mesa 3.3 defaults to 24bit Zbuffer?

[<ant...@wm...>]

On Tue, 29 Aug 2000, Daniel Vogel wrote:

> On Mon, Aug 28, 2000 at 02:35:49PM -0600, Brian Paul wrote:
> >
> > > yes, it works fine, but what I wonder is: how does fxMesa respond when
> > > asked to set a 24bit zbuffer on a card that doesn't support it!?
> > 
> > I think it's only reporting 24bits/z but really using 16.
> 
> Why that?

I would assume that either the fxMesa ignores the 24 and uses 16, or
fails at 24, goes down to 16, and doesn't report 16?
But I think Brian should answer that, not me :)


BTW, good job on all your guys' conversions/ports over there are Loki! (at
least the ones' i have tried out)

> -- 
> Daniel Vogel
> Programmer
> Loki Entertainment Software
> 

Re: [Mesa3d-dev] Call for more general hardware API

[Marcelo E. M. <mar...@bi...>]

>> Brian Paul <br...@va...> writes:

 > By popular demand I added the OSMesa feature into XFree86/DRI
 > 4.0.1.  [...]  They share common dispatch code and coexist as
 > expected (i.e.  an app can use both interfaces at once).

 A naive question.  OSMesa does off-screen *software-only* rendering,
 right?

                                Marcelo

Re: [Mesa3d-dev] Call for more general hardware API

[Brian P. <br...@va...>]

Howard wrote:
> 
> Brian Paul wrote:
> 
> > The DRI architecture was originally targetted for Linux but was designed
> > with portability in mind.  It's been ported to FreeBSD now, for example.
> > Porting to other flavors of Unix should be feasible.
> >
> > One thing people tend to overlook when talking about adding hardware
> > 3D acceleration to a system is window system integration.  It's
> > actually rather complicated.  Since the DRI was designed for XFree86,
> > if you want hardware 3D for another window system you'll likely have
> > to start from scratch.
> >
> > A short-cut to hardware 3D is to run without a window system
> > (like the original Glide for Voodoo1/2 did).  But then you're limited
> > to full-screen apps and need some sort of replacement for GLX (thus
> > requiring customized application code).
> >
> 
> Speaking of this, what is the status of the OSMesalib that you broke out a couple of
> months ago? That is a major portability issue to us. If we are able to bind that to the
> XFree86 libGL, and other board specific libGL's. we get the best of both worlds. Has
> that been tar'd up anywhere or is it only in CVS?

For those of you who haven't heard of this...

The libGL included with XFree86/DRI is different from the libGL you have
been using from the normal Mesa distribution.  It's strictly a GLX-based
libGL whereas the Mesa libGL can also have built-in interfaces of OSMesa,
fxMesa, GGIMesa, SVGAMesa, etc.

By popular demand I added the OSMesa feature into XFree86/DRI 4.0.1.
It's a separate library named libOSMesa.so.  An application can link
with both -lGL and -lOSMesa and have both the GLX and OSMesa programming
APIs.  They share common dispatch code and coexist as expected (i.e.
an app can use both interfaces at once).

The outstanding problem is that one needs separate versions of the
application to work with both stand-alone Mesa and XFree86/DRI since
the later needs to be linked with the special libOSMesa.so library.  I
suppose dlopen() and dlsym() could be used to hide this problem but
that's not ideal.

Comments are welcome.

libOSMesa.so is in XFree86 4.0.1 and the current DRI and XFree86 CVS
trees.

-Brian

Re: [Mesa3d-dev] Call for more general hardware API

[Andreas E. <eh...@ly...>]

On Thu, Aug 31, 2000 at 07:16:51AM -0600, Brian Paul wrote:
> One thing people tend to overlook when talking about adding hardware
> 3D acceleration to a system is window system integration.  It's
> actually rather complicated.  Since the DRI was designed for XFree86,
> if you want hardware 3D for another window system you'll likely have
> to start from scratch.

Documentation and/or source code could be missing as well.
Is it possible as a mere mortal[1] to get information about 2d/3d driver
writing in windows 95/98/NT for example?
Someone would need to be motivated enough to actually write the support
as well.

regards
Andreas Ehliar

Re: [Mesa3d-dev] Call for more general hardware API

[Howard <ho...@me...>]

Brian Paul wrote:

> The DRI architecture was originally targetted for Linux but was designed
> with portability in mind.  It's been ported to FreeBSD now, for example.
> Porting to other flavors of Unix should be feasible.
>
> One thing people tend to overlook when talking about adding hardware
> 3D acceleration to a system is window system integration.  It's
> actually rather complicated.  Since the DRI was designed for XFree86,
> if you want hardware 3D for another window system you'll likely have
> to start from scratch.
>
> A short-cut to hardware 3D is to run without a window system
> (like the original Glide for Voodoo1/2 did).  But then you're limited
> to full-screen apps and need some sort of replacement for GLX (thus
> requiring customized application code).
>

Speaking of this, what is the status of the OSMesalib that you broke out a
couple of months ago? That is a major portability issue to us. If we are able to
bind that to the XFree86 libGL, and other board specific libGL's. we get the
best of both worlds. Has that been tar'd up anywhere or is it only in CVS?
Thanks,
--
Howard Luby     ho...@me...,  Ph:(248)540-2251, Fax:(248)540-3138
Mediascape Corporation                         http://www.mediascape.com

Re: [Mesa3d-dev] Call for more general hardware API

[Brian P. <br...@va...>]

Philip Brown wrote:
> 
> Howdy folks,
> 
> Probably noone except Brian here even vaguely knows my name. :-)
> But I'm the guy who originally gave the GLX hack code to Brian, because
> I thought it would be a really cool thing if Mesa broadened its horizons.
> 
> I'd like to do the same thing again. But this time, for hardware support.
> 
> I see a whole bunch of hardware acceleration support in Mesa right now...
> And 99% of it is only for Linux.
> 
> I think that's pretty far from the original goals of Mesa, which was to be
> a more crossplatform project.
> 
> I haven't dug deep down into the code. So I dont know the grungy details
> on the "Glide" stuff, and the Xfree86 "DRI" stuff. But I know its pretty
> much all linux-only

Not especially.  Just the DRI kernel modules.  More of the DRI is
XFree86-centric, rather than Linux-centric.


> I DO know that when you get down to the very basic level of things,
> there are only a few basic operations you can do with a piece of hardware.
> Read/Write registers. Map memory.
> 
> So it boggles my mind to see all this Linux-only stuff.
> It would seem to me that there isn't a basic API that encapsulates that
> level. Something that just sticks to the core hardware neccessities, to
> keep porting easy.
> Because if there were, it would be almost trivial to port Mesa hardware
> acceleration across platforms, and it would have been used already.
> 
> If there is one, and I missed it, please point me in the right direction.
> 
> If there isn't one: let's make one!
> 
> And then I'll write a solaris driver or two to match it.

The DRI architecture was originally targetted for Linux but was designed
with portability in mind.  It's been ported to FreeBSD now, for example.
Porting to other flavors of Unix should be feasible.

One thing people tend to overlook when talking about adding hardware
3D acceleration to a system is window system integration.  It's
actually rather complicated.  Since the DRI was designed for XFree86,
if you want hardware 3D for another window system you'll likely have
to start from scratch.

A short-cut to hardware 3D is to run without a window system
(like the original Glide for Voodoo1/2 did).  But then you're limited
to full-screen apps and need some sort of replacement for GLX (thus
requiring customized application code).

-Brian

[Mesa3d-dev] Call for more general hardware API

[<ph...@bo...>]

Howdy folks,

Probably noone except Brian here even vaguely knows my name. :-)
But I'm the guy who originally gave the GLX hack code to Brian, because
I thought it would be a really cool thing if Mesa broadened its horizons.

I'd like to do the same thing again. But this time, for hardware support.

I see a whole bunch of hardware acceleration support in Mesa right now...
And 99% of it is only for Linux.

I think that's pretty far from the original goals of Mesa, which was to be
a more crossplatform project.

I haven't dug deep down into the code. So I dont know the grungy details
on the "Glide" stuff, and the Xfree86 "DRI" stuff. But I know its pretty
much all linux-only

I DO know that when you get down to the very basic level of things,
there are only a few basic operations you can do with a piece of hardware.
Read/Write registers. Map memory.

So it boggles my mind to see all this Linux-only stuff.
It would seem to me that there isn't a basic API that encapsulates that
level. Something that just sticks to the core hardware neccessities, to
keep porting easy.
Because if there were, it would be almost trivial to port Mesa hardware
acceleration across platforms, and it would have been used already.

If there is one, and I missed it, please point me in the right direction.

If there isn't one: let's make one!

And then I'll write a solaris driver or two to match it.

Re: [Mesa3d-dev] Intro & question

[Paul G. <pga...@te...>]

On 29 Aug 2000, at 9:21, the Illustrious Brian Paul wrote:

> The include/GL/mesa_wgl.h file was accidently omitted from the
> 3.2.1 and 3.3 releases.  It'll be there in the next release.  I'm
> attaching a copy of it.
> 
> I have no idea if it actually works.  I don't maintain the
> Windows or mingw32 stuff and few people seem interested in it
> anymore.

	Thanks for that input.  I know there are quite a few people who 
have downloaded and used the mesa3d libraries from my ongoing 
activity in the mingw development community and as the mingw 
compiler matures, I am seeing more people downloading and 
installing of the mesa3d libs.  I am just not sure which version 
they are using outside of the fact that it is typically not the 
development version but one of the earlier stable releases.

	Whether or not the amount of people using it is sufficient to 
warrant ongoing maintenance of the mingw port still remains to 
be seen, at least for me.  I know there is at least one other 
person besides myself who is interested in the functional 
operation of the mesa3d mingw port.

	Of course, there is always the possibility that no one has had 
any problems with the stable mingw32 builds...maybe a poll of 
some sort could help with this determination...?

	Peace,

		Paul G.

> 
> -Brian




Nothing real can be threatened.
    Nothing unreal exists.

Re: [Mesa3d-dev] Intro & question

[Paul G. <pga...@te...>]

On 29 Aug 2000, at 9:21, the Illustrious Brian Paul wrote:

> Paul Garceau wrote:
> > 

(skip)

> >         Question:
> > 
> >                 In the compile line, it is noted that the
> >                 following switches
> > have been set:
> > 
> >          -DWIN32 -D__WIN32__ -D_WINDOWS
> > 
> >         I am assuming this is an attempt to differentiate
> >         between
> > various Windows compilers.
> > 
> >         Is this an accurate assumption?
> 
> 
> The include/GL/mesa_wgl.h file was accidently omitted from the
> 3.2.1 and 3.3 releases.  It'll be there in the next release.  I'm
> attaching a copy of it.
> 
> I have no idea if it actually works.  I don't maintain the
> Windows or mingw32 stuff and few people seem interested in it
> anymore.

	Thanks, Brian.

	Peace,

		Paul G.
> 
> -Brian




Nothing real can be threatened.
    Nothing unreal exists.

Re: [Mesa3d-dev] Anyone know why: Mesa 3.3 defaults to 24bit Zbuffer?

[Daniel V. <vo...@lo...>]

On Mon, Aug 28, 2000 at 02:35:49PM -0600, Brian Paul wrote:
>
> > yes, it works fine, but what I wonder is: how does fxMesa respond when
> > asked to set a 24bit zbuffer on a card that doesn't support it!?
> 
> I think it's only reporting 24bits/z but really using 16.

Why that?

-- 
Daniel Vogel
Programmer
Loki Entertainment Software

Re: [Mesa3d-dev] Intro & question

[Brian P. <br...@va...>]

Paul Garceau wrote:
> 
> Hi folks,
> 
>         Some time ago I wrote a .bat file (mingw32) in order to allow a
> port of Mesa3d for the mingw (native gnu windows) compiler.
> 
>         It has recently come to my attention that the build did not
> have (3.3 latest release) a header file called mesa_wgl.h
> available in the include folder/directory.
> 
>         I researched it a bit and noticed that it would probably be
> fine if I simply copied the file from a stable release version.
> 
>         So, after copying the file from the cvs repository and moving
> it into the 3.3 include/gl directory, I went ahead and ran the
> .bat program again (in lieu of trying to write a whole new make
> sequence).
> 
>         Remembering what I read in the archives (dev) about mesa_wgl.h,
> there was no mention of what exactly had happened to mesa_wgl.h
> outside of Brians' last modifications dated back in May which
> stated:
> 
>         "moved a lot of Window-isms out of gl.h into other files".
> Apparently a few of those Window-isms were moved into
> mesa_wgl.h.
> 
>         Since then I have seen no further revisions in the repository
> for mesa_wgl.h.
> 
>         Currently, the native mingw32 [dev] build (not pgi-mingw32) is
> broken.
> 
>         Question:
> 
>                 In the compile line, it is noted that the following switches
> have been set:
> 
>          -DWIN32 -D__WIN32__ -D_WINDOWS
> 
>         I am assuming this is an attempt to differentiate between
> various Windows compilers.
> 
>         Is this an accurate assumption?


The include/GL/mesa_wgl.h file was accidently omitted from the 3.2.1
and 3.3 releases.  It'll be there in the next release.  I'm attaching
a copy of it.

I have no idea if it actually works.  I don't maintain the Windows
or mingw32 stuff and few people seem interested in it anymore.

-Brian

Re: [Mesa3d-dev] Anyone know why: Mesa 3.3 defaults to 24bit Zbuffer?

[Brian P. <br...@va...>]

ant...@wm... wrote:
> 
> > I took at look at this but didn't make any progress.  I'm not sure
> > how Q3 is choosing its visual and determining the bits per buffer.
> 
> you can force it to use a 24bit depth with:
> ./quake3 +set r_depthbits 24
> 
> > The game is working OK, right?
> 
> yes, it works fine, but what I wonder is: how does fxMesa respond when
> asked to set a 24bit zbuffer on a card that doesn't support it!?

I think it's only reporting 24bits/z but really using 16.


> (Voodoo2)
> It should not run, therefore somewhere in there something needs fixing..
> 
> > I won't be able to look into this anymore until next week.
> 
> no, worries, i just hope it's not a bug in 3.3

-Brian

Re: [Mesa3d-dev] Anyone know why: Mesa 3.3 defaults to 24bit Zbuffer?

[<ant...@wm...>]

> I took at look at this but didn't make any progress.  I'm not sure
> how Q3 is choosing its visual and determining the bits per buffer.

you can force it to use a 24bit depth with:
./quake3 +set r_depthbits 24 

> The game is working OK, right?

yes, it works fine, but what I wonder is: how does fxMesa respond when
asked to set a 24bit zbuffer on a card that doesn't support it!? (Voodoo2)
It should not run, therefore somewhere in there something needs fixing..

> I won't be able to look into this anymore until next week.

no, worries, i just hope it's not a bug in 3.3 

[Mesa3d-dev] Intro & question

[Paul G. <pga...@te...>]

Hi folks,

	Some time ago I wrote a .bat file (mingw32) in order to allow a 
port of Mesa3d for the mingw (native gnu windows) compiler.

	It has recently come to my attention that the build did not 
have (3.3 latest release) a header file called mesa_wgl.h 
available in the include folder/directory.

	I researched it a bit and noticed that it would probably be 
fine if I simply copied the file from a stable release version.

	So, after copying the file from the cvs repository and moving 
it into the 3.3 include/gl directory, I went ahead and ran the 
.bat program again (in lieu of trying to write a whole new make 
sequence).

	Remembering what I read in the archives (dev) about mesa_wgl.h, 
there was no mention of what exactly had happened to mesa_wgl.h 
outside of Brians' last modifications dated back in May which 
stated:

	"moved a lot of Window-isms out of gl.h into other files".  
Apparently a few of those Window-isms were moved into 
mesa_wgl.h.

	Since then I have seen no further revisions in the repository 
for mesa_wgl.h.

	Currently, the native mingw32 [dev] build (not pgi-mingw32) is 
broken.

	Question:

		In the compile line, it is noted that the following switches 
have been set:

	 -DWIN32 -D__WIN32__ -D_WINDOWS

	I am assuming this is an attempt to differentiate between 
various Windows compilers.

	Is this an accurate assumption?

	Thank you,

		Paul G.


Nothing real can be threatened.
    Nothing unreal exists.

Re: [Mesa3d-dev] Anyone know why: Mesa 3.3 defaults to 24bit Zbuffer?

[Brian P. <br...@va...>]

ant...@wm... wrote:
> 
> > Mesa 3.3 was changed to allow arbitrary Z buffer depths at runtime,
> > instead of being a compile-time option.  Looks like I missed
> > something in the tdfx driver code.  Could you try this patch
> > to Mesa-3.3/src/FX/fxapi.c?
> >
> > diff -r1.21 fxapi.c
> > 946c946
> > <    fxMesa->haveZBuffer=depthSize ? 1 : 0;
> > ---
> > >    fxMesa->haveZBuffer=depthSize ? 16 : 0;
> >
> >
> > -Brian
> >
> 
> Ok, letme know if there is something that you want me to try....
> because the reason i was confused is that the Voodoo2 cards don't support
> more than 16bit deep zbuffers/depthbuffers, at least from what i know ...

I took at look at this but didn't make any progress.  I'm not sure
how Q3 is choosing its visual and determining the bits per buffer.

The game is working OK, right?

I won't be able to look into this anymore until next week.

-Brian

Re: [Mesa3d-dev] Anyone know why: Mesa 3.3 defaults to 24bit Zbuffer?

[<ant...@wm...>]

> Mesa 3.3 was changed to allow arbitrary Z buffer depths at runtime,
> instead of being a compile-time option.  Looks like I missed
> something in the tdfx driver code.  Could you try this patch
> to Mesa-3.3/src/FX/fxapi.c?
> 
> diff -r1.21 fxapi.c
> 946c946
> <    fxMesa->haveZBuffer=depthSize ? 1 : 0;
> ---
> >    fxMesa->haveZBuffer=depthSize ? 16 : 0;
> 
> 
> -Brian
> 


Ok, letme know if there is something that you want me to try....
because the reason i was confused is that the Voodoo2 cards don't support
more than 16bit deep zbuffers/depthbuffers, at least from what i know ...

Re: [Mesa3d-dev] undefined symbols

[Brian P. <br...@va...>]

Alex Romosan wrote:
> 
> looks like you forgot to add convolve.[ch] to libGL sources so if you
> try to link against this library you get undefined symbols. the
> following patch fixes it for me:
> 
> diff -u -r1.17 Makefile.am
> --- src/Makefile.am     2000/04/07 16:28:38     1.17
> +++ src/Makefile.am     2000/08/21 18:28:59
> @@ -43,6 +43,8 @@
>         config.h \
>         context.c \
>         context.h \
> +       convolve.c \
> +       convolve.h \
>         copy_tmp.h \
>         copypix.c \
>         copypix.h \
> 
> --alex--

Thanks.  Fixed.

-Brian

[Mesa3d-dev] undefined symbols

[Alex R. <ro...@ad...>]

looks like you forgot to add convolve.[ch] to libGL sources so if you
try to link against this library you get undefined symbols. the
following patch fixes it for me:

diff -u -r1.17 Makefile.am
--- src/Makefile.am     2000/04/07 16:28:38     1.17
+++ src/Makefile.am     2000/08/21 18:28:59
@@ -43,6 +43,8 @@
        config.h \
        context.c \
        context.h \
+       convolve.c \
+       convolve.h \
        copy_tmp.h \
        copypix.c \
        copypix.h \

--alex--

-- 
| I believe the moment is at hand when, by a paranoiac and active |
|  advance of the mind, it will be possible (simultaneously with  |
|  automatism and other passive states) to systematize confusion  |
|  and thus to help to discredit completely the world of reality. |

Re: [Mesa3d-dev] Anyone know why: Mesa 3.3 defaults to 24bit Zbuffer?

[Brian P. <br...@va...>]

Brian Paul wrote:
> 
> ant...@wm... wrote:
> >
> > Like I posted a few days back, all the original libMesa's with Q3test
> > Q3Demo and Q3A (as well as Mesa 3.2.1) report 16bit zbuffer inside the
> > game, but 3.3 says 24bit ... and I thought the Voodoo2 has only 16bit
> > zbuffer. Is this a bug or something that I am unaware of?
> >
> > I would appreciate some quick feedback from those who know the insides of
> > Mesa 3.3 real well ...
> 
> Mesa 3.3 was changed to allow arbitrary Z buffer depths at runtime,
> instead of being a compile-time option.  Looks like I missed
> something in the tdfx driver code.  Could you try this patch
> to Mesa-3.3/src/FX/fxapi.c?
> 
> diff -r1.21 fxapi.c
> 946c946
> <    fxMesa->haveZBuffer=depthSize ? 1 : 0;
> ---
> >    fxMesa->haveZBuffer=depthSize ? 16 : 0;
> 

D'oh!  On second look, that's probably not the solution.  I can't test
this here at work.  I'll try to do so tonight on my home system.

-Brian

Re: [Mesa3d-dev] Anyone know why: Mesa 3.3 defaults to 24bit Zbuffer?

[Brian P. <br...@va...>]

ant...@wm... wrote:
> 
> Like I posted a few days back, all the original libMesa's with Q3test
> Q3Demo and Q3A (as well as Mesa 3.2.1) report 16bit zbuffer inside the
> game, but 3.3 says 24bit ... and I thought the Voodoo2 has only 16bit
> zbuffer. Is this a bug or something that I am unaware of?
> 
> I would appreciate some quick feedback from those who know the insides of
> Mesa 3.3 real well ...

Mesa 3.3 was changed to allow arbitrary Z buffer depths at runtime,
instead of being a compile-time option.  Looks like I missed
something in the tdfx driver code.  Could you try this patch
to Mesa-3.3/src/FX/fxapi.c?

diff -r1.21 fxapi.c
946c946
<    fxMesa->haveZBuffer=depthSize ? 1 : 0;
---
>    fxMesa->haveZBuffer=depthSize ? 16 : 0;


-Brian

[Mesa3d-dev] Anyone know why: Mesa 3.3 defaults to 24bit Zbuffer?

[<ant...@wm...>]

Like I posted a few days back, all the original libMesa's with Q3test
Q3Demo and Q3A (as well as Mesa 3.2.1) report 16bit zbuffer inside the
game, but 3.3 says 24bit ... and I thought the Voodoo2 has only 16bit
zbuffer. Is this a bug or something that I am unaware of?

I would appreciate some quick feedback from those who know the insides of
Mesa 3.3 real well ...

thanks in advance