mesa3d-dev

Re: [Mesa3d-dev] Bug in glDrawRangeElements(..)

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

Scott McMillan wrote:
> 
> I am having trouble with glDrawRangeElements (again) with version
> 3.5.  The attached test program renders three GL_POLYGONs.  By
> pressing 'v' it cycles through using glVertex3f (the initial mode),
> glDrawRangeElements, and glDrawElements.  There is a problem with
> the glDrawRangeElements.
> 
> This leads me to my second question.  glDrawRangeElements was
> either broken or did not exist (I cannot remember which) in
> version 3.1 or earlier.  I used to use MESA_MAJOR_VERSION and
> MESA_MINOR_VERSION to determine what I was working with.  These
> seem to be gone now, and I was wondering if this was temporary or
> if I am supposed to be using one of the many replacements:
> XMESA_MAJOR_VERSION, OSMESA_MAJOR_VERSION, etc...

I think you should call glGetString(GL_VERSION) and examine the
Mesa version number it returns.  Afterall, you want to know the
version at runtime, not compile time, right?

The MESA_MINOR/MAJOR_VERSION tokens really weren't appropriate,
so I removed them a while back.

-Brian

Re: [Mesa3d-dev] Artifact in Texture Mapped Quad

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

Allen Barnett wrote:
> 
> Hi,
> 
> I see a slight artifact in the attached snapshot (the brighter, broken,
> vertical yellow line above the left edge of the "O"). The image was
> generated from two overlapping, texture-mapped quads drawn in the same
> plane (z=0). The blue parts are opaque (r=0.,g=0,b=.5,a=1), while the
> yellowish parts have alpha = .3 (1,1,0,.3). Blending and the depth test
> are turned on. If I turn off the depth test, the artifact goes away.
> 
> If you could give me some idea where in the code (software Mesa 3.5.1
> under X) the pixels are computed for a depth-tested, alpha-blended,
> texture-mapped quad, I'll be glad to track this down a little further.
> It's probably unavoidable round-off somewhere, but I'd like to
> understand what it's the round-off of!
> 
> (I'd don't see the artifact in DRI/Mesa 3.4.2 in either direct or
> indirect rendering modes, though.)

You may have just been getting lucky with 3.4.2.  There are minor
differences in the triangle rasterizer in 3.5.

Are you rendering the quads with any rotation (other than around Z)?
If so, you should be aware that rendering coplanar polygons is always
going to be a problem because of "z fighting".  That's when minor
differences in rasterization basically result in random Z priority of
the overlapping quads.

Solutions include polygon offset, stencilling, or disable Z testing/writing
if you really don't need it.

Your sample image looks funny though in that the bright yellow pixels
don't appear to be in the actual overlap area.  Do you have a test
program?

-Brian

Re: [Mesa3d-dev] color matrix manip bug

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

Stephane Conversy wrote:
> 
> Keith Whitwell wrote:
> >
> > Stephane Conversy wrote:
> > >
> > > Hi.
> > >
> > > mesa 3.5, in matrix.c:78, when manipulating
> > > the color matrix, shouldn't flags be set to:
> > >
> > > flags |= _NEW_COLOR_MATRIX | _NEW_PIXEL;
> > >
> > > instead of:
> > >
> > > flags |= _NEW_COLOR_MATRIX;
> > >
> > > doing so fixes a bug when copying into a texture
> > > (ie mesa_update_state is called)...
> >
> > It sounds like the opposite is true: there is a place where we are checking
> > for _NEW_PIXEL where we should (also?) be checking for _NEW_COLOR_MATRIX.  It
> > is the color matrix that is being changed at this point, so that is the bit
> > which is set.
> 
> Ok, if I remember well, it's in _mesa_CopyTexImage2D
> at teximage.c:1874:
> 
>    if (ctx->NewState & _NEW_PIXEL)
>       _mesa_update_state(ctx);
> 
> since _NEW_PIXEL was not set, _mesa_update_state is not called
> after a color matrix change.

