mesa3d-dev

[Mesa3d-dev] Re: [Mesa3d-cvs] CVS Update: Mesa (branch: trunk)

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

Jacob Jansen wrote:
> 
> CVSROOT:        /cvsroot/mesa3d
> Module name:    Mesa
> Repository:     Mesa/src-glut/
> Changes by:     joukj@usw-pr-cvs1.      01/03/22 03:38:37
> 
> Log message:
>    Modified Files:
>         Mesa/descrip.mms Mesa/mms-config Mesa/demos/descrip.mms
>         Mesa/si-glu/include/gluos.h
>         Mesa/si-glu/libnurbs/internals/bufpool.h
>         Mesa/si-glu/libnurbs/internals/mysetjmp.h
>         Mesa/src-glut/descrip.mms
>    Added Files:
>         Mesa/si-glu/descrip.mms Mesa/si-glu/mesaglu.opt
> 
>    changes needed to compile SI-GLU on VMS.

You should forward your changes to the OpenGL SI group at SGI.

I really want to keep the GLU code in Mesa synchronized to the SGI SI
code as closely as possible.

Thanks.

-Brian

[Mesa3d-dev] Re: [Mesa3d-users] configure problem (was Missing GLX extensions)

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

On Wed, Mar 21, 2001 at 01:44:31PM +0100, Dirk Reiners wrote:
> On Mar 20,  6:31pm, Sven M. Hallberg wrote:
> > Subject: Re: [Mesa3d-users] configure problem (was Missing GLX
> extensions)
> >
> > Oh, that's ugly. As far as a quick grep indicated the identifier 'quad'
> is
> > used in a number of places. It would probably be pretty painful to wade
> > through all the source files to eliminate every occurance.
> >
> > Do you have any way of preventing bsd_types.h from being included or
> quad from
> > being defined in it?
> 
> It's not really that bad. It's not actually DEFINEd, it's just a typedef.
> I just changed it in ss_tritmp.h and could compile everything. As for
> avoiding it: it's unconditionally included from sys/types.h, and I guess
> that one's is definitely needed.

Well I guess we'll just change it there for now and leave everything
else untouched unless it becomes a problem.


> > Well, if the compiler doesn't support the feature the only way would be
> to use
> > some sort of preprocessor kludge or hard-code the function names. Both
> options
> > seem kind of hard to accept. I'd say we check for the feature and in
> case it's
> > not available #define __FUNCTION__ to something sensable expressing the
> lack.
> 
> It does support __FILE__ and __LINE__, maybe using these would be better
> than not having any indications of the problem happened.

Right. Are those two preprocessor macros or real variables?


> The new common_rules.make has a bug in that it uses spaces instead of tabs
> for the new rules, make doesn't like that.

Argh. Happens when copy-and-pasting from an xterm... Fixed.


> Some Makefiles use the linker option -no-install, Irix doesn't know that
> one. I don't know what the purpose of that option is, maybe it can just be
> removed.

Hehe. I've noticed that flag, too. Actually asked about it's purpose on
mesa3d-dev. Generates a warning on my system, so I'm ignoring it until someone
tells me I can safely remove it (*wink*).


> I tried making and running a demo from all the different demo directories.
> Compiling works, but they didn't run. Apparently somewhere in si-glu C++
> streams are used. I couldn't actually find it, but the library contains
> undefined references to symbols that are used in that context (__dl__GPv,
> __iob, __vtbl__9type_info, __pure_virtual_called). Adding -lCio to the
> link line fixes that.

libCio? Never heard of that. And what does it have to do with C++ streams?
Can you give me a description of the circumstances under which this library is
needed so I can model a proper check for it? It's not available on my machine.


> The last thing I found is tests/. The Makefile there doesn't use automake
> yet, and wants to use gcc hardcoded. Don't know how important that is.

The comment in the Makefile says that these are not supposed to go into the
distribution, so I'll leave them out of autoconf/automake for now.


> Hope it helps

Oh it does.


