mesa3d-dev

[Mesa3d-dev] Anonymous CVS access for Mesa being denied?

[Stephen H. <sho...@pr...>]

When trying to get an update from cvs.mesa3d.org, I keep on getting a 
"connection refused" message - has the CVS archive moved?


	Stephen
-- 
  The views expressed above are not those of PGS Tensor.

    "We've heard that a million monkeys at a million keyboards could produce
     the Complete Works of Shakespeare; now, thanks to the Internet, we know
     this is not true."            Robert Wilensky, University of California

[Mesa3d-dev] Mesa 3.2 released

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

I've released Mesa 3.2.  You can download it from
http://sourceforge.net/project/filelist.php?group_id=3

or

ftp://ftp.mesa3d.org/mesa/

Here's what's new since the 3.2 beta release:

    Bug fixes:
	- fixed memcpy bugs in span.c
	- fixed missing glEnd problem in demos/tessdemo.c
	- fixed bug when clearing 24bpp Ximages
	- fixed clipping problem found in Unreal Tournament
	- fixed Loki's "ice bug" and "crazy triangles" seen in Heretic2
	- fixed Loki's 3dfx RGB vs BGR bug
	- fixed Loki's 3dfx smooth/flat shading bug in SoF
    Changes:
	- updated docs/README file
	- use bcopy() optimizations on FreeBSD
	- re-enabled the optimized persp_textured_triangle() function


-Brian

[Mesa3d-dev] CONFORM

[physic <ph...@te...>]

Hey Brian, I just wanted to point out that you should probably rerun
the sgi opengl conformance suite before you release 3.2.

--physic
ph...@te...

[Mesa3d-dev] Normals initialization problem

[<jo...@du...>]

Hi all,

I have the following problem with Mesa3.3:
 -I use the application xlockmore, running as
   xlock -mode random -modelist cage -nice 0 -inwindow
  as test application.
 -On my VMS box it crashes in
    LIBMESAGL  SHADE  shade_fast_rgba_two_sided_compacted
                                        26882 0000000000010C00 0000000000AD56E0
    because of a floating overflow
  On my AIX box it runs correctly.
 -The given line 26882 is somewhat below line 155 in shade_tmp.h. If I check
  normal[0],normal[1] and normal[2] at line 155 I get
    on VMS:
       normal : 0.000000 0.000000 1.000000
       normal : 1103029150191208900000.000000
         1130982216341569100000000000000.000000 0.000000
      {CRASH!!!!}
	 
    on AIX
       normal : 0.000000 0.000000 1.000000
       normal : 0.000000 0.000000 0.000000
       normal : 0.000000 1.000000 0.000000
          etc....
 -Skipping the illogical normals in shade_tmp.h give as far as I can see the
  right result on the screen.
 -Looks like that the normals are not initialized to zero on VMS but where???
  Any ideas?
  
               Jouk


Ceterum censeo tertium millennium post Christum natum anno MMI incepturum esse

>------------------------------------------------------------------------------<

  Jouk Jansen
		 
  jo...@hr...

  Technische Universiteit Delft        tttttttttt  uu     uu  ddddddd
  Nationaal centrum voor HREM          tttttttttt  uu     uu  dd    dd
  Rotterdamseweg 137                       tt      uu     uu  dd     dd
  2628 AL Delft                            tt      uu     uu  dd     dd
  Nederland                                tt      uu     uu  dd    dd
  tel. 31-15-2781536                       tt       uuuuuuu   ddddddd

>------------------------------------------------------------------------------<

Re: [Mesa3d-dev] Getting Mesa via CVS?

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

Kendall Bennett wrote:
> 
> Hi,
> 
> > Hey Kendall.  Maybe you its this:
> >
> > >  cvs -z3 -
> > > d:pserver:ano...@cv...:/cvsroot/mesa3d co .
> >
> > Change the . to Mesa
> 
> Ugh. That appears to be it. How come the . used to work with the old
> server, but it no longer works with the new one?
> 
> This should be mentioned more clearly on the CVS pages on
> SourceForge, since all it says to use is 'modulename', with no
> indication anywhere what the module name is! Note that the module
> name above does *not* match the cvsroot name (for CrystalSpace it is
> CS!).