I think in teximage.c we should simply be checking for _IMAGE_NEW_TRANSFER_STATE
as it's defined to be (_NEW_PIXEL | _NEW_COLOR_MATRIX).

I'll fix this.  Thanks for the bug report.

-Brian

Re: [Mesa3d-dev] Re: bug when applying scale and bias

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

Stephane Conversy wrote:
> 
> ok, I changed
> 
> GLfloat (*rgba)[4] = (GLfloat (*)[4]) tmpImage + row * width * 4;
> 
> to
> 
> GLfloat (*rgba)[4] = (GLfloat (*)[4]) (tmpImage + row * width * 4);
> 
> (which removes warnings compared to the previous version)
> 
> at both line 198 and 230, and it seems to work now.

Thanks for the info.  I'm checking in the fix now.

-Brian

Re: [Mesa3d-dev] CVS Build Problem

[Allen B. <ba...@lo...>]

Hi,

I was trying to build Mesa with profiling enabled via './configure
--enable-profile'. This seemed to build all the source code and the
sub-libraries (.la's) with '-pg' OK, however, the last big libtool link
of libGL.so didn't have the '-pg' argument and I didn't get a gmon.out
file when I ran my code against it. There are probably a lot of things
which went wrong that I don't understand (like: can you even have a
profiling shared object?) (or perhaps I didn't compile my code with
-pg).

I eventually got what I wanted with 'make -f Makefile.X11 linux-prof'.
Though, this created a static library. Is this what --enable-profile
should do, too?

Thanks,
Allen

[Mesa3d-dev] Re: bug when applying scale and bias

[Stephane C. <Ste...@em...>]

ok, I changed 

GLfloat (*rgba)[4] = (GLfloat (*)[4]) tmpImage + row * width * 4;

to

GLfloat (*rgba)[4] = (GLfloat (*)[4]) (tmpImage + row * width * 4);

(which removes warnings compared to the previous version)

at both line 198 and 230, and it seems to work now.



Stephane Conversy wrote:
> 
> Hello.
> 
> I tried to use glCopyPixels with some scale and bias,
> and I get one-pixel width "stripes" instead of plain rectangles,
> as if line adressing in a pixmap was broken.
> 
> I changed in swrast/s_copypix.c:198
> 
> GLfloat (*rgba)[4] = (GLfloat (*)[4]) tmpImage + row * width * 4;
> 
> for:
> 
> GLfloat (*rgba)[4] = tmpImage + row * width * 4;
> 
> and the bug is fixed. There is a similar statement at line 230,
> I suspect it's buggy as well since convImage is in the same
> format than tmpImage.


--
Stephane Conversy
Ecole des Mines de Nantes

[Mesa3d-dev] bug when applying scale and bias

[Stephane C. <Ste...@em...>]

Hello.

I tried to use glCopyPixels with some scale and bias,
and I get one-pixel width "stripes" instead of plain rectangles,
as if line adressing in a pixmap was broken.

I changed in swrast/s_copypix.c:198

GLfloat (*rgba)[4] = (GLfloat (*)[4]) tmpImage + row * width * 4;

for:

GLfloat (*rgba)[4] = tmpImage + row * width * 4;

and the bug is fixed. There is a similar statement at line 230,
I suspect it's buggy as well since convImage is in the same
format than tmpImage.

