mesa3d-dev

[Mesa3d-dev] Porting 3.3 to Windows

[<me...@bi...>]

I'm trying to get Mesa 3.3 compiling under windows.  Someone kindly
mentioned they got this working with a trivial change, but it doesn't
seem to be so easy to me.  Namely the driver interface has changed
a bit so src/Windows doesn't compile any more.

The extensions table in src/Windows/wgl.h has references to gl*EXT
functions, but they don't exist anymore in 3.3.  It looks like I could
either get these functions dynamically from a context, or I could use
_mesa_*EXT versions.  What's the right thing to do?

--Bill Baxter

[Mesa3d-dev] what happened to mesa-widgets/src?

[James A. T. <tr...@de...>]

There is no source in mesa-widgets/src in mesa 3.2.1.
Is this intentional and if so, why?

-- 
James (Jay) Treacy
tr...@de...

Re: [Mesa3d-dev] Mesa version and CVS branch info

[Michael V. <bri...@lo...>]

On Mon, Jul 31, 2000 at 07:12:37AM -0600, Brian Paul wrote:

> Many of you will want to keep two Mesa CVS directory trees, one
> for the 3.4 branch and another for the 3.5 trunk.

Two?!

[michael@namaste src]$ ls -d Mesa*
Mesa-2.6  Mesa-3.1  Mesa-3.2.1  Mesa-3.4
Mesa-3.0  Mesa-3.2  Mesa-3.3    Mesa-3.5

:)

m.

-- 
Programmer             "Ha ha." "Ha ha." "What are you laughing at?"
Loki Software                      "Just the horror of being alive."
http://lokigames.com/~briareos/                   - Tony Millionaire

[Mesa3d-dev] Mesa version and CVS branch info

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

There are now two active versions of Mesa development:
  a) 3.4 (an even number) which is the stabilization (bug fixes)
     since Mesa 3.3.  This is the mesa_3_4_branch CVS branch.

  b) 3.5 (an odd number) which is the branch for all new development
     and new features.  This is the CVS trunk.

To set your Mesa CVS tree onto the 3.4 branch, do a
"cvs update -r mesa_3_4_branch" command.

To set your Mesa CVS tree to the trunk, do a "cvs update -A" command.

Many of you will want to keep two Mesa CVS directory trees, one
for the 3.4 branch and another for the 3.5 trunk.

If you commit bug fixes, be sure to check them into both branches
if appropriate.

Thanks.

-Brian

Re: [Mesa3d-dev] More bad news about Mesa 3.3 and Win32

[Alessandro P. <al...@ti...>]

At 15.24 25/07/00, Gareth Hughes wrote:
>I've whipped up a VC 6.0 project/workspace and have built Mesa-3.3 with
>it.  I'm at SIGGRAPH at the moment and am planning on submitting this to
>Brian when I get back.
I am trying to compile all from commandline.
I do not like VCx-IDE very much (well...i think it sucks at all ;)


>The one change I made was to include a "#include <windows.h>" in
>glheader.h if _WIN32 was defined and _WINDOWS_ wasn't (or whatever the
>windows.h definition is).
Where? (i.e. : at which line ?)
I've just tried to add :

#if defined(_WIN32) && !defined(_WINDOWS_)
#include <windows.h>
#endif

after the "/* XXX " comment lines but it does not work for me (I mean: i 
have the same errors as before).
Ah: please note that I copied mesa_wgl.h into include/GL from mesa 3.2.1, 
cos in 3.3 distrubution-file it is missing (I reported it some days ago).
Is this wrong ?

Btw, it works fine on your pc.. so.... please enlight me on how make this 
damned WC (yes, WC!) work with mesa3.3 ! ^___-
Thanks in advance,

TXM

Re: [Mesa3d-dev] More bad news about Mesa 3.3 and Win32

[Gareth H. <ga...@va...>]

Alessandro Pisani wrote:
> 
> Okay...i tried to work-around the types-redefinition problems and so
> compile Mesa 3.3 for win32. It goes okay except for glapi.c : MS-VC6 does
> not like this one at all ;-) Simply, it stops with this sad line: "fatal
> error C1003: error count exceeds 100; stopping compilation". Is this, as
> usual, a MS-VC6 problem (I mean: does glapi.c compile without errors with
> gcc and under mingw32?) ?
> and did anyone else try to compile mesa 3.3 for win32 ?
> 
> PS: I tried with both win32/nmake.mak and src/makefile.fx (which is usually
> better for reading/debugging ms-vc making process).

I've whipped up a VC 6.0 project/workspace and have built Mesa-3.3 with
it.  I'm at SIGGRAPH at the moment and am planning on submitting this to
Brian when I get back.

The one change I made was to include a "#include <windows.h>" in
glheader.h if _WIN32 was defined and _WINDOWS_ wasn't (or whatever the
windows.h definition is).

-- Gareth