I can't edit the CVS web page.  Perhaps you should send a note
to the admins with this suggestion.

The Mesa pages are due for an overhaul, or at least a bunch of
udpates.  I'll try to clarify this then.

-Brian

Re: [Mesa3d-dev] Getting Mesa via CVS?

[Kendall B. <Ken...@sc...>]

Hi,

> Hey Kendall.  Maybe you its this:
> 
> >  cvs -z3 -
> > d:pserver:ano...@cv...:/cvsroot/mesa3d co .
> 
> Change the . to Mesa

Ugh. That appears to be it. How come the . used to work with the old 
server, but it no longer works with the new one?

This should be mentioned more clearly on the CVS pages on 
SourceForge, since all it says to use is 'modulename', with no 
indication anywhere what the module name is! Note that the module 
name above does *not* match the cvsroot name (for CrystalSpace it is 
CS!).

Regards,

+---------------------------------------------------------------+
|   SciTech Software - Building Truly Plug'n'Play Software!     |
+---------------------------------------------------------------+
| Kendall Bennett          | Email: Ken...@sc...    |
| Director of Engineering  | Phone: (530) 894 8400              |
| SciTech Software, Inc.   | Fax  : (530) 894 9069              |
| 505 Wall Street          | ftp  : ftp.scitechsoft.com         |
| Chico, CA 95928, USA     | www  : http://www.scitechsoft.com  |
+---------------------------------------------------------------+

[Mesa3d-dev] Re: [utah-glx-dev] geekosphere xmms plugin crashes Mesa 3.2

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

On Fri, Apr 14, 2000 at 10:57:54AM -0600, Brian Paul wrote:
> Andreas Ehliar wrote:
> > 
> > On Wed, Apr 12, 2000 at 05:54:54PM -0400, Wichert Akkerman wrote:
> > > xmms with the `geekosphere' plugin (available from www.xmms.org) crashes Utah.
> > 
> > It crashes standard Mesa 3.2 with software rendering as well:
> > (I've submitted this as a bug report to the Mesa bugtracker)
> > 
> <snip backtrace>
> 
> What code do you see at line 170 of cull_tmp.h?  In my copy, line 170
> is the closing brace of a function.  But since this is macro-ized code
> there may be a line numbering descrepency.

I see the same closing brace here.

/AE

[Mesa3d-dev] Re: [utah-glx-dev] geekosphere xmms plugin crashes Mesa 3.2

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

Andreas Ehliar wrote:
> 
> On Wed, Apr 12, 2000 at 05:54:54PM -0400, Wichert Akkerman wrote:
> > xmms with the `geekosphere' plugin (available from www.xmms.org) crashes Utah.
> 
> It crashes standard Mesa 3.2 with software rendering as well:
> (I've submitted this as a bug report to the Mesa bugtracker)
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x400f09f7 in gl_make_normal_cullmask () at cull_tmp.h:170
> 170     }
> (gdb) bt
> #0  0x400f09f7 in gl_make_normal_cullmask () at cull_tmp.h:170
> #1  0x400c2a54 in do_normal_transform (VB=0x81b2700) at stages.c:423
> #2  0x400a871c in gl_run_pipeline () at pipeline.c:395
> #3  0x400f71a6 in gl_execute_cassette () at vbxform.c:812
> #4  0x40057e4d in gl_cva_compile_cassette () at cva.c:349
> #5  0x400f77fe in gl_flush_vb () at vbxform.c:812
> #6  0x40065941 in save_Map2f (ctx=0x81a0028, target=GL_MAP2_VERTEX_4, u1=0,
>     u2=1, ustride=24, uorder=3, v1=0, v2=1, vstride=4, vorder=3,
>     points=0x81f5458, retain=1) at dlist.c:1541
> #7  0x40031aaa in glMap2f () at api1.c:407
> #8  0x408ecf52 in draw_polygon_mode () from /usr/X11R6/lib/libGLU.so.1
> #9  0x18 in ?? ()



What code do you see at line 170 of cull_tmp.h?  In my copy, line 170
is the closing brace of a function.  But since this is macro-ized code
there may be a line numbering descrepency.