About bug policy: each time I get a bug, I try to find at least
a workaround (at least to be sure it's a bug), if not a fix.
Do I have to submit an entry in the bug database in this case ?

Regards,


--
Stephane Conversy
Ecole des Mines de Nantes

Re: [Mesa3d-dev] Bug in glDrawRangeElements(..)

[Keith W. <ke...@va...>]

Scott McMillan wrote:
> 
> I am having trouble with glDrawRangeElements (again) with version
> 3.5.  The attached test program renders three GL_POLYGONs.  By
> pressing 'v' it cycles through using glVertex3f (the initial mode),
> glDrawRangeElements, and glDrawElements.  There is a problem with
> the glDrawRangeElements.
> 
> This leads me to my second question.  glDrawRangeElements was
> either broken or did not exist (I cannot remember which) in
> version 3.1 or earlier.  I used to use MESA_MAJOR_VERSION and
> MESA_MINOR_VERSION to determine what I was working with.  These
> seem to be gone now, and I was wondering if this was temporary or
> if I am supposed to be using one of the many replacements:
> XMESA_MAJOR_VERSION, OSMESA_MAJOR_VERSION, etc...
> 

I'm on this one too...  I've got a largish lighting change that's clogging the
works ahead of these bugs, I may have to put it to one side.

Keith

[Mesa3d-dev] Bug in glDrawRangeElements(..)

[Scott M. <mcm...@ca...>]

I am having trouble with glDrawRangeElements (again) with version
3.5.  The attached test program renders three GL_POLYGONs.  By
pressing 'v' it cycles through using glVertex3f (the initial mode),
glDrawRangeElements, and glDrawElements.  There is a problem with
the glDrawRangeElements.

This leads me to my second question.  glDrawRangeElements was
either broken or did not exist (I cannot remember which) in
version 3.1 or earlier.  I used to use MESA_MAJOR_VERSION and
MESA_MINOR_VERSION to determine what I was working with.  These
seem to be gone now, and I was wondering if this was temporary or
if I am supposed to be using one of the many replacements:
XMESA_MAJOR_VERSION, OSMESA_MAJOR_VERSION, etc...

-- 
Scott McMillan                        mailto:mcm...@ca...
Cambridge Research Associates         http://www.cambridge.com
1430 Spring Hill Road, Ste. 200       Voice: (703) 790-0505 x7235
McLean, VA 22102                      Fax:   (703) 790-0370

[Mesa3d-dev] Artifact in Texture Mapped Quad

[Allen B. <ba...@lo...>]

Hi,

I see a slight artifact in the attached snapshot (the brighter, broken,
vertical yellow line above the left edge of the "O"). The image was
generated from two overlapping, texture-mapped quads drawn in the same
plane (z=0). The blue parts are opaque (r=0.,g=0,b=.5,a=1), while the
yellowish parts have alpha = .3 (1,1,0,.3). Blending and the depth test
are turned on. If I turn off the depth test, the artifact goes away. 

If you could give me some idea where in the code (software Mesa 3.5.1
under X) the pixels are computed for a depth-tested, alpha-blended,
texture-mapped quad, I'll be glad to track this down a little further.
It's probably unavoidable round-off somewhere, but I'd like to
understand what it's the round-off of!

(I'd don't see the artifact in DRI/Mesa 3.4.2 in either direct or
indirect rendering modes, though.)

Thanks,
Allen

Re: [Mesa3d-dev] codegen again

[Jeff E. <je...@in...>]

On Wed, Jul 11, 2001 at 12:57:52AM -0400, Josh Vanderhoof wrote:
> Allen Akin <ak...@po...> writes:
> 
> > Also, my personal bias would be to use an input representation that's
> > more abstract than MIPS-like virtual-machine instructions.  That makes
> > it easier to optimize the output code if you like, and needn't have a
> > huge impact on compilation time if optimization is turned off.  I
> > acknowledge this can become a tarpit, though.
> 
> I'm surprised they went for only 6 registers.  Most virtual machines
> go the other way and give you a huge number of registers.  It seems
> like it would be hard to get good performance with such a small number
> of registers.  (Although it would be possible to create a pentium pro
> style register renamer to at least get some use of the extra registers
> available on non x86 processors.)

In fact, I suspect the number 6 was chosen so that a naive code
generator could still work for x86.

Jeff

Re: [Mesa3d-dev] color matrix manip bug

[Stephane C. <Ste...@em...>]

Keith Whitwell wrote:
> 
> Stephane Conversy wrote:
> >
> > Hi.
> >
> > mesa 3.5, in matrix.c:78, when manipulating
> > the color matrix, shouldn't flags be set to:
> >
> > flags |= _NEW_COLOR_MATRIX | _NEW_PIXEL;
> >
> > instead of:
> >
> > flags |= _NEW_COLOR_MATRIX;
> >
> > doing so fixes a bug when copying into a texture
> > (ie mesa_update_state is called)...
> 
> It sounds like the opposite is true: there is a place where we are checking
> for _NEW_PIXEL where we should (also?) be checking for _NEW_COLOR_MATRIX.  It
> is the color matrix that is being changed at this point, so that is the bit
> which is set.


Ok, if I remember well, it's in _mesa_CopyTexImage2D
at teximage.c:1874:

   if (ctx->NewState & _NEW_PIXEL)
      _mesa_update_state(ctx);

since _NEW_PIXEL was not set, _mesa_update_state is not called
after a color matrix change.


> 
> Keith

--
Stephane Conversy
Ecole des Mines de Nantes

Re: [Mesa3d-dev] color matrix manip bug

[Keith W. <ke...@va...>]

Stephane Conversy wrote:
> 
> Hi.
> 
> mesa 3.5, in matrix.c:78, when manipulating
> the color matrix, shouldn't flags be set to:
> 
> flags |= _NEW_COLOR_MATRIX | _NEW_PIXEL;
> 
> instead of:
> 
> flags |= _NEW_COLOR_MATRIX;
> 
> doing so fixes a bug when copying into a texture
> (ie mesa_update_state is called)...

It sounds like the opposite is true: there is a place where we are checking
for _NEW_PIXEL where we should (also?) be checking for _NEW_COLOR_MATRIX.  It
is the color matrix that is being changed at this point, so that is the bit
which is set.

Keith

[Mesa3d-dev] color matrix manip bug

[Stephane C. <Ste...@em...>]

Hi.

mesa 3.5, in matrix.c:78, when manipulating
the color matrix, shouldn't flags be set to:

flags |= _NEW_COLOR_MATRIX | _NEW_PIXEL;

instead of:

flags |= _NEW_COLOR_MATRIX;

doing so fixes a bug when copying into a texture
(ie mesa_update_state is called)...

	stef


--
Stephane Conversy
Ecole des Mines de Nantes

Re: [Mesa3d-dev] codegen again

[Josh V. <ho...@na...>]

Allen Akin <ak...@po...> writes:

> Also, my personal bias would be to use an input representation that's
> more abstract than MIPS-like virtual-machine instructions.  That makes
> it easier to optimize the output code if you like, and needn't have a
> huge impact on compilation time if optimization is turned off.  I
> acknowledge this can become a tarpit, though.

I'm surprised they went for only 6 registers.  Most virtual machines
go the other way and give you a huge number of registers.  It seems
like it would be hard to get good performance with such a small number
of registers.  (Although it would be possible to create a pentium pro
style register renamer to at least get some use of the extra registers
available on non x86 processors.)

Even with more registers, a generic assembly language is still at a
large disadvantage for optimization just because of the amount of
information missing vs. a higher level language.  I've read (in the
GCC IA-64 summit minutes *) that that even gcc's RTL representation
throws away too much information for some optimizations, so they are
going to make some of their latest optimizations work on trees instead
of RTL.

