mesa3d-dev

Re: [Mesa3d-dev] static linking of 3.5 on irix

[Eric P. <eri...@di...>]

> I don't know why they reextract the archive, but anyhow, I just tried a static
> library build and a quick grep loop showed that all members of libNInt.al were
> included in libGLU.a.

Yes, if I do an nm -C libGLU.a everything I need is listed, but some of
them are marked "UNDEF", and those are the ones that cause the problem.
If you look at what you get from nm -C libNInt.a, you'll notice that
those symbols are there and this time they're not UNDEF. It seems to be
related to the fact that ranlib is run on the .a, which is not necessary
on IRIX (see the ar man page on irix). I ended up doing my own libGLU.a
with
ar cru libGLU.a `find . -name "*.o"`
and that worked quite well. No substitutes for doing things yourself;
don't trust dose darn machines :-).

> using the latest versions of autoconf, automake, and libtool. Maybe it was
> just a bug in one of them (I take it you built from the last release, right?).

Yes. This is likely a libtool issue. If I get around to it I'll mention
it to them.

> :) I guess to some extent hairy problems tend to result in hairy solutions.

True. With those things (autoconf etc), I usually end up with no hair
and no solutions. :-)


Thanks,

-- 
eric plante, software developer, effects, discreet

Re: [Mesa3d-dev] Display List Problem

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

Keith Whitwell wrote:
> 
> Allen Barnett wrote:
> > Attached is a short program which demonstrates a problem with display
> > lists in the current CVS version of Mesa. It appears that if a triangle
> > ... blah blah blah ... I carry on ...
> >
> 
> Allen,
> 
> I've fixed this in current CVS - let me know if if fixes your larger problems.
> 
> Keith

Yes, this fixed the rendering problem I had.

However, it also seems to have excited a different problem. (Well, there
were a lot of changes in CVS when I updated my source so it may be
unrelated to your fix here.) Attached is a test program which creates a
couple of display lists. The first dl draws a rectangle and translates
the modelview. The second dl just translates the modelview. If there is
a call to glNormal() in the second dl, Mesa segmentation faults in
_tnl_flush_vertices() when the second dl is invoked.

Thanks,
Allen

P.S. This behavior arises from trying to "draw" the blank character in
my OpenGL/FreeType 2 text rendering library. See
http://oglft.sourceforge.net
I just started this project and I'd appreciate any feedback or
suggestions.

Re: [Mesa3d-dev] Re: [Dri-devel] GLUT inclusion?

[Mike A. H. <mh...@re...>]

On Wed, 18 Jul 2001, Brian Paul wrote:

>> I've mentioned this to people, and they are worried that GLUT
>> won't be supported because it is not part of XFree86 Mesa.
>>
>> I do not use Mesa myself, so I don't understand how big a problem
>> removing GLUT from the distro might be.  Is there plans to
>> integrate GLUT with XFree86 4.2.0 at all?  If not, what is the
>> reasoning, and should we support it separately do you think?
>
>I think GLUT should be in its own RPM, independent of Mesa, XFree86,
>DRI, etc.  Since GLUT can be used with any number of X and OpenGL
>implementations it's wrong to create an unneeded dependency on
>Mesa or XFree86.
>
>I only distribute GLUT with Mesa as a convenience to users so
>that they can get up & running with OpenGL quickly.

Ok, thanks for the feedback Brian. (and everyone else too).

I think that sounds like the best idea as well, and I'll likely
do it that way when the time comes.

Thanks,
TTYL

----------------------------------------------------------------------
Mike A. Harris                  Shipping/mailing address:
OS Systems Engineer             190 Pittsburgh Ave., Sault Ste. Marie,
XFree86 maintainer              Ontario, Canada, P6C 5B3
Red Hat Inc.                    Phone: (705)949-2136
http://www.redhat.com           ftp://people.redhat.com/mharris
----------------------------------------------------------------------

[Mesa3d-dev] Re: [Dri-devel] GLUT inclusion?

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