[Mesa3d-dev] More bad news about Mesa 3.3 and Win32

[Alessandro P. <al...@ti...>]

Okay...i tried to work-around the types-redefinition problems and so 
compile Mesa 3.3 for win32. It goes okay except for glapi.c : MS-VC6 does 
not like this one at all ;-) Simply, it stops with this sad line: "fatal 
error C1003: error count exceeds 100; stopping compilation". Is this, as 
usual, a MS-VC6 problem (I mean: does glapi.c compile without errors with 
gcc and under mingw32?) ?
and did anyone else try to compile mesa 3.3 for win32 ?

PS: I tried with both win32/nmake.mak and src/makefile.fx (which is usually 
better for reading/debugging ms-vc making process).

TXM
---
Alessandro Pisani aka TXM - email:al...@ti..., ICQ #2209087
INWO Project Head-programmer - http://www.inwoproject.f2s.com/
Team Isa++ software design coder ----- http://teamisa.cjb.net/

[Mesa3d-dev] Problems in Mesa-3.2.1 and Mesa-3.3 for Win32

[Alessandro P. <al...@ti...>]

I downloaded both Mesa3.2.1 and Mesa3.3 and tried to compile them for Win32 
using MS-VC 6.0-SP4; here there is a list of problems I found (which were 
not present in Mesa 3.2, I mean) :

Light problems (Mesa 3.x):
1a) In both Mesa 3.2.1 and Mesa 3.3 , due to the revert to GLU 1.1, win32 
makefiles contains some "orphans" (like tess_clip.*, tess_wind.*, etc etc)
This email has a patched win32/rules/lib.mesaglu.core attached.

1b) ...there is also to change the src-glu/mesaGLU.def (GLU32.DLL is not 
generated noither via win32/nmake.mak nor via src-glu/makefile.fx) or you 
will get some unresolved externals errors in linking.
This email has a patched src-glu/mesaGLU.def AND a pathed 
win32/res/mesaglu32.def attached (I only rem some lines)

Heavy problems (Mesa 3.3 only):
1) win32 makefiles updated in 3.2.1 are NOT present (why?)
2) GL/mesa_wgl.h file is MISSING (again, this was present in Mesa3.2.1)
3) VC start compiling but stop after a while with fatal errors (i.e. : HDC 
and HGLRC types redefined in glheader.h from 
E:\PROGRA~1\MICROS~2\VC98\INCLUDE\windef.h )

This does not happen in Mesa 3.2.1 in which gl.h was not splitted into gl.h 
and glheader.h :( I'm investigating on this... but it is really hard, at 
least for me.

PS: Brian told me some people complained about the CR/LF files I posted 
some time ago. Sorry, this is caused by my working in DOS/Win32 instead of 
Linux (my Linux partition is actually KO :sob!: ). Use this to fix the 
file: sh -c "mv filename _tmpfile; tr -d \\\r < _tmpfile > filename; rm 
_tmpfile"

TXM 

Re: [Mesa3d-dev] Mesa 3.3, DRI, XF40

[Gareth H. <ga...@va...>]

"Sven M. Hallberg" wrote:
> 
> Then how can I upgrade my XF40 DRI libGL?

Just install XFree86 4.0.1 or use the CVS version of either the DRI
(absolute latest) or XFree86.  Just use whatever comes with your current
version of XFree86 - mixing and matching will surely cause problems.

-- Gareth

Re: [Mesa3d-dev] Mesa 3.3, DRI, XF40

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

On Fri, Jul 21, 2000 at 01:45:07PM -0600, Brian Paul wrote:
> > Will I be able to use the libGL created by compiling the Mesa 3.3 distribution
> > for hardware-accelerated DRI rendering under XFree86 4.0 (substituting the
> > libGL compiled with XF)?
> 
> No.  The Mesa 3.3 distro has no code related to GLX or the DRI.

Then how can I upgrade my XF40 DRI libGL?

-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] Mesa 3.3, DRI, XF40

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

"Sven M. Hallberg" wrote:
> 
> Hi,
> 
> Will I be able to use the libGL created by compiling the Mesa 3.3 distribution
> for hardware-accelerated DRI rendering under XFree86 4.0 (substituting the
> libGL compiled with XF)?

No.  The Mesa 3.3 distro has no code related to GLX or the DRI.

-Brian

[Mesa3d-dev] Mesa 3.3, DRI, XF40

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

Hi, 

Will I be able to use the libGL created by compiling the Mesa 3.3 distribution
for hardware-accelerated DRI rendering under XFree86 4.0 (substituting the
libGL compiled with XF)?

Thanks,
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] Build error on current CVS (HEAD) [PATCH]

[Thomas T. <ta...@ff...>]