Josh

* http://linuxia64.org/gcc_summit.2001.06.06.html

Re: [Mesa3d-dev] codegen again

[Allen A. <ak...@po...>]

On Tue, Jul 10, 2001 at 08:40:03AM -0600, Keith Whitwell wrote:
| For those interested, take a look at the GNU lightning project.

There's some good work there.

I'm a little worried by the lack of an instruction scheduler.  That
may not be a big deal for lightning's intended purpose, but I'd guess
it would be more important in some applications for Mesa.

Also, my personal bias would be to use an input representation that's
more abstract than MIPS-like virtual-machine instructions.  That makes
it easier to optimize the output code if you like, and needn't have a
huge impact on compilation time if optimization is turned off.  I
acknowledge this can become a tarpit, though.

Allen

[Mesa3d-dev] codegen again

[Keith W. <ke...@va...>]

For those interested, take a look at the GNU lightning project.  This looks
like a viable approach to codegen for mesa (using an abstracted machine code
and fast translation to the underlying architecture).

There's a fair bit of information in the info files included in the tarball
download.

http://www.gnu.org/software/lightning/lightning.html

On a quick look, a fast, architecture-specific peephole optimizer looks like a
viable addition...

Keith

Re: [Mesa3d-dev] CVS Build Problem

[Sven M. H. <pe...@gm...>]