"Mike A. Harris" wrote:
> 
> I've had several people asking me why GLUT is not included in
> XFree86's Mesa.  We ship separate Mesa which has it, but if I
> understand correctly, Brian Paul has added the needed bits to the
> Mesa trunk so that it works with 3.3.6 now also.  When this makes
> it into an official XFree86 release, we won't need external Mesa
> I don't believe, and likely will just ship XFree86 Mesa.
> 
> I've mentioned this to people, and they are worried that GLUT
> won't be supported because it is not part of XFree86 Mesa.
> 
> I do not use Mesa myself, so I don't understand how big a problem
> removing GLUT from the distro might be.  Is there plans to
> integrate GLUT with XFree86 4.2.0 at all?  If not, what is the
> reasoning, and should we support it separately do you think?

I think GLUT should be in its own RPM, independent of Mesa, XFree86,
DRI, etc.  Since GLUT can be used with any number of X and OpenGL
implementations it's wrong to create an unneeded dependency on
Mesa or XFree86.

I only distribute GLUT with Mesa as a convenience to users so
that they can get up & running with OpenGL quickly.

-Brian

[Mesa3d-dev] Re: [Dri-devel] GLUT inclusion?

[Philip W. <pg...@do...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Today, Gareth Hughes wrote:

>Philip Willoughby wrote:
>>
>> As I understand it it's a licensing issue.  glut is released under the strict
>> GPL, and XFree86 is not.
>
>Actually, no, it's not under the GPL.  The NOTICE file is as follows:
>
>NOTICE:  The OpenGL Utility Toolkit (GLUT) distribution contains source
>code published in a book titled "Programming OpenGL for the X Window
>System" (ISBN: 0-201-48359-9) published by Addison-Wesley.  The
>programs and associated files contained in the distribution were
>developed by Mark J. Kilgard and are Copyright 1994, 1995, 1996 by Mark
>J. Kilgard (unless otherwise noted).  The programs are not in the
>public domain, but they are freely distributable without licensing
>fees.  These programs are provided without guarantee or warrantee
>expressed or implied.
>
>Not the GPL, not the XFree86 (BSD) licence.  IANAL, but basically "it's
>not public domain, and don't sue me" -- to quote Nick Triantos from
>NVIDIA :-)

Ah OK...

Just grepping through the sources, it looks like distributors may need to be
extremely careful (more so than if it was all GPL) since some of the files are
in the public domain, and some are not.  However all of the source files for
libglut.so itself have this at the top:

/* Copyright (c) Mark J. Kilgard, 1994, 1997.  */

/* This program is freely distributable without licensing fees
   and is provided without guarantee or warrantee expressed or
   implied. This program is -not- in the public domain. */

His spelling not mine....

Regards,

Philip Willoughby

- --
echo bz...@nf... | tr "bizndfohces" "pwgd9ociaku"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7VZRyTEXlrOaAVckRAn8iAJwImKntMS3dJBF+ro/n7vwcYlcb5QCePN9s
1O7Vy5ASxdj9af2eHfV6bFk=
=WVlA
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] Re: [Dri-devel] GLUT inclusion?

[Rasputin <rar...@vi...>]

* Gareth Hughes <gar...@ac...> [010718 14:19]:
> Philip Willoughby wrote:
> > 
> > As I understand it it's a licensing issue.  glut is released under the strict
> > GPL, and XFree86 is not.
> 
> Actually, no, it's not under the GPL.  The NOTICE file is as follows:
> 
> NOTICE:  The OpenGL Utility Toolkit (GLUT) distribution contains source
> code published in a book titled "Programming OpenGL for the X Window
> System" (ISBN: 0-201-48359-9) published by Addison-Wesley.  The
> programs and associated files contained in the distribution were
> developed by Mark J. Kilgard and are Copyright 1994, 1995, 1996 by Mark
> J. Kilgard (unless otherwise noted).  The programs are not in the
> public domain, but they are freely distributable without licensing
> fees.  These programs are provided without guarantee or warrantee
> expressed or implied.
> 
> Not the GPL, not the XFree86 (BSD) licence.  IANAL, but basically "it's
> not public domain, and don't sue me" -- to quote Nick Triantos from
> NVIDIA :-)

Isn't that the license for the sample programs?
i.e. demos as in "Mesa-Demos".

What about libglut itself?