On 19-Jul-2000 Richard Guenther wrote:
> Hi!
> 
> I'm unable to build the current mesa on standard Linux/ix86:
> 
> ./configure --disable-ggi-fbdev
> 
> 
> It seems that though GGI seems to be detected disabled correctly:
> 
> checking for ggi/ggi.h... (cached) yes
> checking for main in -lggi... (cached) yes
> checking for kgi/kgi.h... (cached) no
> checking if we should build GGIMesa's fbdev target... no
> checking if we should build GGIMesa's generic KGI driver... no
> 
> (but ggi.h installed) is is tried to use it - as I can see from
> conf.h GGI is enabled...
> 
> so perhaps we need a --disable-ggi switch... [see attached patch]
> also --disable-svga should be there for the same reasons (well I
> would vote for all but X11 and GLX drivers to be disabled by default
> and to be enabled by --enable-feature rather than autodetecting such
> stuff anyway).

 Please read the docs!
 There already are --without-ggi, --without-svga etc. flags to
 disable specific drivers.

Thomas Tanner -------------------------
email: tanner@(ffii.org|gnu.org|gmx.de)
web:   http://home.pages.de/~tanner
UMI:   http://umi.ffii.org

[Mesa3d-dev] Mesa 3.3 released

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

I've just uploaded the Mesa 3.3 files to www.sourceforge.net.
They can be downloaded from http://sourceforge.net/project/filelist.php?group_id=3

Following the Linux kernel even/odd release number policy, Mesa 3.3
is considered to be a development version.  Mesa 3.2.1 is the latest
stable release.

Mesa 3.3 should be pretty reliable though as it's been in use by
XFree86/DRI for a few months now.  If you try Mesa 3.3 and find
a problem, please report it to the Mesa bug database on sourceforge.net
I hope to release the 3.4/stable version in a timely manner.

Here's what's new in version 3.3:
    New:
	- antialiased triangles now implemented
	- GL_EXT_texture_env_add texture mode extension
	- GLX 1.3 API
	- support for separate draw/read buffers (ie GL_SGI_make_current_read)
	- thread-safe API dispath
	- improved glxinfo program
	- demos/texdown program to measure texture download performance
	- glext.h header file
	- demos/geartrain program
	- GL_EXT_texture_lod_bias extension
	- demos/lodbias program
	- further optimized glRead/DrawPixels for 16-bit TrueColor X visuals
	- GLX_EXT_visual_rating extension (a no-op, however)
	- GL_HP_occlusion_test extension (for X and OS/Mesa drivers)
	- demos/occlude program
	- GL_SGIS_pixel_texture and GL_SGIX_pixel_texture extensions
	- demos/pixeltex program
	- GL_SGI_color_matrix extension
	- GL_SGI_color_table extension
	- GL_EXT_histogram extension
	- GL_ARB_texture_cube_map extension
	- added xdemos/glxheads and xdemos/manywin
	- demos/texenv.c demo
	- GL_EXT_texture_env_combine extension (by Holger Waechtler)
	- Xlib driver is now thread-safe (see xdemos/glthreads)
    Bug Fixes:
	- various GL conformance failures fixed since 3.2.1
    Changes:
	- gl.h now uses #defines instead of C enums for all tokens
	- glu.h now uses #defines instead of C enums for all tokens
	- moved programs from 3Dfx/demos/ into demos/ directory

I think that's ten new extensions altogether!

I'm also happy to report that Mesa 3.3 passes all the OpenGL 1.1
conformance tests, except for antialiased lines in a few situations.
I plan to rewrite the AA line algorithm for the next release.
Keith Whitwell helped a lot in fixing the remaining conformance bugs.

For more details on the internal changes to Mesa 3.3 please read the
docs/RELNOTES-3.3 file.

-Brian

PS: I'll be away at SIGGRAPH all next week and won't be reading/replying
to email too often.  I'll see some of you there!

[Mesa3d-dev] Mesa version plans

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

I've just tagged the trunk sources with the label 'mesa_3_3'.  I'll
be releasing the 3.3 distro files soon.

Recall that Mesa's using an even/odd version numbering scheme.  Odd
releases (like 3.3) are considered developmental/experimental because
there's been a lot of internal changes and new extensions implemented.

Even releases (like 3.2 and 3.2.1) are considired stable releases.

In this case, Mesa 3.3 should be pretty stable.  It's been used within
XFree86/DRI for a few months now.  I hope to make the 3.4 release
fairly quicky and get it included in the next XFree86 release.


The Mesa roadmap looks like this:

   1. The 3.2 / 3.2.1 branch probably won't be touched anymore.

   2. We'll soon create a 3.4 branch (labeled mesa_3_4_branch) which will
      be where we just fix bugs found in Mesa 3.3 in preparation for
      the stable 3.4 release.

   3. The trunk will then be considered to be 3.5 where new development
      will take place.  Keith has started a new large project and will
      check in his work there.

-Brian

PS: I (and many of the DRI guys) will be away at SIGGRAPH all next
week.  I'll probably won't read/reply to email very often.