On Mon, Jul 09, 2001 at 08:10:19AM -0400, Allen Barnett wrote:
> OK :-) Here is an even more minor issue: 'make distclean' dies like
> this:

I know of this issue. I have tried to fix it. I have no clue how to fix it.
If anyone does, please tell me.

Look at this (where --> means "depends on"):

          Makefile-->conf.h<-----.
              \                   \
               `-->matypes.h-->gen_matypes

The fun starts in a distclean because it deletes conf.h pretty early.
Then Makefile gets rebuilt, because that rule is always checked, regardless of
the actual target. Makefile depends on gen_matypes, so that gets rebuilt too.
Unfortunately conf.h is _gone_, so that build fails. Ugh.


> If you fix this, though, please don't revert to requiring me to remmber
> to rebuild matypes.h by hand :-)

No way, that's defying the whole purpose of make. :)


Regards,
Sven

-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]

Re: [Mesa3d-dev] Display List Problem

[Keith W. <ke...@va...>]

Allen Barnett wrote:
> 
> Hi,
> 
> Attached is a short program which demonstrates a problem with display
> lists in the current CVS version of Mesa. It appears that if a triangle
> strip with exactly 216 vertices is compiled into a display list, an
> error occurs in the processing of the display list which prevents the
> execution of subsequent commands in the display list. From looking at
> the code, it's related to the size of the cassette data structure. In
> this case, the END element of a 216 vertex triangle strip goes into the
> first element of a separate cassette. It is only this case that appears
> to give trouble; if there are more or fewer than 216 elements, it works
> OK.
> 
> Compile the attached program and run with:
> 
> $ gcc -o try10 try10.c -lglut -lGL -lGLU -lm
> $ MESA_DEBUG=1 ./try10
> MMX cpu detected.
> Testing OS support for SSE...yes.
> Test OS support for SEE unmasked exceptions... SIGFPE, yes.
> Test of OS support for SSE passed.
> SSE cpu detected.
> Brian Paul Mesa X11 1.2 Mesa 3.5
> Mesa user error: GL_INVALID_OPERATION in begin/end
> Mesa user error: GL_INVALID_OPERATION in begin/end
> Mesa user error: GL_INVALID_OPERATION in begin/end
> $ gcc -DIMMEDIATE -o try10 try10.c -lglut -lGL -lGLU -lm
> $ MESA_DEBUG=1 ./try10
> MMX cpu detected.
> Testing OS support for SSE...yes.
> Test OS support for SEE unmasked exceptions... SIGFPE, yes.
> Test of OS support for SSE passed.
> SSE cpu detected.
> Brian Paul Mesa X11 1.2 Mesa 3.5
> $
> 
> In the first (error) case, one of the triangle strips just appears as a
> rectangle fading from cyan to yellow. In the second, immediate mode,
> case, both strips are correctly shown as parallel waves. If you adjust
> N_TRIANGLES in the program to be something other than 108, then both
> cases work.
> 
> Thanks,
> Allen
> 

Thanks for the bug report, Allen.  I'll get onto this.

Keith

Re: [Mesa3d-dev] CVS Build Problem

[Allen B. <ba...@lo...>]

"Sven M. Hallberg" wrote:
> 
> On Sun, Jul 08, 2001 at 11:04:43AM -0400, Allen Barnett wrote:
> > Hi,
> >
> > Sorry to be a pest. I did a fresh check out and build of the current CVS
> > version of Mesa. The build fails in the src/OSMesa directory:
> 
> Oh, please continue productive pestism.
> 

OK :-) Here is an even more minor issue: 'make distclean' dies like
this:

...
Making distclean in X86
make[2]: Entering directory `/home/src/Mesa/src/X86'
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include -I../../src
-DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM     -g -O2 -Wall
-fomit-frame-pointer -ffast-math -fexpensive-optimizations
-fstrict-aliasing -malign-loops=2 -malign-jumps=2 -malign-functions=2
-D_REENTRANT -DPTHREADS -c gen_matypes.c
In file included from gen_matypes.c:40:
../../src/glheader.h:72:18: conf.h: No such file or directory
In file included from ../../src/mtypes.h:33,
                 from gen_matypes.c:41:
../../src/config.h:38:18: conf.h: No such file or directory
make[2]: *** [gen_matypes.o] Error 1
make[2]: Leaving directory `/home/src/Mesa/src/X86'
...

If you fix this, though, please don't revert to requiring me to remmber
to rebuild matypes.h by hand :-)

Thanks,
Allen

Re: [Mesa3d-dev] CVS Build Problem

[Sven M. H. <pe...@gm...>]

On Sun, Jul 08, 2001 at 11:04:43AM -0400, Allen Barnett wrote:
> Hi,
> 
> Sorry to be a pest. I did a fresh check out and build of the current CVS
> version of Mesa. The build fails in the src/OSMesa directory:

Oh, please continue productive pestism.


> ...
> mv -f osmesa.o osmesa.lo
> make[3]: *** No rule to make target `../libGL.la', needed by
> `libMesaOS.la'.  Stop.
> make[3]: Leaving directory
> `/home/src/Mesa/src/OSmesa'                          
> ...
> 
> since libGL.la is not built until all the subdirectories are processed.

Thank you, I should do clean checkouts more often. This was easy to fix: just
told Automake to build in the OSmesa after everywhere else. See commit msg.


-Sven

-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]

[Mesa3d-dev] CVS Build Problem

[Allen B. <ba...@lo...>]

Hi,