[Mesa3d-dev] Re: [Dri-devel] GLUT inclusion?

[Gareth H. <gar...@ac...>]

Philip Willoughby wrote:
> 
> As I understand it it's a licensing issue.  glut is released under the strict
> GPL, and XFree86 is not.

Actually, no, it's not under the GPL.  The NOTICE file is as follows:

NOTICE:  The OpenGL Utility Toolkit (GLUT) distribution contains source
code published in a book titled "Programming OpenGL for the X Window
System" (ISBN: 0-201-48359-9) published by Addison-Wesley.  The
programs and associated files contained in the distribution were
developed by Mark J. Kilgard and are Copyright 1994, 1995, 1996 by Mark
J. Kilgard (unless otherwise noted).  The programs are not in the
public domain, but they are freely distributable without licensing
fees.  These programs are provided without guarantee or warrantee
expressed or implied.

Not the GPL, not the XFree86 (BSD) licence.  IANAL, but basically "it's
not public domain, and don't sue me" -- to quote Nick Triantos from
NVIDIA :-)

-- Gareth

[Mesa3d-dev] Re: [Dri-devel] GLUT inclusion?

[Philip W. <pg...@do...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Today, Mike A. Harris wrote:

>I've had several people asking me why GLUT is not included in
>XFree86's Mesa.  We ship separate Mesa which has it, but if I
>understand correctly, Brian Paul has added the needed bits to the
>Mesa trunk so that it works with 3.3.6 now also.  When this makes
>it into an official XFree86 release, we won't need external Mesa
>I don't believe, and likely will just ship XFree86 Mesa.
>
>I've mentioned this to people, and they are worried that GLUT
>won't be supported because it is not part of XFree86 Mesa.
>
>I do not use Mesa myself, so I don't understand how big a problem
>removing GLUT from the distro might be.  Is there plans to
>integrate GLUT with XFree86 4.2.0 at all?  If not, what is the
>reasoning, and should we support it separately do you think?
>
>Any advice appreciated.

As I understand it it's a licensing issue.  glut is released under the strict
GPL, and XFree86 is not.  The licenses are not entirely compatible, and since
the XFree86 guys (rightly) do not want 90% of their code under one license, and
then some random bits in other license -- this just makes it a lot harder for
people to work out what they can and cannot do with the code.

I think that the best way for you to package X, GL, GLU and glut would be to
have all four in seperate packages.  glut really should be separate since it
uses a different license, GLU should be separate from GL because you want to
have more than one libGL.so (Mesa software for 3.3.6, Mesa GLX DRI for 4.x.y,
and Nvidias binary one for 4.x.y), but libGLU.so does not change.  And that
just leaves X...

Of course, this is just my opinion, but perhaps it would help distribution
vendors, and more so end-users if all concerned could agree on a standard way
of packaging up X, GL, GLU and glut...

Regards,

Philip Willoughby

- --
echo bz...@nf... | tr "bizndfohces" "pwgd9ociaku"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7VX+NTEXlrOaAVckRAgLKAJ4mPd8jgILFi/b970lOevHRd252DgCfeu/B
eigeN/B+W47ojNhRyujfyEQ=
=/knb
-----END PGP SIGNATURE-----

[Mesa3d-dev] GLUT inclusion?

[Mike A. H. <mh...@re...>]

I've had several people asking me why GLUT is not included in
XFree86's Mesa.  We ship separate Mesa which has it, but if I
understand correctly, Brian Paul has added the needed bits to the
Mesa trunk so that it works with 3.3.6 now also.  When this makes
it into an official XFree86 release, we won't need external Mesa
I don't believe, and likely will just ship XFree86 Mesa.

I've mentioned this to people, and they are worried that GLUT
won't be supported because it is not part of XFree86 Mesa.

I do not use Mesa myself, so I don't understand how big a problem
removing GLUT from the distro might be.  Is there plans to
integrate GLUT with XFree86 4.2.0 at all?  If not, what is the
reasoning, and should we support it separately do you think?

Any advice appreciated.

Thanks guys,
TTYL




----------------------------------------------------------------------
Mike A. Harris                  Shipping/mailing address:
OS Systems Engineer             190 Pittsburgh Ave., Sault Ste. Marie,
XFree86 maintainer		Ontario, Canada, P6C 5B3
Red Hat Inc.                    Phone: (705)949-2136
http://www.redhat.com		ftp://people.redhat.com/mharris
----------------------------------------------------------------------

Re: [Mesa3d-dev] Display List Problem

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

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

Allen, 

I've fixed this in current CVS - let me know if if fixes your larger problems.

Keith

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

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

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

I don't see this problem at all.  Can you verify it is still there with
current cvs?

Keith

Re: [Mesa3d-dev] static linking of 3.5 on irix

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

Eric Plante wrote:
> 
> Hi there all.
> 
> First of all, a big thanks. You are doing something great for the free
> software community.
> 
> In the next few weeks (counting out siggraph en EG CAS), I'll be playing
> quite a bit with mesa, particularly OSmesa; eventually I'd like to have
> it work in 12 bits per channel and have the channel depth specified in
> the creation of the context. But I'm not there yet, I'm starting with
> more modest goals, the first one of which being to get working static
> libs on irix.
> 
> The first thing I stumbled on is that the MesaLib tar will not compile
> without MesaDemos, which contains glut. No problem.
> 
> So, here's my first problem (more to come I promise ;) ). This one is
> irix-specific. It seems that some objects are missing from the libGLU.a.
> Is that possible?
> 
> I tried finding out what is happening, and it seems that
> si-glu/libnurbs/internals/.libs/libNInt is built, and then _extracted_
> (don't ask me why) back into .o's in (..)/.libs/libGLU.lax/libNInt.a/,
> and then selected .o's end up included in the final libGLU.a . It seems
> that some of those are missing, like for instance nurbsinterfac.o.
> 
> I have to say, I instantly admire anyone capable of dealing with
> autoconf, libtool and their likes. They're definately a blessing to the
> end user, but _man_ ... :-)
> 
> Ideas, anyone?
> 
> I have to say all of this is using irix cc, and I will try with gcc. I'm
> doubtful that the problem will be solved though, as the gcc installation
> on irix uses irix's native tools rather than GNU binutils..

Hi Eric,

I've had trouble with configure+make on my IRIX system too.  You might
want to try the "old-style" makefiles instead:

cd Mesa-3.5
cp Makefile.X11 Makefile
make irix6-n32		// irix6-n32-dso would build shared libs

This will actually build the old Mesa GLU 1.1 library since the irix6-n32
config isn't setup for C++ (which the si-glu needs).  But this should at
least get you up and running.

-Brian

[Mesa3d-dev] update: mesa 3.5 on irix

[Eric P. <eri...@di...>]

Just a short note. Doesn't work with gcc. Some mix of headers bombs the
build with an unmatched quote. So I'm still stuck with my original
problem..



-- 
eric plante, software developer, effects, discreet

[Mesa3d-dev] static linking of 3.5 on irix

[Eric P. <eri...@di...>]

Hi there all.

First of all, a big thanks. You are doing something great for the free
software community.

In the next few weeks (counting out siggraph en EG CAS), I'll be playing
quite a bit with mesa, particularly OSmesa; eventually I'd like to have
it work in 12 bits per channel and have the channel depth specified in
the creation of the context. But I'm not there yet, I'm starting with
more modest goals, the first one of which being to get working static
libs on irix.

The first thing I stumbled on is that the MesaLib tar will not compile
without MesaDemos, which contains glut. No problem.

So, here's my first problem (more to come I promise ;) ). This one is
irix-specific. It seems that some objects are missing from the libGLU.a.
Is that possible?

I tried finding out what is happening, and it seems that
si-glu/libnurbs/internals/.libs/libNInt is built, and then _extracted_
(don't ask me why) back into .o's in (..)/.libs/libGLU.lax/libNInt.a/,
and then selected .o's end up included in the final libGLU.a . It seems
that some of those are missing, like for instance nurbsinterfac.o.

I have to say, I instantly admire anyone capable of dealing with
autoconf, libtool and their likes. They're definately a blessing to the
end user, but _man_ ... :-)

Ideas, anyone?

I have to say all of this is using irix cc, and I will try with gcc. I'm
doubtful that the problem will be solved though, as the gcc installation
on irix uses irix's native tools rather than GNU binutils..


Thanks,


-- 
eric plante, software developer, effects, discreet

[Mesa3d-dev] [ mesa3d-Bugs-441859 ] glColorMaterial fails with strips

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

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

Category: mesa-core
Group: Rendering Error
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Saunders (rms7326)
Assigned to: Nobody/Anonymous (nobody)
Summary: glColorMaterial fails with strips

Initial Comment:
Using glColorMaterial(GL_FRONT_AND_BACK,
GL_AMBIENT_AND_DIFFUSE) in conjunction with
GL_QUAD_STRIP blocks does not always color/light the
surface correctly. The first few strips shade well and
then suddenly the strip turns black. This occurs only
when lighting is used. If we turn lighting off the
strips are colored correctly. We noticed that if we
deliver a color at each vertex then glColorMaterial
seems to track lighting correctly.

I should note that this problem occurs on Intel Linux
2.2 machine but not on our Solaris 7 machine. One
difference between the two builds is that I compiled
the Solaris 7 platform so that it did not use the Sparc
ASM code (i.e. USE_SPARC_ASM is commented out in conf.h
because it won't compile otherwise). So I suppose it is
possible that the problem is in that or other platform
specific code (including the graphics card I suppose).
Our linux machine has a GForce 2 Ulta.

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

>Comment By: Michael Saunders (rms7326)
Date: 2001-07-17 10:39

Message:
Logged In: YES 
user_id=217333

After further investigation I discovered that I mistated
when I said that Solaris 7 did not exhibit the problem. This
is not true and I was able to get Solaris 5 and 7 to fail as
well. I tried to reduce the problem to as small as possible.
While I was doing this I notied some interesting points.

1) If we turned off drawing of the lines strips that are
also in this plot the shading problems went away. Next I ran
a larger problem and discoverd that with larger problems it
didn't matter if I turned the line strips on or not.

2) When I linked the debug build of our application to the
release build of the Mesa 3.5 library the problem did not
exhibit itself. However when I linked the release build of
our application to the release build of the Mesa 3.5 library
the problem did exhibit itself.
Initially I had assumed that we must be sending different
instructions to Mesa with our debug and release builds. So I
turned on our logging feature which outputs the OpenGL
statements delivered to Mesa and compared the two. The diffs
were identical. This leads me to believe that the problem is
an uninitialized variable inside the code that processes
strips and tracks the color and lighting (glColorMaterial).