[Mesa3d-dev] Mesa 3.2.1 released

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

Mesa 3.2.1 can now be downloaded from the SourceForge download
page at http://sourceforge.net/project/filelist.php?group_id=3

Version 3.2.1 just fixes bugs since the 3.2 release:

	- gluBuild2DMipmaps() didn't accept GL_BGRA
	- Fixed compile/makefile problems on IRIX
	- fixed segfault in 3dfx driver when using GL selection/feedback
	- no longer cull very, very tiny triangles
	- blending w/ drawbuffer==GL_FRONT_BACK caused segfault (sw rendering)
	- fixed Motif detection code in widgets-mesa/configure.in
	- glColorMaterial and glMaterial updates to emissive and ambient
	  didn't always work right
	- Specular highlights weren't always in the right place
	- clipped GL_LINE mode polygons had interior lines appear
	- several OpenGL conformace test fixes
	- blend term GL_ONE_MINUS_CONSTANT_ALPHA was broken
	- GL_NICEST fog didn't always work with flat shading
	- glRect commands in display lists were sometimes miscolored
	- Line Z offset didn't always work
	- fixed texgen normal vector problem (gloss's teapot)
	- numerous GL conformance bugs fixed

Also, the GLU library has been reverted to GLU version 1.1 since the
new 1.2 polygon tessellator wasn't working very well.


NOTE: Mesa 3.3 will be released very soon (perhaps today or tomorrow).
There will not be a 3.3 beta release since it's been tested within
XFree86/DRI for several months now.  3.3 (an odd-numbered release) is
considered a development/experimental release.  The internals have
changed a lot and many new extensions have been added.

Finally, there are a number of open bug reports on SourceForge which
I can't make any progress on until people post follow-up information.
As I've said before, if you submit a bug report, please check on it
from time to time.

-Brian

[Mesa3d-dev] Re: [ogl-sample] SGI SI GLU integration

[Olivier M. <Oli...@cy...>]

Brian Paul wrote:
> 
> Olivier Michel wrote:
> >
> > Hello,
> >
> > Sorry, I was off last week and I am just back from holidays reading my
> > 142 e-mails...
> > Apparently Dave commited a number of changes I requested. However, it is
> > apparently not yet complete (since the glu.h header is not yet fixed, it
> > still includes the OpenGL 1.0 compatibility lines), but I guess Dave is
> > currently working working on that...
> > Hence my RPM .spec file doesn't work yet from the CVS source (the glu.h
> > file still needs to be patched by hand). However, I can provide all what
> > I have:
> >
> > 1) The method to patch the glu.h and build the rpm from my modified
> > .spec file. This might be useful to build binary rpms for other
> > platforms. I will send them upon request.
> >
> > 2) The binary package for linux i386 (it is already available from
> > ftp://ftp.cyberbotics.com as mentioned in a previous e-mail, along with
> > a RPM package for Mesa without its GLU).
> >
> > Otherwise, we have to wait for Dave to fix the glu.h problem and to
> > add/merge my RPM .spec file to the CVS tree.
> >
> > I will rebuild the binary RPMs for linux i386 for both SGI SI GLU and
> > Mesa core GL (without GLU) as soon as Mesa-3.3 is out. However, I would
> > appreciate if they could be hosted somewhere else than on my ftp site
> > (since it cannot support high traffic).
> 
> You shouldn't have to wait for a Mesa release to put out the SI GLU
> package.

Sure. It is already available on ftp://ftp.cyberbotics.com and is not
likely to change when Mesa-3.3 is out. I will eventually rebuild it if
bug fixes are commited.

> I was hoping to release Mesa 3.2.1 and 3.3 this week but a last-minute
> bug regression in evaluators is postponing that, probably until after
> SIGGRAPH.  Dave's probably busy preparing for SIGGRAPH too.
> 
> So, I might be two weeks before we're all ready.

All right.

> > By the way, how should I name the final versions of those packages ?
> >
> > mesa-without-glu-3.3-1.i386.rpm and sgi-si-glu-1.3-1.i386.rpm, or simply
> > Mesa-3.3-1.i386.rpm and sgi-glu-1.3-1.i386.rpm ?
> 
> I prefer the later.

That's fine for me.