Regards,
@SVEN_M_HALLBERG@ <$(pesco_gmx.de)>
-- 
"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] Re: [Mesa3d-users] configure problem (was Missing GLX extensions)

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

Dirk Reiners wrote:
> 
> OK, next iteration. :)
> 
> On Mar 20,  6:31pm, Sven M. Hallberg wrote:
> > Subject: Re: [Mesa3d-users] configure problem (was Missing GLX
> extensions)
> >
> > Oh, that's ugly. As far as a quick grep indicated the identifier 'quad'
> is
> > used in a number of places. It would probably be pretty painful to wade
> > through all the source files to eliminate every occurance.
> >
> > Do you have any way of preventing bsd_types.h from being included or
> quad from
> > being defined in it?
> 
> It's not really that bad. It's not actually DEFINEd, it's just a typedef.
> I just changed it in ss_tritmp.h and could compile everything. As for
> avoiding it: it's unconditionally included from sys/types.h, and I guess
> that one's is definitely needed.
> 
> > Well, if the compiler doesn't support the feature the only way would be
> to use
> > some sort of preprocessor kludge or hard-code the function names. Both
> options
> > seem kind of hard to accept. I'd say we check for the feature and in
> case it's
> > not available #define __FUNCTION__ to something sensable expressing the
> lack.
> 
> It does support __FILE__ and __LINE__, maybe using these would be better
> than not having any indications of the problem happened.
> 
> > Hm, seems something messed up here. Fixed two minor mistakes, but I
> don't see
> > how these could have caused glut not being built at all:
> >         * Makefile.am: Added src-glut to DIST_SUBDIRS.
> >         * src-glut/Makefile.am: Removed NEED_GLUT check for good.
> >
> > I assume you don't have another GLUT already installed, do you? In that
> case
> > the configure script will use that library instead of the one supplied
> with
> > Mesa. Look for a warning message from configure. You can tell configure
> not to
> > look for an external GLUT using --without-glut.
> 
> OK, looks like that was the problem. I do have another GLUT somewhere,
> --without-glut worked.
> 
> >-- End of excerpt from Sven M. Hallberg
> 
> Nearly.
> 
> The new common_rules.make has a bug in that it uses spaces instead of tabs
> for the new rules, make doesn't like that.
> 
> Some Makefiles use the linker option -no-install, Irix doesn't know that
> one. I don't know what the purpose of that option is, maybe it can just be
> removed.
> 
> Now everything makes. Woohoo! ;)
> 
> I tried making and running a demo from all the different demo directories.
> Compiling works, but they didn't run. Apparently somewhere in si-glu C++
> streams are used. I couldn't actually find it, but the library contains
> undefined references to symbols that are used in that context (__dl__GPv,
> __iob, __vtbl__9type_info, __pure_virtual_called). Adding -lCio to the
> link line fixes that.
> 
> The last thing I found is tests/. The Makefile there doesn't use automake
> yet, and wants to use gcc hardcoded. Don't know how important that is.

The programs under tests/ aren't included in the Mesa distro.  They're
only intended for us developers.  The makefiles aren't too important.

-Brian

[Mesa3d-dev] Re: [Mesa3d-users] configure problem (was Missing GLX extensions)

[Dirk R. <re...@ig...>]

OK, next iteration. :)

On Mar 20,  6:31pm, Sven M. Hallberg wrote:
> Subject: Re: [Mesa3d-users] configure problem (was Missing GLX
extensions)
>
> Oh, that's ugly. As far as a quick grep indicated the identifier 'quad'
is
> used in a number of places. It would probably be pretty painful to wade
> through all the source files to eliminate every occurance.
>
> Do you have any way of preventing bsd_types.h from being included or
quad from
> being defined in it?

It's not really that bad. It's not actually DEFINEd, it's just a typedef.
I just changed it in ss_tritmp.h and could compile everything. As for
avoiding it: it's unconditionally included from sys/types.h, and I guess
that one's is definitely needed.