I have included the log output as an attachment. The
instructions are all executable so if you need to paste it
into a c program it should work fine. The log contains all
the instructions send to Mesa with their respective
arguments.

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

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

Re: [Mesa3d-dev] Bug in glEnable (GL_BLEND) & glDiable(GL_BLEND)

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

On Tue, 17 Jul 2001, Igor Pokrovsky wrote:

> Hello.
> 
> My machine is hanging, when I'm using glEnable(GL_BLEND) and glDisable(GL_BLEND) frequently.
> May be this is bug?
 
Maybe you should tell us (in order of importance):

  * Which version of Mesa you have.
  * What graphics card you have.
  * What Xfree version (assuming you are using Xfree)
  * What Kernel revision
  * What Linux distro (assuming you are running Linux)
  * What CPU/CPU-speed/RAM-size you have

----
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

[Mesa3d-dev] Bug in glEnable (GL_BLEND) & glDiable(GL_BLEND)

[Igor P. <igo...@ma...>]

Hello.

My machine is hanging, when I'm using glEnable(GL_BLEND) and glDisable(GL_BLEND) frequently.
May be this is bug?

Anyway, regards
Igor Pokrovsky

[Mesa3d-dev] [ mesa3d-Bugs-441859 ] glColorMaterial fails with strips

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

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