> > Another option could be to merge Mesa and SGI GLU into a single RPM
> > binary package named Mesa-with-sgi-glu-3.3-1.i386.rpm or simply
> > Mesa-3.3-1.i386.rpm (in this case, the RPM build process will be a bit
> > more tricky, but that's not a problem for me).
> 
> I'd rather keep the packages separate.  I expect that the GLU package
> won't be updated as often as Mesa.  Also, it would make the Mesa package
> smaller.
>
> > Personaly, I like the idea of the Mesa-3.3-1.i386.rpm containing
> > everything, but this might be conficting with other versions using Mesa
> > GLU. By the way, Brian, will you officially drop Mesa GLU, i.e., remove
> > it from Mesa distribution and recommanding to use SGI GLU instead ?
> 
> Yes, I'd like to drop Mesa's GLU at some point but I haven't worked
> out the details.
> 
> -Brian

It's not easy because the demos and examples need a GLU to work...

-Olivier

[Mesa3d-dev] Re: [ogl-sample] SGI SI GLU integration

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

Olivier Michel wrote:
> 
> Hello,
> 
> Sorry, I was off last week and I am just back from holidays reading my
> 142 e-mails...
> Apparently Dave commited a number of changes I requested. However, it is
> apparently not yet complete (since the glu.h header is not yet fixed, it
> still includes the OpenGL 1.0 compatibility lines), but I guess Dave is
> currently working working on that...
> Hence my RPM .spec file doesn't work yet from the CVS source (the glu.h
> file still needs to be patched by hand). However, I can provide all what
> I have:
> 
> 1) The method to patch the glu.h and build the rpm from my modified
> .spec file. This might be useful to build binary rpms for other
> platforms. I will send them upon request.
> 
> 2) The binary package for linux i386 (it is already available from
> ftp://ftp.cyberbotics.com as mentioned in a previous e-mail, along with
> a RPM package for Mesa without its GLU).
> 
> Otherwise, we have to wait for Dave to fix the glu.h problem and to
> add/merge my RPM .spec file to the CVS tree.
> 
> I will rebuild the binary RPMs for linux i386 for both SGI SI GLU and
> Mesa core GL (without GLU) as soon as Mesa-3.3 is out. However, I would
> appreciate if they could be hosted somewhere else than on my ftp site
> (since it cannot support high traffic).

You shouldn't have to wait for a Mesa release to put out the SI GLU
package.

I was hoping to release Mesa 3.2.1 and 3.3 this week but a last-minute
bug regression in evaluators is postponing that, probably until after
SIGGRAPH.  Dave's probably busy preparing for SIGGRAPH too.

So, I might be two weeks before we're all ready.


> By the way, how should I name the final versions of those packages ?
> 
> mesa-without-glu-3.3-1.i386.rpm and sgi-si-glu-1.3-1.i386.rpm, or simply
> Mesa-3.3-1.i386.rpm and sgi-glu-1.3-1.i386.rpm ?

I prefer the later.


> Another option could be to merge Mesa and SGI GLU into a single RPM
> binary package named Mesa-with-sgi-glu-3.3-1.i386.rpm or simply
> Mesa-3.3-1.i386.rpm (in this case, the RPM build process will be a bit
> more tricky, but that's not a problem for me).

I'd rather keep the packages separate.  I expect that the GLU package
won't be updated as often as Mesa.  Also, it would make the Mesa package
smaller.


> Personaly, I like the idea of the Mesa-3.3-1.i386.rpm containing
> everything, but this might be conficting with other versions using Mesa
> GLU. By the way, Brian, will you officially drop Mesa GLU, i.e., remove
> it from Mesa distribution and recommanding to use SGI GLU instead ?

Yes, I'd like to drop Mesa's GLU at some point but I haven't worked
out the details.

-Brian

[Mesa3d-dev] Re: [ogl-sample] SGI SI GLU integration

[Olivier M. <Oli...@cy...>]

Hello,

Sorry, I was off last week and I am just back from holidays reading my
142 e-mails...
Apparently Dave commited a number of changes I requested. However, it is
apparently not yet complete (since the glu.h header is not yet fixed, it
still includes the OpenGL 1.0 compatibility lines), but I guess Dave is
currently working working on that...
Hence my RPM .spec file doesn't work yet from the CVS source (the glu.h
file still needs to be patched by hand). However, I can provide all what
I have:

1) The method to patch the glu.h and build the rpm from my modified
.spec file. This might be useful to build binary rpms for other
platforms. I will send them upon request.

2) The binary package for linux i386 (it is already available from
ftp://ftp.cyberbotics.com as mentioned in a previous e-mail, along with
a RPM package for Mesa without its GLU).

Otherwise, we have to wait for Dave to fix the glu.h problem and to
add/merge my RPM .spec file to the CVS tree.

I will rebuild the binary RPMs for linux i386 for both SGI SI GLU and
Mesa core GL (without GLU) as soon as Mesa-3.3 is out. However, I would
appreciate if they could be hosted somewhere else than on my ftp site
(since it cannot support high traffic).

By the way, how should I name the final versions of those packages ?

mesa-without-glu-3.3-1.i386.rpm and sgi-si-glu-1.3-1.i386.rpm, or simply
Mesa-3.3-1.i386.rpm and sgi-glu-1.3-1.i386.rpm ?