> ----------------------
> 
> It is interesting to note that Utah doesn't segfault at the same place:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x40a541aa in gl_make_normal_cullmask () at vbcull.c:804
> 804     }
> (gdb) bt
> #0  0x40a541aa in gl_make_normal_cullmask () at vbcull.c:804
> #1  0x40a0b3f2 in do_normal_transform (VB=0x819f028) at stages.c:423
> #2  0x409d7d56 in gl_run_pipeline () at pipeline.c:395
> #3  0x40a5cf7d in gl_execute_cassette () at vbxform.c:812
> #4  0x4096d4bd in gl_cva_compile_cassette () at cva.c:189
> #5  0x40a59509 in gl_maybe_transform_vb () at vbxform.c:188
> #6  0x40a595c2 in gl_flush_vb () at vbxform.c:188
> #7  0x40973373 in save_Map2f (ctx=0x81d8170, target=GL_MAP2_VERTEX_4, u1=0,
>     u2=1, ustride=24, uorder=3, v1=0, v2=1, vstride=4, vorder=3,
>     points=0x82330c8, retain=1 '\001') at dlist.c:1541
> #8  0x409258e2 in glMap2f () at api1.c:1647
> #9  0x4004c8b2 in glMap2f () at api1.c:1414
> #10 0x40788f52 in draw_polygon_mode () from /usr/X11R6/lib/libGLU.so.1
> #11 0x18 in ?? ()


Keith, can you look into this?

-Brian

[Mesa3d-dev] geekosphere xmms plugin crashes Mesa 3.2

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