Category: mesa-core
Group: Rendering Error
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Saunders (rms7326)
Assigned to: Nobody/Anonymous (nobody)
Summary: glColorMaterial fails with strips

Initial Comment:
Using glColorMaterial(GL_FRONT_AND_BACK,
GL_AMBIENT_AND_DIFFUSE) in conjunction with
GL_QUAD_STRIP blocks does not always color/light the
surface correctly. The first few strips shade well and
then suddenly the strip turns black. This occurs only
when lighting is used. If we turn lighting off the
strips are colored correctly. We noticed that if we
deliver a color at each vertex then glColorMaterial
seems to track lighting correctly.

I should note that this problem occurs on Intel Linux
2.2 machine but not on our Solaris 7 machine. One
difference between the two builds is that I compiled
the Solaris 7 platform so that it did not use the Sparc
ASM code (i.e. USE_SPARC_ASM is commented out in conf.h
because it won't compile otherwise). So I suppose it is
possible that the problem is in that or other platform
specific code (including the graphics card I suppose).
Our linux machine has a GForce 2 Ulta.

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

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

[Mesa3d-dev] [ mesa3d-Bugs-429312 ] glMaterialfv broken with Translucency

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

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

Category: mesa-core
Group: Rendering Error
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Saunders (rms7326)
Assigned to: Nobody/Anonymous (nobody)
Summary: glMaterialfv broken with Translucency

Initial Comment:
The glMaterialfv function does not seem to recognize
changes to translucency correctly. We are pulling
"panels" off of a depth sorted panel heap and then then
setting the appropriate translucency for each. The
order of our OpenGL calls looks something like this:


glNewList(dataList, GL_COMPILE)
glDepthMask(FALSE)
glEnable(GL_BLEND)
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)
glPolygonMode(GL_FRONT_AND_BACK, 6914)
glEnable(GL_LIGHTING)
glShadeModel(GL_FLAT)
glMaterialfv(GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE,
RGBA_array) where RGBA_array[0..3]=[0.823529,0,0,0.9]
glBegin(GL_POLYGON)
glNormal3d(0 1 0)
glVertex3d(1.1,0,0)
glVertex3d(1.1,0,1)
glVertex3d(2.1,0,1)
glVertex3d(2.1,0,0)
glEnd()
glMaterialfv(GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE,
RGBA_array) where RGBA_array[0..3]=[0.823529,0,0,0.5]
glBegin(GL_POLYGON)
glNormal3d(0 1 0)
glVertex3d(0,0,0)
glVertex3d(0,0,1)
glVertex3d(1,0,1)
glVertex3d(1,0,0)
glEnd()
glDepthMask(TRUE)
glDisable(GL_BLEND)
glEndList()
glCallList(dataList)
glFlush()