Another option could be to merge Mesa and SGI GLU into a single RPM
binary package named Mesa-with-sgi-glu-3.3-1.i386.rpm or simply
Mesa-3.3-1.i386.rpm (in this case, the RPM build process will be a bit
more tricky, but that's not a problem for me).

Personaly, I like the idea of the Mesa-3.3-1.i386.rpm containing
everything, but this might be conficting with other versions using Mesa
GLU. By the way, Brian, will you officially drop Mesa GLU, i.e., remove
it from Mesa distribution and recommanding to use SGI GLU instead ?

-Olivier

Brian Paul wrote:
> 
> Olivier Michel wrote:
> >
> > Good news: It was a bit tricky, but I successfully built 2 RPM binary
> > packages (for i386)
> >
> >   ogl-sample-glu-1.3.04JUL00-1.i386.rpm and
> > mesa-without-glu-3.3.04JUL00-1.i386.rpm
> >
> > I am not sure the names and version numbering are fine, but that's just
> > a first trial.
> >
> > You may use rpm -Uvh with --nodeps or --force to get them installed
> > properly on differents Linux distros I could test it on Suze 6.4, Redhat
> > 6.0 and Slackware 7.0 and seemed to work properly: the tesselator
> > doesn't crash my app any more :)
> >
> > These packages are available at ftp://ftp.cyberbotics.com (you may also
> > download the other packages to test my app: webots).
> >
> > I finally found the real problem with building the SGI libGLU from the
> > current CVS:
> >
> > In the file glue.c, the functions
> >
> > static const char *__glNURBSErrorString( int errno )
> >
> > and
> >
> > static const char *__glTessErrorString( int errno )
> >
> > should not be defined as static because they are used by error.c. This
> > cause the libGLU.so doesn't work at runtime because it doesn't find
> > these functions called by error.c (which are local to glue.c).
> >
> > So, the fix is pretty simple: just remove the static keyword for these
> > two functions in glue.c
> >
> > Again, since I have no write access to the CVS, I hope someone could do
> > it for me.
> >
> > Moreover I had to hack the glu.h problem by hand.
> 
> Olivier,
> 
> What's the status on this project?
> 
> -Brian

Re: [Mesa3d-dev] Build error on current CVS (HEAD) [PATCH]

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