On Wed, Apr 12, 2000 at 05:54:54PM -0400, Wichert Akkerman wrote:
> xmms with the `geekosphere' plugin (available from www.xmms.org) crashes Utah.

It crashes standard Mesa 3.2 with software rendering as well:
(I've submitted this as a bug report to the Mesa bugtracker)

Program received signal SIGSEGV, Segmentation fault.
0x400f09f7 in gl_make_normal_cullmask () at cull_tmp.h:170
170     }
(gdb) bt
#0  0x400f09f7 in gl_make_normal_cullmask () at cull_tmp.h:170
#1  0x400c2a54 in do_normal_transform (VB=0x81b2700) at stages.c:423
#2  0x400a871c in gl_run_pipeline () at pipeline.c:395
#3  0x400f71a6 in gl_execute_cassette () at vbxform.c:812
#4  0x40057e4d in gl_cva_compile_cassette () at cva.c:349
#5  0x400f77fe in gl_flush_vb () at vbxform.c:812
#6  0x40065941 in save_Map2f (ctx=0x81a0028, target=GL_MAP2_VERTEX_4, u1=0, 
    u2=1, ustride=24, uorder=3, v1=0, v2=1, vstride=4, vorder=3, 
    points=0x81f5458, retain=1) at dlist.c:1541
#7  0x40031aaa in glMap2f () at api1.c:407
#8  0x408ecf52 in draw_polygon_mode () from /usr/X11R6/lib/libGLU.so.1
#9  0x18 in ?? ()



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

It is interesting to note that Utah doesn't segfault at the same place:

Program received signal SIGSEGV, Segmentation fault.
0x40a541aa in gl_make_normal_cullmask () at vbcull.c:804
804     }
(gdb) bt
#0  0x40a541aa in gl_make_normal_cullmask () at vbcull.c:804
#1  0x40a0b3f2 in do_normal_transform (VB=0x819f028) at stages.c:423
#2  0x409d7d56 in gl_run_pipeline () at pipeline.c:395
#3  0x40a5cf7d in gl_execute_cassette () at vbxform.c:812
#4  0x4096d4bd in gl_cva_compile_cassette () at cva.c:189
#5  0x40a59509 in gl_maybe_transform_vb () at vbxform.c:188
#6  0x40a595c2 in gl_flush_vb () at vbxform.c:188
#7  0x40973373 in save_Map2f (ctx=0x81d8170, target=GL_MAP2_VERTEX_4, u1=0, 
    u2=1, ustride=24, uorder=3, v1=0, v2=1, vstride=4, vorder=3, 
    points=0x82330c8, retain=1 '\001') at dlist.c:1541
#8  0x409258e2 in glMap2f () at api1.c:1647
#9  0x4004c8b2 in glMap2f () at api1.c:1414
#10 0x40788f52 in draw_polygon_mode () from /usr/X11R6/lib/libGLU.so.1
#11 0x18 in ?? ()


regards
Andreas Ehliar

Re: [Mesa3d-dev] gluBuild2DMipmaps() bug?

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

And...@uk... wrote:
> 
> Hi,
> 
> I was wondering if anybody is experiencing an 'illegal instruction' error when using gluBuild2DMipmap() functions with Mesa 3.1/3.2 on Linux?
> 
> I've double checked the code and it looks fine. It also works on other implementations of OpenGL (Sun, and Msft) without problem.
> 
> The call is:
> 
> gluBuild2DMipmaps(GL_TEXTURE_2D, 3, image->sizeZ, image->sizeY,
>                   GL_RGB, GL_UNSIGNED_BYTE, image->data);
> 
> The image size is 256x256.
> 
> The interface is glX.
> 
> I'm running Mandrake 7 Linux which has Mesa 3.1 as default. I've since installed Mesa 3.2, but to no avail.
> 
> Has anybody seen this problem before?

Haven't heard of that one before.  Can you get a stack trace with your
debugger?

-Brian

[Mesa3d-dev] gluBuild2DMipmaps() bug?

[<And...@uk...>]

Hi,

I was wondering if anybody is experiencing an 'illegal instruction' error when using gluBuild2DMipmap() functions with Mesa 3.1/3.2 on Linux?

I've double checked the code and it looks fine. It also works on other implementations of OpenGL (Sun, and Msft) without problem.

The call is:

gluBuild2DMipmaps(GL_TEXTURE_2D, 3, image->sizeZ, image->sizeY,
		  GL_RGB, GL_UNSIGNED_BYTE, image->data);

The image size is 256x256.

The interface is glX.

I'm running Mandrake 7 Linux which has Mesa 3.1 as default. I've since installed Mesa 3.2, but to no avail.

Has anybody seen this problem before?

Kind Regards,

Andy White

Re: [Mesa3d-dev] Getting Mesa via CVS?

[Mukund I. <mu...@hd...>]

>One other thing I forgot. On the SourceForge web pages it says that I 
>need SSH1 in order to get developer access rights to CVS (I am now a 
>developer of Mesa so I have the permissions). However where do I get 
>SSH1 for Win32 so I can do this (and no, I can't do this from Linux!).


try ftp://ftp.ssh.com/pub/ssh/

you can check docs on ssh at http://www.ssh.fi/

if you need more info on getting sourceforge to work for you
(as a new user), you should check the sourceforge documentation project
at http://sfdocs.sourceforge.net/

it has docs on many things like CVS access, SSH, new project HOWTOs, etc.


- muks

Re: [Mesa3d-dev] Getting Mesa via CVS?

[physic <ph...@te...>]

Hey Kendall.  Maybe you its this:

>  cvs -z3 -
> d:pserver:ano...@cv...:/cvsroot/mesa3d co .

Change the . to Mesa


This should get you anonymous access.  For ssh1 acces I dunno.  A bud of
ming bought fsecure ssh for windows and it works well.  Not sure if it has
a command line interface.  Maybe the sourceforge people have soemthign in
their faq.

--physic
ph...@te...

Re: [Mesa3d-dev] Getting Mesa via CVS?

[Kendall B. <Ken...@sc...>]

Hi again,

One other thing I forgot. On the SourceForge web pages it says that I 
need SSH1 in order to get developer access rights to CVS (I am now a 
developer of Mesa so I have the permissions). However where do I get 
SSH1 for Win32 so I can do this (and no, I can't do this from Linux!).

Regards,

+---------------------------------------------------------------+
|   SciTech Software - Building Truly Plug'n'Play Software!     |
+---------------------------------------------------------------+
| Kendall Bennett          | Email: Ken...@sc...    |
| Director of Engineering  | Phone: (530) 894 8400              |
| SciTech Software, Inc.   | Fax  : (530) 894 9069              |
| 505 Wall Street          | ftp  : ftp.scitechsoft.com         |
| Chico, CA 95928, USA     | www  : http://www.scitechsoft.com  |
+---------------------------------------------------------------+

[Mesa3d-dev] Getting Mesa via CVS?

[Kendall B. <Ken...@sc...>]

Ok,

I must be really stupid or something, but I simply can't get CVS to 
work for me again. I have used it in the past to connect to up CVS 
for Mesa (and other projects), but now I can't get any of them to 
work. Basically I have all my cvs stuff under my c:\cvs directory on 
Windows 2000. I am using the 1.10 command line version of CVS for 
Win32. Now I tried to sync up to Mesa using the following commands:

 cd \cvs
 md \cvs\Mesa3D
 cd \cvs\Mesa3D
 cvs -d:pserver:ano...@cv...:/cvsroot/mesa3d 
login
 cvs -z3 -
d:pserver:ano...@cv...:/cvsroot/mesa3d co .

and I always get the following:

cvs checkout: cannot open CVS/Entries for reading: No such file or 
directory
cvs [checkout aborted]: no repository

I tried the CrystalSpace and Jet3D CVS servers also with no luck. So 
what am I doing wrong!!?

Regards,

+---------------------------------------------------------------+
|   SciTech Software - Building Truly Plug'n'Play Software!     |
+---------------------------------------------------------------+
| Kendall Bennett          | Email: Ken...@sc...    |
| Director of Engineering  | Phone: (530) 894 8400              |
| SciTech Software, Inc.   | Fax  : (530) 894 9069              |
| 505 Wall Street          | ftp  : ftp.scitechsoft.com         |
| Chico, CA 95928, USA     | www  : http://www.scitechsoft.com  |
+---------------------------------------------------------------+

[Mesa3d-dev] Re: [Mesa-dev] Latest status of Mesa?

[Kendall B. <Ken...@sc...>]

Hi Brian,

> If you've got bug fixes for 3.2 please check them in ASAP.

I don't have any at the moment, but we will be doing some testing 
shortly so we might uncover some. There are a few issues we are 
fixing that we want to add back in if the stuff is not already there.

Regards,

+---------------------------------------------------------------+
|   SciTech Software - Building Truly Plug'n'Play Software!     |
+---------------------------------------------------------------+
| Kendall Bennett          | Email: Ken...@sc...    |
| Director of Engineering  | Phone: (530) 894 8400              |
| SciTech Software, Inc.   | Fax  : (530) 894 9069              |
| 505 Wall Street          | ftp  : ftp.scitechsoft.com         |
| Chico, CA 95928, USA     | www  : http://www.scitechsoft.com  |
+---------------------------------------------------------------+

[Mesa3d-dev] Re: [Mesa-dev] Latest status of Mesa?

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

Kendall Bennett wrote:
> 
> Brian Paul <br...@pr...> wrote:
> 
> > 3.2 will be wrapped up and released as soon as I find and fix a few
> > more specific bugs.  Hopefully within a week.
> 
> Great! We will concentrate on using the 3.2 sources for our release
> stuff since that will sync up well with us. We may have other bug
> fixes that we want to contribute back also.

If you've got bug fixes for 3.2 please check them in ASAP.


> > > My current CVS
> > > stuff is a version of the Mesa 3.1 development tree, and I want to
> > > have the ability to work with both the 3.1 development tree and the
> > > 3.2 release tree.
> >
> > There is no 3.1 tree/branch.  The sources were tagged when 3.1 was
> > released.  It's done.  3.2 is the stabilization of 3.1.  That
> > means no new features; only bug fixes.
> 
> Right, I did not look at the version I am using but it is currently
> Mesa 3.3 ;-)
> 
> > > How can I sync up to the 3.2 release tree with CVS
> > > (I am not that familiar with CVS; I need to brush up on it again ;-).
> >
> > When you do a check-out or update use the -r (revision) option
> > to specify the mesa_3_2_dev branch:
> >
> >       cvs update -r mesa_3_2_dev
> >
> > The default, main trunc has the Mesa 3.3 sources.  There's been a LOT
> > of changes from 3.1/3.2 to 3.3.  3.3 is used for the DRI project.
> > That's where new development happens.
> 
> Ok. Is it possible to sync up to *both* branches, so I can have the
> 3.2 sources in one directory and the 3.3 sources in another? I would
> like to help work on 3.3, but we need to stick to 3.2 for the time
> being until we release the product.

Sure, I have two Mesa CVS directories, one for each branch.


> > > and do the people who have write permissions
> > > previously still have write permissions to CVS?
> >
> > No, as I wrote this morning you'll have to get a sourceforge login
> > and send it to me so I can add you to the project and enable CVS
> > writes for you.
> 
> Ok, I will go do that.
> 
> Are there now two Mesa 3D development lists, the original one and now
> the SourceForge one? Wouldn't it make more sense to simply have one
> list?

Yup.  I'll probably have the old dev list and bug list shut down over
the weekend.

-Brian

[Mesa3d-dev] Re: [Mesa-dev] Latest status of Mesa?

[Kendall B. <Ken...@sc...>]

Brian Paul <br...@pr...> wrote:

> 3.2 will be wrapped up and released as soon as I find and fix a few
> more specific bugs.  Hopefully within a week. 

Great! We will concentrate on using the 3.2 sources for our release 
stuff since that will sync up well with us. We may have other bug 
fixes that we want to contribute back also.

> > My current CVS
> > stuff is a version of the Mesa 3.1 development tree, and I want to
> > have the ability to work with both the 3.1 development tree and the
> > 3.2 release tree.
> 
> There is no 3.1 tree/branch.  The sources were tagged when 3.1 was
> released.  It's done.  3.2 is the stabilization of 3.1.  That
> means no new features; only bug fixes. 

Right, I did not look at the version I am using but it is currently 
Mesa 3.3 ;-)

> > How can I sync up to the 3.2 release tree with CVS
> > (I am not that familiar with CVS; I need to brush up on it again ;-).
> 
> When you do a check-out or update use the -r (revision) option
> to specify the mesa_3_2_dev branch:
> 
> 	cvs update -r mesa_3_2_dev
> 
> The default, main trunc has the Mesa 3.3 sources.  There's been a LOT
> of changes from 3.1/3.2 to 3.3.  3.3 is used for the DRI project.
> That's where new development happens.

Ok. Is it possible to sync up to *both* branches, so I can have the 
3.2 sources in one directory and the 3.3 sources in another? I would 
like to help work on 3.3, but we need to stick to 3.2 for the time 
being until we release the product.

> > and do the people who have write permissions
> > previously still have write permissions to CVS?
> 
> No, as I wrote this morning you'll have to get a sourceforge login
> and send it to me so I can add you to the project and enable CVS
> writes for you. 

Ok, I will go do that.

Are there now two Mesa 3D development lists, the original one and now 
the SourceForge one? Wouldn't it make more sense to simply have one 
list?

Regards,

+---------------------------------------------------------------+
|   SciTech Software - Building Truly Plug'n'Play Software!     |
+---------------------------------------------------------------+
| Kendall Bennett          | Email: Ken...@sc...    |
| Director of Engineering  | Phone: (530) 894 8400              |
| SciTech Software, Inc.   | Fax  : (530) 894 9069              |
| 505 Wall Street          | ftp  : ftp.scitechsoft.com         |
| Chico, CA 95928, USA     | www  : http://www.scitechsoft.com  |
+---------------------------------------------------------------+

[Mesa3d-dev] Re: [Mesa-dev] Latest status of Mesa?

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

Kendall Bennett wrote:
> 
> Hi Guys,
> 
> I am trying to determine the latest status of the Mesa 3D project,
> since we are trying to wrap up some of our Mesa projects for release.
> Hence I am thinking that we should be sticking to the Mesa 3.2
> sources instead of the Mesa 3.1 (or is it now Mesa 3.3) development
> sources. Would that make sense?

3.2 will be wrapped up and released as soon as I find and fix a
few more specific bugs.  Hopefully within a week.


> So, how do I go about doing this? I figure I can download the latest
> sources, but it looks like there is only a Mesa 3.2b1 archive (is
> that beta 1 or is Mesa 3.2 now officially released?).

3.2b1 = 3.2 beta 1


> My current CVS
> stuff is a version of the Mesa 3.1 development tree, and I want to
> have the ability to work with both the 3.1 development tree and the
> 3.2 release tree.

There is no 3.1 tree/branch.  The sources were tagged when 3.1 was
released.  It's done.  3.2 is the stabilization of 3.1.  That means
no new features; only bug fixes.


> How can I sync up to the 3.2 release tree with CVS
> (I am not that familiar with CVS; I need to brush up on it again ;-).

When you do a check-out or update use the -r (revision) option
to specify the mesa_3_2_dev branch:

	cvs update -r mesa_3_2_dev

The default, main trunc has the Mesa 3.3 sources.  There's been a LOT
of changes from 3.1/3.2 to 3.3.  3.3 is used for the DRI project.
That's where new development happens.


> Also I notice that Mesa 3D is now on Source Forge. Is CVS now on
> SourceForge also,

Yes, as I said in email yesterday.


> and do the people who have write permissions
> previously still have write permissions to CVS?

No, as I wrote this morning you'll have to get a sourceforge login and
send it to me so I can add you to the project and enable CVS writes for
you.


> Is the CVS server address still the same as before?

No.  Visit mesa3d.sourceforge.net for the new CVS instructions.

-Brian

[Mesa3d-dev] Mesa CVS write access

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

Those of you who want CVS write access must first get an account
on sourceforge.  Then send me a note, with your login ID, so I
can add you as a project developer and enable CVS writes for you.

Note that you'll need ssh (Secure Shell) on your system for CVS
write authentication.

-Brian

[Mesa3d-dev] Mesa CVS now on SourceForge

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

One of the Mesa CVS host's disks went haywire and so VA moved the
Mesa CVS tree to SourceForge.net.  Everything appears to be intact.
(sigh of relief!)

So, everyone will have to check out a new CVS tree from SourceForge
following the instructions at http://sourceforge.net/cvs/?group_id=3

I'd also like to remind all developers to join the new mesa3d-dev
mailing list.  The mes...@me... list will be shut down at
some point.  You can subscribe to the new list(s) at
http://sourceforge.net/mail/?group_id=3

Consolidating all the Mesa stuff on SourceForge will simplify things
for me and the admins.

-Brian

[Mesa3d-dev] FP exception in gl_x86_cliptest_points4()

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

If anyone has seen clipping problems in Mesa 3.1 or later on X86 systems
you might be interested in this.

I found that gl_x86_cliptest_points4() is raising an FP overflow
exception in some programs.  Disabling that function, by commenting
out the assignment near line 114 of Mesa/src/X86/x86.c:

#if 0   
   gl_clip_tab[4] = gl_x86_cliptest_points4;
#endif

stopped the exception.

So, if you've had clipping problems try this fix and let me know if
it solves the problem.

-Brian

PS: You can enable FP exception aborts in Mesa 3.3 with 'setenv MESA_DEBUG FP'
Normally, most (all?) FP exceptions on X86 Linux (other OSes?) are silently
ignored.

[Mesa3d-dev] Bug database usage

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

I'm glad that people are reporting bugs in the Mesa bug database
on SourceForge.  However, I'd like it if people would submit their
bugs as a real user, not anonymously.  If you submit bugs anonymously
you won't get email when the report is modified.  People usually don't
submit enough information in their bug reports and I have to ask
follow-up questions.  If you report bugs as anonymous, please
check back every so often to see if more information is needed.

Remember, a vague bug report is pretty much worthless and is unlikely
to get fixed.

Thanks.

-Brian

Re: [Mesa3d-dev] gears - automation

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

Alexander Perry wrote:
> 
> I'd like to suggest that the demo "gears" have a
> command line option for automatically exiting
> after a specific time.  This simplifies doing
> comparative performance rendering speed tests.
> I've added one for my own use; patch is attached.

Done (in Mesa 3.3).

-Brian

[Mesa3d-dev] gears - automation

[Alexander P. <ar...@pa...>]

I'd like to suggest that the demo "gears" have a
command line option for automatically exiting
after a specific time.  This simplifies doing
comparative performance rendering speed tests.
I've added one for my own use; patch is attached.