What we discover is that the two polygons have the same
instead of different translucency. This is a small
example of a larger problem. When we draw tens of
thousands of polygons in this way we discover that on
occasion the correct translucency value is pushed
through, almost as if there is a cache problem. I know
it is not graphics card related cache problem because
we have run the Mesa version of our product on various
platforms all exhibiting the same behavior.

Additionally, we are using Mesa 3.4.1. I can provide
more info about what we are doing before and after the
above calls if needed.

Thanks,
Michael

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

>Comment By: Michael Saunders (rms7326)
Date: 2001-07-16 17:42

Message:
Logged In: YES 
user_id=217333

Brian,

I got a chance to check out the 3.5 release and the problem
with glMateral is now fixed so you can close this bug
report. I did however discover another bug with
glColorMaterial and strips which I will report separately.

Michael

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

Comment By: Brian Paul (brianp)
Date: 2001-06-04 09:01

Message:
Logged In: YES 
user_id=983

I think this should be fixed in Mesa 3.5 (the CVS trunk). 
Can you
give that a try?



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

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

[Mesa3d-dev] [ mesa3d-Bugs-441817 ] Solaris 5 and 7 can't compile glu

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

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

Category: GLU
Group: Compile/Install
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Saunders (rms7326)
Assigned to: Nobody/Anonymous (nobody)
Summary: Solaris 5 and 7 can't compile glu

Initial Comment:
Both my Solaris 5 and Solaris 7 platforms can't compile
some files (at least "curve.cc", but there may be more)
in the "si-glu/libnurbs/internals" directory. The file,
"curve.cc" uses "::sqrtf" which when LIBRARYBUILD is
defined (and not GLBUILD or STANDALONE) it is undefined
(see "mymath.h"). For some reason the linux build using
g++ does not have this problem so I assume it must
define ::sqrtf but the Sun Workshop 6 compilers do not.