Richard Guenther wrote:
> 
> Hi!
> 
> I'm unable to build the current mesa on standard Linux/ix86:
> 
> ./configure --disable-ggi-fbdev
> 
> gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../include
> -I../../../src/GGI/include -I../../../src -g -O2 -Wall
> -fomit-frame-pointer -ffast-math -fexpensive-optimizations -malign-loops=2
> -malign-jumps=2 -malign-functions=2 -D_REENTRANT -Wp,-MD,.deps/stubs.pp -c
> stubs.c  -fPIC -DPIC -o stubs.lo
> stubs.c: In function `MesaGGIdl_stubs':
> stubs.c:415: `GGIFUNC_open' undeclared (first use in this function)
> stubs.c:415: (Each undeclared identifier is reported only once
> stubs.c:415: for each function it appears in.)
> stubs.c:418: `GGIFUNC_exit' undeclared (first use in this function)
> stubs.c:419: `GGIFUNC_close' undeclared (first use in this function)
> stubs.c:416: warning: unreachable code at beginning of switch statement
> make[4]: *** [stubs.lo] Error 1
> 
> It seems that though GGI seems to be detected disabled correctly:
> 
> checking for ggi/ggi.h... (cached) yes
> checking for main in -lggi... (cached) yes
> checking for kgi/kgi.h... (cached) no
> checking if we should build GGIMesa's fbdev target... no
> checking if we should build GGIMesa's generic KGI driver... no
> 
> (but ggi.h installed) is is tried to use it - as I can see from
> conf.h GGI is enabled...
> 
> /* #undef FX */
> /* #undef FX_GLIDE3 */
> #define GGI 1
> #define SVGA 1
> #define USE_XSHM 1
> 
> so perhaps we need a --disable-ggi switch... [see attached patch]
> also --disable-svga should be there for the same reasons (well I
> would vote for all but X11 and GLX drivers to be disabled by default
> and to be enabled by --enable-feature rather than autodetecting such
> stuff anyway).
> 
> Note that the patch includes addition of -fstrict-aliasing as this
> enables a whole range of optimizations of array access and friends
> and makes a huge difference (just checked that here on IRIX) - I hope
> Mesa is safe with the aliasing rules of ANSI C.... at least it seems
> to work with the supplied demos (just picked a few random ones).
> 
> Richard.
> 
> --
> Richard Guenther <ric...@st...>
> WWW: http://www.anatom.uni-tuebingen.de/~richi/
> The GLAME Project: http://www.glame.de/
> 
> Index: configure.in
> ===================================================================
> RCS file: /cvsroot/mesa3d/Mesa/configure.in,v
> retrieving revision 1.27
> diff -u -r1.27 configure.in
> --- configure.in        2000/07/01 08:22:08     1.27
> +++ configure.in        2000/07/19 11:27:18
> @@ -77,7 +77,7 @@
>    dnl Optimization flags
>    if test "x$enable_debug" = xno && test "x$enable_prof" = xno; then
>      if test "x$GCC" = xyes; then
> -      CFLAGS="$CFLAGS -fomit-frame-pointer -ffast-math -fexpensive-optimizations"
> +      CFLAGS="$CFLAGS -fomit-frame-pointer -ffast-math -fexpensive-optimizations -fstrict-aliasing"
>        case "$host" in
>        i*86-*-*) CFLAGS="$CFLAGS -malign-loops=2 -malign-jumps=2 -malign-functions=2";;
>        esac
> @@ -299,7 +299,12 @@
> 
>  dnl ------------------------------------------
>  dnl GGI driver
> -have_ggi=auto
> +AC_ARG_ENABLE(ggi,
> +[  --disable-ggi           Don't build the GGI target at all],
> +have_ggi=$enableval, have_ggi=auto)
> +if test "x$have_ggi" = xyes; then
> +       have_ggi=auto;
> +fi
>  GGI_CFLAGS=""
>  GGI_LIBS=""
>  AC_ARG_WITH(ggi,


OK, I've applied your patch to both the 3.2.1 and 3.3 branches.
But, I removed the -fstrict-aliasing option from 3.2.1 just to be
cautious.  I always avoid pointer aliasing in function calls but
can't guarantee that in anybody else's code.

-Brian

Re: [Mesa3d-dev] Minor Mesa demo bug.

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

Bill White wrote:
> 
> The function ShowDepthBuffer disables depth and stencil testing.  However,
> it doesn't include GL_ENABLE_BIT in its bitmask for glPushAttrib.  This
> means that the depth and stencil testing is inadvertently disabled by
> ShowDepthBuffer.  You can't see it in reflect, since the depth test is
> enabled there explicitly.  If you put a ShowDepthBuffer into gears, look
> at the depth buffer, and then look at the color buffer, it displays
> incorrectly.
> 
> I'm assuming that the stencil enabled state is not part of the state saved
> by GL_DEPTH_BUFFER_BIT in glPushAttrib.  The spec is not clear about
> this, at least to my reading.  The Stencil enabled state is saved and
> restored by glPushAttrib/glPopAttrib, with the GL_STENCIL_BUFFER_BIT.
> Several other state enabled/disabled bits are enabled both by GL_ENABLE_BIT
> and GL_MUMBLE_BIT.
> 
> In any case, the fix is trivial.  Either include GL_ENABLE_BIT in
> ShowDepthBuffer,
> or else restore the depth enabled state in _mesa_PopAttrib.  The depth enabled
> state is stored with _mesa_PushAttrib, so restoring it is possible.

OK, I'm about to check in the fix to attrib.c.  When popping the
GL_DEPTH_BUFFER_BIT state, I call ctx->Driver.Enable to restore the
depth test enable/disable state.

-Brian

[Mesa3d-dev] Minor Mesa demo bug.

[Bill W. <bil...@gr...>]

The function ShowDepthBuffer disables depth and stencil testing.  However,
it doesn't include GL_ENABLE_BIT in its bitmask for glPushAttrib.  This
means that the depth and stencil testing is inadvertently disabled by
ShowDepthBuffer.  You can't see it in reflect, since the depth test is
enabled there explicitly.  If you put a ShowDepthBuffer into gears, look
at the depth buffer, and then look at the color buffer, it displays
incorrectly.

I'm assuming that the stencil enabled state is not part of the state saved
by GL_DEPTH_BUFFER_BIT in glPushAttrib.  The spec is not clear about
this, at least to my reading.  The Stencil enabled state is saved and
restored by glPushAttrib/glPopAttrib, with the GL_STENCIL_BUFFER_BIT.
Several other state enabled/disabled bits are enabled both by GL_ENABLE_BIT
and GL_MUMBLE_BIT.

In any case, the fix is trivial.  Either include GL_ENABLE_BIT in 
ShowDepthBuffer,
or else restore the depth enabled state in _mesa_PopAttrib.  The depth enabled
state is stored with _mesa_PushAttrib, so restoring it is possible.

[Mesa3d-dev] Build error on current CVS (HEAD) [PATCH]

[Richard G. <ric...@st...>]

Hi!

I'm unable to build the current mesa on standard Linux/ix86:

./configure --disable-ggi-fbdev

gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../include
-I../../../src/GGI/include -I../../../src -g -O2 -Wall
-fomit-frame-pointer -ffast-math -fexpensive-optimizations -malign-loops=2
-malign-jumps=2 -malign-functions=2 -D_REENTRANT -Wp,-MD,.deps/stubs.pp -c
stubs.c  -fPIC -DPIC -o stubs.lo
stubs.c: In function `MesaGGIdl_stubs':
stubs.c:415: `GGIFUNC_open' undeclared (first use in this function)
stubs.c:415: (Each undeclared identifier is reported only once
stubs.c:415: for each function it appears in.)
stubs.c:418: `GGIFUNC_exit' undeclared (first use in this function)
stubs.c:419: `GGIFUNC_close' undeclared (first use in this function)
stubs.c:416: warning: unreachable code at beginning of switch statement
make[4]: *** [stubs.lo] Error 1

It seems that though GGI seems to be detected disabled correctly:

checking for ggi/ggi.h... (cached) yes
checking for main in -lggi... (cached) yes
checking for kgi/kgi.h... (cached) no
checking if we should build GGIMesa's fbdev target... no
checking if we should build GGIMesa's generic KGI driver... no

(but ggi.h installed) is is tried to use it - as I can see from
conf.h GGI is enabled...

/* #undef FX */
/* #undef FX_GLIDE3 */
#define GGI 1
#define SVGA 1
#define USE_XSHM 1

so perhaps we need a --disable-ggi switch... [see attached patch]
also --disable-svga should be there for the same reasons (well I
would vote for all but X11 and GLX drivers to be disabled by default
and to be enabled by --enable-feature rather than autodetecting such
stuff anyway).

Note that the patch includes addition of -fstrict-aliasing as this
enables a whole range of optimizations of array access and friends
and makes a huge difference (just checked that here on IRIX) - I hope
Mesa is safe with the aliasing rules of ANSI C.... at least it seems
to work with the supplied demos (just picked a few random ones).

Richard.

--
Richard Guenther <ric...@st...>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/


Index: configure.in
===================================================================
RCS file: /cvsroot/mesa3d/Mesa/configure.in,v
retrieving revision 1.27
diff -u -r1.27 configure.in
--- configure.in	2000/07/01 08:22:08	1.27
+++ configure.in	2000/07/19 11:27:18
@@ -77,7 +77,7 @@
   dnl Optimization flags
   if test "x$enable_debug" = xno && test "x$enable_prof" = xno; then
     if test "x$GCC" = xyes; then
-      CFLAGS="$CFLAGS -fomit-frame-pointer -ffast-math -fexpensive-optimizations"
+      CFLAGS="$CFLAGS -fomit-frame-pointer -ffast-math -fexpensive-optimizations -fstrict-aliasing"
       case "$host" in
       i*86-*-*) CFLAGS="$CFLAGS -malign-loops=2 -malign-jumps=2 -malign-functions=2";;
       esac     
@@ -299,7 +299,12 @@
 
 dnl ------------------------------------------
 dnl GGI driver
-have_ggi=auto
+AC_ARG_ENABLE(ggi,
+[  --disable-ggi           Don't build the GGI target at all],
+have_ggi=$enableval, have_ggi=auto)
+if test "x$have_ggi" = xyes; then
+	have_ggi=auto;
+fi
 GGI_CFLAGS=""
 GGI_LIBS=""
 AC_ARG_WITH(ggi,

[Mesa3d-dev] OpenGL meetings at SIGGRAPH

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

The OpenGL Special Interest Group meeting will be held on Wednesday,
July 26 from 6:30pm to 8:00pm in the Hilton Hotel's Napoleon Room.
See www.opengl.org for a short agenda.


The Linux/OpenGL Birds of a Feather meeting will be held on Thursday,
July 27 from 6:30pm to 8:00pm in the Hilton's Riverside Versaille Ballroom.
Daryll Strauss is organizing it.  Here's his original announcement:

  We're doing our 3rd Linux 3D BOF at SIGGRAPH on Thursday evening this
  year. If you or anyone else from your company is interested in giving
  a brief (5 minute) presentation on your Linux support, we'd love to
  have you. Drop us a note at lin...@li.... You can find the
  announcement for the event at http://www.linux3d.org/s2000bof.html.

                                                - |Daryll


I'll attend both meetings and will give Mesa status updates.

-Brian

[Mesa3d-dev] [RFC] MESA_texture_env_combine2 extension

[Holger W. <hwa...@ya...>]

Hi everybody,

I attached a preliminary spec for a MESA_texture_env_combine2 extension,
which adds some new modes including dot3 modes for perpixel lighting on
top of EXT_texture_env_combine.

Now I'd like to get some comments from people who have access to hardware 
specs (and from those who have to use the extension ...). Modes, which
don't map on any known card make no sense.

In the mesa_3_3_texture_env_combine2 branch a experimental implementation
of the extension is available via CVS. A perpixel demo, which does
ambient, diffuse and specular lighting using the new modes in 2 passes and
one CopyPixels call (for specular color lookup) is included. Some
screenshots and the demo source you find at

    http://www.informatik.hu-berlin.de/~waechtle/mesa

However, to get it working, you have to check out the
MESA_texture_env_combine2 branch.

- Holger