Sorry to be a pest. I did a fresh check out and build of the current CVS
version of Mesa. The build fails in the src/OSMesa directory:
...
mv -f osmesa.o osmesa.lo
make[3]: *** No rule to make target `../libGL.la', needed by
`libMesaOS.la'.  Stop.
make[3]: Leaving directory
`/home/src/Mesa/src/OSmesa'                          
...

since libGL.la is not built until all the subdirectories are processed.

Thanks,
Allen

[Mesa3d-dev] Display List Problem

[Allen B. <ba...@lo...>]

Hi,

Attached is a short program which demonstrates a problem with display
lists in the current CVS version of Mesa. It appears that if a triangle
strip with exactly 216 vertices is compiled into a display list, an
error occurs in the processing of the display list which prevents the
execution of subsequent commands in the display list. From looking at
the code, it's related to the size of the cassette data structure. In
this case, the END element of a 216 vertex triangle strip goes into the
first element of a separate cassette. It is only this case that appears
to give trouble; if there are more or fewer than 216 elements, it works
OK.

Compile the attached program and run with:

$ gcc -o try10 try10.c -lglut -lGL -lGLU -lm
$ MESA_DEBUG=1 ./try10
MMX cpu detected.
Testing OS support for SSE...yes.
Test OS support for SEE unmasked exceptions... SIGFPE, yes.
Test of OS support for SSE passed.
SSE cpu detected.
Brian Paul Mesa X11 1.2 Mesa 3.5
Mesa user error: GL_INVALID_OPERATION in begin/end
Mesa user error: GL_INVALID_OPERATION in begin/end
Mesa user error: GL_INVALID_OPERATION in begin/end
$ gcc -DIMMEDIATE -o try10 try10.c -lglut -lGL -lGLU -lm
$ MESA_DEBUG=1 ./try10
MMX cpu detected.
Testing OS support for SSE...yes.
Test OS support for SEE unmasked exceptions... SIGFPE, yes.
Test of OS support for SSE passed.
SSE cpu detected.
Brian Paul Mesa X11 1.2 Mesa 3.5
$

In the first (error) case, one of the triangle strips just appears as a
rectangle fading from cyan to yellow. In the second, immediate mode,
case, both strips are correctly shown as parallel waves. If you adjust
N_TRIANGLES in the program to be something other than 108, then both
cases work.

Thanks,
Allen

[Mesa3d-dev] [ mesa3d-Bugs-439291 ] Voodoo2 glide3 always 640x480

[<no...@so...>]

Bugs item #439291, was opened at 2001-07-07 07:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=100003&aid=439291&group_id=3

Category: 3dfx-driver
Group: Rendering Error
Status: Open
Resolution: None
Priority: 5
Submitted By: Ivan Kalvatchev (iive)
Assigned to: Nobody/Anonymous (nobody)
Summary: Voodoo2 glide3 always 640x480

Initial Comment:
I own Voodoo2, i have instaled the lates glide from 
3dfx site (RIP). When i compile mesa it found glide2 
and glide3 and links with glide3. Then when i start 
game (Legacy doom, Quake 1,2,3) and try to 4ange 
resolution, strane thing happen. The screen get in the 
resolution but the voodoo still reners 640x480, so 
when i switch 800x600 a get picture in the corner, and 
then i switch to 512x482 i see just a part of the 
picture.
When i compile mesa only with glide2 everythink is OK.
I am sure that the bug comes from misreported FBI 
memory (it shows 0) that prevent mesa from switching 
resoultion (memory check). 
If you are sure that the bug is in glide3 could you 
give me working version of this.
By the way there are glide, glide2, glide2x, glide3, 
glide3x in ./configure, which version each voodoo card 
uses?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=100003&aid=439291&group_id=3

Re: [Mesa3d-dev] Hardcopy Output Driver

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

Allen Barnett wrote:
> 
> Hi,
> 
> Has anybody ever built a hardcopy output driver for Mesa which (more or
> less) retained the detailed geometry of the original primitives (as
> opposed to just taking a screen snapshot)? For example, older versions
> of the SGI Showcase program generated postscript commands which
> corresponded directly to the transformed and lighted points, lines and
> polygons in a scene; it even seemed to take care of depth sorting so
> that 3D elements where drawn correctly. (It didn't support texture
> mapping, though, which is probably why later versions of Showcase
> generated raster images instead.)
> 
> I'd like to build something which works with StarOffice (or OpenOffice).
> Currently, the only color vector drawing format which it can import is a
> Windows Metafile (which is basically a 2D drawing format). You could
> probably do something similar to the Showcase PostScript driver if you
> weren't too picky about smooth shading and texture mapping.
> 
> Would this be a reasonable approach? Or would it be better to just
> render in OSMesa at a high resolution and live with the raster image?

As I'm sure you know, there's a fundamental problem in that OpenGL
is raster-oriented while PostScript is vector-oriented.  

Marcelo mentioned gl2ps.  I haven't used it personally.

I think most people render high-resolution images with OpenGL then
print the raster images.  You might check out TR for generating
extra-large images: http://www.mesa3d.org/brianp/TR.html

Another approach, if you're just interested in line drawing, might
be to use OpenGL's feedback mode to capture the transformed coordinates
and emit PostScript line drawing commands.

-Brian