Michael

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

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

[Mesa3d-dev] mmx blend code bug

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

Using a test program provided by Allen Barnett I've found that there's a
bug in the _mesa_mmx_blend_transparency() function in src/X86/mmx_blend.S.

It appears that if mask[0] is zero then the next pixel (element [1]) isn't
always blended as it should be.

I don't remember who wrote this code and I'm not inclined to debug it myself.
If anyone wants to take a stab at fixing it I'll send you the test program.
Otherwise, I'm just going to disable the MMX code.

-Brian

[Mesa3d-dev] [ mesa3d-Bugs-441788 ] Compiler's -g used with optimize

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

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

Category: mesa-core
Group: Compile/Install
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Saunders (rms7326)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compiler's -g used with optimize

Initial Comment:
When I run configure with the "--disable-debug" and
"--enable-optimize" (the defaults) for Mesa 3.5 under
Solaris 7 I noticed that a "-g" gets into the compile
commands.

This may be a problem with other platforms as well.

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

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

Re: [Mesa3d-dev] mesa extensions

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

axe...@ph... wrote:
> 
> Hi,
> 
> is there a list of the OpenGL extensions implemented for
> MESA so far (and in which status they are)?

Mesa supports:

GL_ARB_imaging
GL_ARB_multisample
GL_ARB_multitexture
GL_ARB_texture_border_clamp
GL_ARB_texture_compression
GL_ARB_texture_cube_map
GL_ARB_texture_env_add
GL_ARB_texture_env_combine
GL_ARB_texture_env_dot3
GL_ARB_transpose_matrix
GL_EXT_abgr
GL_EXT_bgra
GL_EXT_blend_color
GL_EXT_blend_func_separate
GL_EXT_blend_logic_op
GL_EXT_blend_minmax
GL_EXT_blend_subtract
GL_EXT_clip_volume_hint
GL_EXT_cull_vertex
GL_EXT_convolution
GL_EXT_compiled_vertex_array
GL_EXT_fog_coord
GL_EXT_histogram
GL_EXT_packed_pixels
GL_EXT_paletted_texture
GL_EXT_point_parameters
GL_EXT_polygon_offset
GL_EXT_rescale_normal
GL_EXT_secondary_color
GL_EXT_shared_texture_palette
GL_EXT_stencil_wrap
GL_EXT_texture3D
GL_EXT_texture_compression_s3tc
GL_EXT_texture_env_add
GL_EXT_texture_env_combine
GL_EXT_texture_env_dot3
GL_EXT_texture_filter_anisotropic
GL_EXT_texture_object
GL_EXT_texture_lod_bias
GL_EXT_vertex_array
GL_EXT_vertex_array_set
GL_HP_occlusion_test
GL_IBM_rasterpos_clip
GL_INGR_blend_func_separate
GL_MESA_packed_depth_stencil
GL_MESA_resize_buffers
GL_MESA_sprite_point
GL_MESA_window_pos
GL_NV_blend_square
GL_NV_texgen_reflection
GL_SGI_color_matrix
GL_SGI_color_table
GL_SGIS_generate_mipmap
GL_SGIS_pixel_texture
GL_SGIS_texture_border_clamp
GL_SGIS_texture_edge_clamp
GL_SGIX_depth_texture
GL_SGIX_pixel_texture
GL_SGIX_shadow
GL_SGIX_shadow_ambient
GL_3DFX_texture_compression_FXT1

But the extensions that you'll actually get depends on the driver
and hardware that you're using (Xlib, DRI, etc).

-Brian

[Mesa3d-dev] mesa extensions

[<axe...@ph...>]

Hi,

is there a list of the OpenGL extensions implemented for
MESA so far (and in which status they are)?

regards

axel binder

=====================================================
Axel Binder                     Philips Starnberg
Development Manager Software    Petersbrunner Str. 17
                                D-82319 Starnberg
phone:  +49 8151 270 108        Germany
fax:    +49 8151 270 200
mobile: +49 172 92 18 623
e-mail: axe...@ph...
=====================================================