> Well, if the compiler doesn't support the feature the only way would be
to use
> some sort of preprocessor kludge or hard-code the function names. Both
options
> seem kind of hard to accept. I'd say we check for the feature and in
case it's
> not available #define __FUNCTION__ to something sensable expressing the
lack.

It does support __FILE__ and __LINE__, maybe using these would be better
than not having any indications of the problem happened.

> Hm, seems something messed up here. Fixed two minor mistakes, but I
don't see
> how these could have caused glut not being built at all:
>         * Makefile.am: Added src-glut to DIST_SUBDIRS.
>         * src-glut/Makefile.am: Removed NEED_GLUT check for good.
>
> I assume you don't have another GLUT already installed, do you? In that
case
> the configure script will use that library instead of the one supplied
with
> Mesa. Look for a warning message from configure. You can tell configure
not to
> look for an external GLUT using --without-glut.

OK, looks like that was the problem. I do have another GLUT somewhere,
--without-glut worked.

>-- End of excerpt from Sven M. Hallberg

Nearly.

The new common_rules.make has a bug in that it uses spaces instead of tabs
for the new rules, make doesn't like that.

Some Makefiles use the linker option -no-install, Irix doesn't know that
one. I don't know what the purpose of that option is, maybe it can just be
removed.

Now everything makes. Woohoo! ;)

I tried making and running a demo from all the different demo directories.
Compiling works, but they didn't run. Apparently somewhere in si-glu C++
streams are used. I couldn't actually find it, but the library contains
undefined references to symbols that are used in that context (__dl__GPv,
__iob, __vtbl__9type_info, __pure_virtual_called). Adding -lCio to the
link line fixes that.

The last thing I found is tests/. The Makefile there doesn't use automake
yet, and wants to use gcc hardcoded. Don't know how important that is.

Hope it helps

	Dirk

-- 
--
-- Dirk Reiners             re...@ig..., Dir...@gm... 
-- OpenSG Forum                                http://www.opensg.org
-- Rundeturmstrasse 6                 http://www.igd.fhg.de/~reiners
-- D-64283 Darmstadt                 All standard disclaimers apply. 
-- Truth is stranger than fiction because fiction has to make sense. 

Re: [Mesa3d-dev] new glu.h

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

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi all,
> 
> I just noticed that the "old" glu does not compile with the new glu.h.
> IMHO we should not try to get the old source compiled with the new one. Maybe
> when someone has no c++ compiiler the old glu.h should be copied over the
> new one. The configure script and/or the makefiles should be able to detect the need of this copy.

I've made a few modifications to the old src-glu/ code to make it compile
with the new glu.h header.  I'll check it in soon.

-Brian

[Mesa3d-dev] Re: [Mesa3d-users] configure problem (was Missing GLX extensions)

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

On Tue, Mar 20, 2001 at 04:55:24PM +0100, Dirk Reiners wrote:
> 1) src/array_cache/libMesaAC_la_SOURCES was missing, I recreated it as
> shown in the attachment, I hope that's right. At least it compiles. ;)
Completely correct. I had forgotten to add it to the repository. Fixed now.


> 2) cc-1101 cc: ERROR File = ss_tritmp.h, Line = 159
>   "quad" has already been declared in the current scope.
> 
>   static void TAG(quad)( GLcontext *ctx, GLuint v0,
>               ^
> quad is already defined in bsd_types.h. Renaming quad to quadfunc in
> ss_tritmp.h fixed that.

Oh, that's ugly. As far as a quick grep indicated the identifier 'quad' is
used in a number of places. It would probably be pretty painful to wade
through all the source files to eliminate every occurance.

Do you have any way of preventing bsd_types.h from being included or quad from
being defined in it?


> 3) texutil_tmp.h : __FUNCTION__ undefined
> Irix CC doesn't define __FUNCTION__. I just killed it by #defining it to
> nothing, but that's not a solution.

Well, if the compiler doesn't support the feature the only way would be to use
some sort of preprocessor kludge or hard-code the function names. Both options
seem kind of hard to accept. I'd say we check for the feature and in case it's
not available #define __FUNCTION__ to something sensable expressing the lack.