[Mesa3d-dev] [ mesa3d-Bugs-441141 ] Various compile errors for Solaris 7

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

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

Category: mesa-core
Group: Compile/Install
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Saunders (rms7326)
Assigned to: Nobody/Anonymous (nobody)
Summary: Various compile errors for Solaris 7

Initial Comment:
1) Several files in the 3.5 distribution are reported
by the Solaris 7 compiler (Workshop 6.0) as having a
null character at the end of the files. The compiler
reports this as an error and stops. I solved the
problem by editing the file with vi and adding a
newline to the end of the file and then deleting it
again. I have discovered from working in a mixed
environment that when Windows machines write out text
files they leave off whatever character the Solaris
machine is expecting at the end of the file. I have
never had this problem when editing files with a Unix
machine.

2) With the USE_SPARC_ASM define set to 1 the Solaris 7
Workshop 6.0 cc compiler has trouble compiling the
assembly language files. It passes off the cpp'ed file
to a utility called /opt/SUNWspro/bin/../WS6/bin/fbe to
convert the asm to machine code but it reports all
kinds of errors (a few follow below):
cc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include
-I../../src -DUSE_SPARC_ASM -I./src/X86 -g -D_REENTRANT
-DPTHREADS -c glapi_sparc.S  -KPIC -DPIC -o
glapi_sparc.o
/opt/SUNWspro/bin/../WS6/bin/fbe: "/tmp/cpp0AAADRaq8M",
line 611: error: invalid character (0x40)
/opt/SUNWspro/bin/../WS6/bin/fbe: "/tmp/cpp0AAADRaq8M",
line 614: error: invalid character (0x23)
/opt/SUNWspro/bin/../WS6/bin/fbe: "/tmp/cpp0AAADRaq8M",
line 614: error: invalid character (0x3b)
/opt/SUNWspro/bin/../WS6/bin/fbe: "/tmp/cpp0AAADRaq8M",
line 614: error: statement syntax
/opt/SUNWspro/bin/../WS6/bin/fbe: "/tmp/cpp0AAADRaq8M",
line 614: error: invalid character (0x23)
/opt/SUNWspro/bin/../WS6/bin/fbe: "/tmp/cpp0AAADRaq8M",
line 614: error: invalid number of operands
/opt/SUNWspro/bin/../WS6/bin/fbe: "/tmp/cpp0AAADRaq8M",
line 614: error: invalid character (0x2c)
/opt/SUNWspro/bin/../WS6/bin/fbe: "/tmp/cpp0AAADRaq8M",
line 614: error: invalid character (0x40)
/opt/SUNWspro/bin/../WS6/bin/fbe: "/tmp/cpp0AAADRaq8M",
line 614: error: statement syntax

Here is what the preprossed file looks like (note I
added the line numbers to help you see the association
with the errors above:

599 .text
600 .align 32
601 .globl __glapi_sparc_icache_flush
602 __glapi_sparc_icache_flush: 
603 	flush	%o0
604 	retl
605 	 nop
606 
607 .data
608 .align 64
609 
610 .globl _mesa_sparc_glapi_begin
611 .type _mesa_sparc_glapi_begin,@function
612 _mesa_sparc_glapi_begin:
613 
614 .globl gl##NewList ; .type gl##NewList,@function
615 gl##NewList:
616 # 39 "glapi_sparc.S" 
617 
618 	sethi	%hi(0x00000000), %g1
619 	ld	[%g1 + %lo(0x00000000)], %g1
620	ld	[%g1 + (4 * 0)], %g3
621 
622 	jmpl	%g3, %g0
623 
624 .globl gl##EndList ; .type gl##EndList,@function
625 gl##EndList:
626 # 58 "glapi_sparc.S" 
627 
628 	sethi	%hi(0x00000000), %g1
629 	ld	[%g1 + %lo(0x00000000)], %g1
630 	ld	[%g1 + (4 * 1)], %g3
631 
632 	jmpl	%g3, %g0
633 
634 .globl gl##CallList ; .type gl##CallList,@function
635 gl##CallList:


It looks like fbe is complaining about the @ and ; and
; and , signs.

Michael

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

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