> 4) si-glu still used the old ,-MD, for dependencies. Adding the rules for
> %.o: %.cc and %.lo: %.cc to common_rules.make fixed that (see attachment).

Oh yeah, missed that one, Fixed.


> Doing that it apparently compiled, but didn't create the GLUT lib. gmake
> all in src-glut does nothing. No idea whats' wrong here?!? Thus I'm not
> sure what else it didn't make and I can't run tests or demos.

Hm, seems something messed up here. Fixed two minor mistakes, but I don't see
how these could have caused glut not being built at all:
        * Makefile.am: Added src-glut to DIST_SUBDIRS.
        * src-glut/Makefile.am: Removed NEED_GLUT check for good.

I assume you don't have another GLUT already installed, do you? In that case
the configure script will use that library instead of the one supplied with
Mesa. Look for a warning message from configure. You can tell configure not to
look for an external GLUT using --without-glut.


Thanks for the feedback,
@SVEN_M_HALLBERG@ <$(pesco_gmx.de)>
-- 
"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] Re: [Mesa3d-users] configure problem (was Missing GLX extensions)

[Dirk R. <re...@ig...>]

On Mar 20,  2:04am, Sven M. Hallberg wrote:
>
> Dirk: Can you check out Mesa 3.5 and see if it compiles on your Irix
machine
> now?
>
>-- End of excerpt from Sven M. Hallberg

Getting closer. After checking out the current CVS I called bootstrap,
configure and gmake all. The following problems came up:

1) src/array_cache/libMesaAC_la_SOURCES was missing, I recreated it as
shown in the attachment, I hope that's right. At least it compiles. ;)

2) cc-1101 cc: ERROR File = ss_tritmp.h, Line = 159
  "quad" has already been declared in the current scope.

  static void TAG(quad)( GLcontext *ctx, GLuint v0,
              ^
quad is already defined in bsd_types.h. Renaming quad to quadfunc in
ss_tritmp.h fixed that.

3) texutil_tmp.h : __FUNCTION__ undefined
Irix CC doesn't define __FUNCTION__. I just killed it by #defining it to
nothing, but that's not a solution.

4) si-glu still used the old ,-MD, for dependencies. Adding the rules for
%.o: %.cc and %.lo: %.cc to common_rules.make fixed that (see attachment).

Doing that it apparently compiled, but didn't create the GLUT lib. gmake
all in src-glut does nothing. No idea whats' wrong here?!? Thus I'm not
sure what else it didn't make and I can't run tests or demos.

I need a hint what to do now...

Thanks

	Dirk



-- 
--
-- Dirk Reiners             re...@ig..., Dir...@gm... 
-- OpenSG Forum                                http://www.opensg.org
-- Rundeturmstrasse 6                 http://www.igd.fhg.de/~reiners
-- D-64283 Darmstadt                 All standard disclaimers apply. 
-- Truth is stranger than fiction because fiction has to make sense. 

Re: [Mesa3d-dev] Software textured triangle funcs

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

Gareth Hughes wrote:
> 
> Brian, what do you want to do about the triangle functions that are
> doing things like:
> 
>    ...
>    const GLchan *texture = (const GLchan *) obj->Image[b]->Data;
>    ...
>    rgb[i][RCOMP] = texture[pos];
>    rgb[i][GCOMP] = texture[pos+1];
>    rgb[i][BCOMP] = texture[pos+2];
>    ...
> 
> A quick inspection indicates at least simple_textured_triangle(),
> simple_z_textured_triangle() and affine_textured_triangle() in
> swrast/s_triangle.c are all guilty of this.

Those triangle functions should only be chosen if the texture is
GL_RGB (or GL_RGBA) with GLubyte components.  The "choose" function
should make all the necessary checks.

-Brian

Re: [Mesa3d-dev] new glu.h

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

On Tue, Mar 20, 2001 at 11:37:24AM +0100, Jacob (=Jouk) Jansen wrote:
> Hi all,
> 
> I just noticed that the "old" glu does not compile with the new glu.h.
> IMHO we should not try to get the old source compiled with the new one. Maybe
> when someone has no c++ compiiler the old glu.h should be copied over the
> new one. The configure script and/or the makefiles should be able to detect
> the need of this copy.

As far as autoconf is concerned, I don't see any problem with such a solution.
Let me propose this approach:

We take the GLU header files out of include/GL/.

We make seperate subdirs for them in their respective GLU source directory.
For instance si-glu/syshdrs/GL/ and src-glu/syshdrs/GL/.

Because we cannot assume the two sets of GLU system headers to be identical,
provide two distinct install mechanisms for each of them. In the case of
autoconf/automake I would list them in glinclude_HEADERS in the approrpiate
Makefile.am's.

In order to use them at build time it's probably easiest to copy the
appropriate set into include/GL.


Regards,
@SVEN_M_HALLBERG@ <$(pesco_gmx.de)>

-- 
"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] new glu.h

[<jo...@hr...>]

Hi all,

I just noticed that the "old" glu does not compile with the new glu.h.
IMHO we should not try to get the old source compiled with the new one. Maybe
when someone has no c++ compiiler the old glu.h should be copied over the
new one. The configure script and/or the makefiles should be able to detect the need of this copy.

               Jouk


Bush : All votes are equal but some votes are more equal than others.

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

  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

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

[Mesa3d-dev] Software textured triangle funcs

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

Brian, what do you want to do about the triangle functions that are
doing things like:

   ...
   const GLchan *texture = (const GLchan *) obj->Image[b]->Data;
   ...
   rgb[i][RCOMP] = texture[pos];
   rgb[i][GCOMP] = texture[pos+1];
   rgb[i][BCOMP] = texture[pos+2];
   ...

A quick inspection indicates at least simple_textured_triangle(),
simple_z_textured_triangle() and affine_textured_triangle() in
swrast/s_triangle.c are all guilty of this.

-- Gareth

[Mesa3d-dev] Re: [Mesa3d-users] configure problem (was Missing GLX extensions)

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

On Mon, Mar 19, 2001 at 09:21:00AM -0700, Brian Paul wrote:
> > Using that the Makefile error goes away, but you still can't compile on
> > Irix. The compiler flag to update dependencies on Irix is '-MDupdate', not
> > '-MD'. I don't know anything about autoconf, so I don't know how to change
> > the configure parts, but just replacing -MD with -MDupdate in all
> > Makefile.in files makes it work. I just don't know if that also works on
> > Linux, can somebody try that? If not, can somebody who knows a little more
> > about autoconf/configure add that as a platform-dependent option?

I've finished this in the CVS trunk (Mesa 3.5). The configure script now
checks a platform-dependent list of possible dependency update switches to
find one that works. If it finds one that is not -MD it overrides the
normal build rules generated by automake. These rules are held in the file
$(top_srcdir)/common_rules.make which every Makefile.am includes.

Unfortunately there is no way to dynamically turn of dependency tracking
alltogether because automake hard-codes it into the build rules. This means
if the configure script doesn't find a way to do dependency tracking but you
need it (probably because you're building from CVS - dependency information
is removed in the distribution package) the build process will blow.

Dirk: Can you check out Mesa 3.5 and see if it compiles on your Irix machine
now?

Hope this helped,
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] -no-install LDFLAG in demo dirs

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

I just stumbled across this:

In the subdirs book/, samples/, and xdemos/ the Makefile.am's each specify
an LDFLAG of -no-install. My gcc reports
gcc: unrecognized option `-no-install'.
The option is also present in demos/, but the line has been commented out.

Can anyone tell me what this option was intended for?

-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] SGI SI GLU library

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

On Mon, Mar 19, 2001 at 10:03:02AM -0700, Brian Paul wrote:
> > I'll look for the SI myself, but can you give me an email address just in case?
> > I'd like to contact them about the above two issues.
> 
> See http://oss.sgi.com/projects/ogl-sample/
> 
> >From the SI CVS tree, I basically copied the contents of ogl-sample/main/gfx/lib/glu/

Yes, I've looked at the site you mention. I've dropped the idea of
autoconfiscating the SI GLU because it's too entangled with the rest of the SI,
namely the GLU headers are included elsewhere (both in Mesa and the SI) plus
the SI even autogenerates them by means of some other tool.

Oh well, it works just as well without its own configure script.

-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] SGI SI GLU library

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

"Sven M. Hallberg" wrote:
> 
> On Mon, Mar 19, 2001 at 08:13:26AM -0700, Brian Paul wrote:
> > "Sven M. Hallberg" wrote:
> > >
> > > On Fri, Mar 16, 2001 at 06:03:58PM -0700, Brian Paul wrote:
> > > >
> > > > I've added the SGI SI GLU library code to Mesa CVS.  It's in the si-glu/
> > > > directory.  You can get it with 'cvs up -d'.
> > > >
> > > > I've updated the "old-style" makefiles (Makefile.X11 and Make-config) to
> > > > compile it.  I'd appreciate it if someone would add the autoconfig files
> > > > needed to compile it with ./configure;make.
> > >
> > > Done. However, it didn't compile on my system at first. The problem was that
> > > glimports.h, mystdio.h, and mystdlib.h were used in some subdirs of libnurbs
> > > while being present only in (multiple!) others. Since the files in the
> > > different subdirs were identical I've pulled them all out into si-glu/libnurbs/
> > > itself and added that to the include path in Makefile.X11. That okay, or should
> > > they go into one of si-glu/libnurbs' subdirs?
> >
> > I was hoping that we wouldn't have to change any of the sources.  That
> > makes it hard to stay synchronized with the OpenGL SI CVS tree.  The SI
> > GLU compiled fine for me without any changes.  Why can't we do the same
> > thing with autoconfig?
> 
> Oh, I wasn't aware there even was a SI CVS tree we're synchronized with. Sorry
> about that, will revert to the old style. However I believe it _is_ sort of
> ugly to have these files duplicated in some dirs. Maybe we should ask the SI
> people about it, my guess would be that they'd agree and change it themselves.
> :) For now, I'll revert the change and modify the Makefile templates to
> find the files, which is of course possible (after all just a matter of an -I).
> 
> I take it the si-glu dir is a direct copy of the SI CVS tree? In that case I'll
> try giving it it's very own configure script and calling that from the
> top-level configure. That way the mechanism could even be incorporated into
> the SI itself.
> 
> I'll look for the SI myself, but can you give me an email address just in case?
> I'd like to contact them about the above two issues.

See http://oss.sgi.com/projects/ogl-sample/

From the SI CVS tree, I basically copied the contents of ogl-sample/main/gfx/lib/glu/


> > > > The SI GLU requires C++ to compile it.  This may be a problem on some
> > > > systems.  I guess I'll continue to include the old src-glu/ code for
> > > > the sake of those systems.
> > >
> > > I've made configure.in so it checks for a C++ compiler and uses si-glu if it
> > > finds one, src-glu otherwise. Should I add a configure switch to specifically
> > > enable/disable it, too?
> >
> > Doesn't matter to me.
> 
> Okay, I'll leave it out because I guess the SI is supposed to replace the Mesa
> GLU if possible right?

Right.  The only reason people should use the old GLU code is if they don't
have a C++ compiler.

-Brian

Re: [Mesa3d-dev] SGI SI GLU library

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

On Mon, Mar 19, 2001 at 08:13:26AM -0700, Brian Paul wrote:
> "Sven M. Hallberg" wrote:
> > 
> > On Fri, Mar 16, 2001 at 06:03:58PM -0700, Brian Paul wrote:
> > >
> > > I've added the SGI SI GLU library code to Mesa CVS.  It's in the si-glu/
> > > directory.  You can get it with 'cvs up -d'.
> > >
> > > I've updated the "old-style" makefiles (Makefile.X11 and Make-config) to
> > > compile it.  I'd appreciate it if someone would add the autoconfig files
> > > needed to compile it with ./configure;make.
> > 
> > Done. However, it didn't compile on my system at first. The problem was that
> > glimports.h, mystdio.h, and mystdlib.h were used in some subdirs of libnurbs
> > while being present only in (multiple!) others. Since the files in the
> > different subdirs were identical I've pulled them all out into si-glu/libnurbs/
> > itself and added that to the include path in Makefile.X11. That okay, or should
> > they go into one of si-glu/libnurbs' subdirs?
> 
> I was hoping that we wouldn't have to change any of the sources.  That
> makes it hard to stay synchronized with the OpenGL SI CVS tree.  The SI
> GLU compiled fine for me without any changes.  Why can't we do the same
> thing with autoconfig?

Oh, I wasn't aware there even was a SI CVS tree we're synchronized with. Sorry
about that, will revert to the old style. However I believe it _is_ sort of
ugly to have these files duplicated in some dirs. Maybe we should ask the SI
people about it, my guess would be that they'd agree and change it themselves.
:) For now, I'll revert the change and modify the Makefile templates to
find the files, which is of course possible (after all just a matter of an -I).

I take it the si-glu dir is a direct copy of the SI CVS tree? In that case I'll
try giving it it's very own configure script and calling that from the
top-level configure. That way the mechanism could even be incorporated into
the SI itself.

I'll look for the SI myself, but can you give me an email address just in case?
I'd like to contact them about the above two issues.

> > > The SI GLU requires C++ to compile it.  This may be a problem on some
> > > systems.  I guess I'll continue to include the old src-glu/ code for
> > > the sake of those systems.
> > 
> > I've made configure.in so it checks for a C++ compiler and uses si-glu if it
> > finds one, src-glu otherwise. Should I add a configure switch to specifically
> > enable/disable it, too?
> 
> Doesn't matter to me.

Okay, I'll leave it out because I guess the SI is supposed to replace the Mesa
GLU if possible right?


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] 3.5 texture formats

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

Gareth Hughes wrote:
> 
> Brian, I finished off the port of the 3.4 texture utils and format work
> this evening.  I think the overall design is clean and fits in well with
> your FetchTexel work from a while back.  Please let me know if you have
> any comments or issues with the work.  There may be a little fine tuning
> with the utilities, but I'll leave that until the trunk is merged into
> the mesa-3-5 branch this week.

I'll try to look over the new code this week.  I'll let you know if I
have any issues.

Thanks.

-Brian

Re: [Mesa3d-dev] security vulnerabilities

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

Gareth Hughes wrote:
> 
> Keith Whitwell wrote:
> >
> > Apparently there's been a security vulnerability posted for current or
> > near-current mesa.  Does anyone know anything about this?
> 
> Where did you hear that?

LWN.  Actually it turns out to be Utah-glx, not Mesa...  The /tmp/glxmemory
file, I think.

Keith

Re: [Mesa3d-dev] security vulnerabilities

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

Keith Whitwell wrote:
> 
> Apparently there's been a security vulnerability posted for current or
> near-current mesa.  Does anyone know anything about this?

Where did you hear that?

-- Gareth

[Mesa3d-dev] security vulnerabilities

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

Apparently there's been a security vulnerability posted for current or
near-current mesa.  Does anyone know anything about this?

Keith

[Mesa3d-dev] 3.5 texture formats

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

Brian, I finished off the port of the 3.4 texture utils and format work
this evening.  I think the overall design is clean and fits in well with
your FetchTexel work from a while back.  Please let me know if you have
any comments or issues with the work.  There may be a little fine tuning
with the utilities, but I'll leave that until the trunk is merged into
the mesa-3-5 branch this week.

-- Gareth

[Mesa3d-dev] SGI SI GLU library

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

I've added the SGI SI GLU library code to Mesa CVS.  It's in the si-glu/
directory.  You can get it with 'cvs up -d'.

I've updated the "old-style" makefiles (Makefile.X11 and Make-config) to
compile it.  I'd appreciate it if someone would add the autoconfig files
needed to compile it with ./configure;make.

The SI GLU requires C++ to compile it.  This may be a problem on some
systems.  I guess I'll continue to include the old src-glu/ code for
the sake of those systems.

-Brian

Re: [Mesa3d-dev] dynamic code generation with gcc

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

Stephen J Baker wrote:
> 
> SGI's OpenGL-for-Windoze can do this without using a compiler - so
> should we.

Which is why I was going down that road...  And quite frankly, a lot of
the stuff I would want to "generate" would be 3DNow!, SSE, MMX, maybe
even x86 hand-optimized assembly.  Thus, using a compiler seems fairly
pointless.

-- Gareth

Re: [Mesa3d-dev] dynamic code generation with gcc

[Stephen J B. <sj...@li...>]

On 13 Mar 2001, Josh Vanderhoof wrote:

> "Stephen J Baker" <sj...@li...> writes:
> 
> > If it's for something like varying the Z buffer depth - then a large
> > overhead might be acceptable (although I still maintain that creating
> > a dependence on a C compiler is a disasterously bad decision).
> 
> I just want to make sure there isn't a misunderstanding here - the C
> compiler would only be used to compile special case functions.  There
> would always be a generic fallback, so Mesa would work (although more
> slowly) even without a compiler installed.
 
Yes - but (as an application author) I have to tell you that well over
half the support problems I have for my code are Mesa-related and many
of them are of the form "The program runs really slowly on this machine
and much faster on that one...why?"  - and this kind of nonsense makes
that kind of thing MUCH worse.

You are going to run into all kinds of practical problem - where the
compiler isn't set up right - or it comes up with unexpected messages
to stdout that mess up people who pipe the output of their programs
off somewhere else.  Some people have C compilers - but not gcc.

There are just too many variables to make this work in a stable manner.

> > If it's something like catering for a particular combination of (say)
> > blend mode, texture type, dither and fogging (the kind of thing that
> > the SGI OpenGL-for-Windoze appears to do) - then taking even a couple
> > of milliseconds at runtime when you first happen to see a polygon with
> > that combination of states would be completely unacceptable - even with
> > caching.
> 
> If it was just 20 milliseconds or so, I doubt most users would notice.
> The problem is, I can easily see the delay being 500 ms for a big
> function.
> 
> I can think of two workarounds:
> 
> 1. Make the cache persistent, then the delay would only happen the
>    first time you run your application.
> 
> 2. Run the compiler in the background at low priority (say 10% cpu).
>    You would have to make do with the generic fallback until the
>    compile completes, but there wouldn't be a 'hitch' when the
>    application exposes a different path.
> 
> Do you think that would be acceptable?
 
Well, I have to say that I don't (yet) make much use of software
rendering - but in my business (Flight Simulation), the worst case
frame time is all that matters.  Occasional glitches in frame rate
are just as bad (from our customer's point of view) as persistantly
bad frame times.

However, we only use hardware accellerated OpenGL - so it's not an
issue in this *specific* case.

SGI's OpenGL-for-Windoze can do this without using a compiler - so
should we.

----
Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Re: [Mesa3d-dev] dynamic code generation with gcc

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

> 
> If it was just 20 milliseconds or so, I doubt most users would notice.
> The problem is, I can easily see the delay being 500 ms for a big
> function.
> 
> I can think of two workarounds:
> 
> 1. Make the cache persistent, then the delay would only happen the
>    first time you run your application.
> 
> 2. Run the compiler in the background at low priority (say 10% cpu).
>    You would have to make do with the generic fallback until the
>    compile completes, but there wouldn't be a 'hitch' when the
>    application exposes a different path.
> 
> Do you think that would be acceptable?

They sound like reasonable strategies, but first I think I'd just like to see
something working.

Keith