[Mesa-dev] Re: [Mesa3d-dev] initialization problem on VMS system

[Brian Paul]

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi all,
> 
> I did not get any answers to my last posts over the last weeks concerning
> an initialization problem on VMS systems and my proposed solution. (the trafic
> on Mesa3d-dev is very low last weeks anyway). So
>   -Is nobody (except me) getting my mails from the list?
>   -Is nobody reading them?
>   -Is nobody sending any answers to the list?
>   -Do I have problems getting mails from the list?

The whole PI team was out of town for a company meeting.  It'll be
a few days before I'm caught up on email.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

[Mesa-dev] reminder: moving to mesa3d-dev@lists.sourceforge.net

[Brian Paul]

Just a reminder, I'll soon be shutting down the Mesa lists hosted
at mesa3d.org.  The new lists are hosted on sourceforge.net

I see that a lot of people on this list haven't yet subscribed to
the new developers list on SourceForge.  To subscribe to it, visit
http://sourceforge.net/mail/?group_id=3

I'll have this list and the mesa-bugs list shut down in the near
future without notice.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

[Mesa-dev] Re: [Mesa3d-dev] CONFORM

[Brian Paul]

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

Yup.  I already did over the weekend.  Same results as for 3.1.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

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

[Brian Paul]

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

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

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

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

[Brian Paul]

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

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


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

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


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

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

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

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

[Brian Paul]

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

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


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

3.2b1 = 3.2 beta 1


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

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


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

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

cvs update -r mesa_3_2_dev

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


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

Yes, as I said in email yesterday.


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

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


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

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

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

[Mesa-dev] Mesa CVS write access

[Brian Paul]

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

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

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

[Mesa-dev] Mesa CVS now on SourceForge

[Brian Paul]

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

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

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

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

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] CVS out of order?

[Brian Paul]

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi
> 
> Is something wrong with the CVS machine. I only get:
> 
> sm43-jj) alias cvsmesa
> cvs -d:pserver:[EMAIL PROTECTED]:/cvs/mesa3d
> sm43-jj) cvsmesa checkout .
> cvs [checkout aborted]: unrecognized auth response from cvs.mesa3d.org: cvs pser
> Jouk

I don't know what the admins did but it seems to be working again.
Disk might have been full, judging from the errors I saw.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] CVS out of order?

[Brian Paul]

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi
> 
> Is something wrong with the CVS machine. I only get:
> 
> sm43-jj) alias cvsmesa
> cvs -d:pserver:[EMAIL PROTECTED]:/cvs/mesa3d
> sm43-jj) cvsmesa checkout .
> cvs [checkout aborted]: unrecognized auth response from cvs.mesa3d.org: cvs pser
> Jouk

It was doing that yesterday for a bit too.  I'll look into it.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Re:Mesa-3.1-widgets-sgi

[Brian Paul]

> Gerry Cook wrote:
> 
> Brian,
> 
> I have problems with widgets-sgi. I tried contacting suggested support at
> [EMAIL PROTECTED] and
> crunch.ikp.physik.th-darmstadt.de (unknown ISP) as documented in Mandrake
> Linux 3.1. Do you keep contacts updated and how do I contact Thorsten Ohl or
> Jeroen van der Zijp?

I haven't heard from either of them in several years.

Please file a (detailed) bug report at mesa3d.sourceforge.net

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

[Mesa-dev] FP exception in gl_x86_cliptest_points4()

[Brian Paul]

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

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

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

stopped the exception.

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

-Brian

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


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

[Mesa-dev] Bug database usage

[Brian Paul]

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

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

Thanks.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] GLX_EXT_visual_rating problem

[Brian Paul]

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi All,
> 
> Someone switched the GLX_EXT_visual_rating macro on in glx.h. This gives
> problems in src-glut/glut_distr.c since GLX_SLOW_VISUAL_EXT is not defined.
> 
>  Why was glx.h changed?
>  What should be the definition of GLX_SLOW_VISUAL_EXT?

As I wrote before, it was a typo in the glx.h file.  I hadn't recompiled
GLUT so didn't notice the problem.

I added this extension yesterday, though it has no effect in stand-alone
Mesa.  I added it since I do plan to support it in the DRI Mesa/GLX code.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

[Mesa-dev] Mesa 3.2 beta 1 released

[Brian Paul]

I've just upload the Mesa 3.2 beta 1 files to SourceForge at
https://sourceforge.net/project/filelist.php?group_id=3

3.2 (note even number) is a stabilization release of Mesa 3.1
meaning it's mainly just bug fixes.

Here's what's changed:

Bug fixes:
- mixed drawing of lines and bitmaps sometimes had wrong colors
- added missing glHintPGI() function
- fixed a polygon culling bug
- fixed bugs in gluPartialDisk()
- Z values in selection mode were wrong
- added missing tokens:
GL_SMOOTH_POINT_SIZE_RANGE
GL_SMOOTH_POINT_SIZE_GRANULARITY
GL_SMOOTH_LINE_WIDTH_RANGE
GL_SMOOTH_LINE_WIDTH_GRANULARITY
GL_ALIASED_POINT_SIZE_RANGE
GL_ALIASED_LINE_WIDTH_RANGE
- fixed glCopyPixels when copying from back to front buffer
- GL_EXT_compiled_vertex_array tokens had _SGI suffix instead of _EXT
- glDrawRangeElements(GL_LINES, 0, 1, 2, type, indices) was broken
- glDeleteTextures() didn't decrement reference count correctly
- GL_SRCA_ALPHA_SATURATE blend mode didn't work correctly
- Actual depth of transformation matrix stacks was off by one
- 24bpp visuals didn't address pixels correctly
- mipmap level of detail (lambda) calculation simplified, more accurate
- 101691 - Polygon clipping and GL_LINE
- 101928 - Polygon clipping and GL_LINE (same fix as above)
- 101808 - Non-glVertexArrays tristrip bug
- 101971 - find_last_3f on Dec OSF (worked around)
- 102369 - segv on dec osf (possibly a duplicate of the above)
- 102893 - orientations of modelview cause segfault
New:
- updated SVGA Linux driver
- added the MESA_FX_NO_SIGNALS env var, see docs/README.3DFX
- build libGLw.a (Xt/OpenGL drawing area widget) library by default
- changed -O2 to -O3 for a number of gcc configs
Changes:
- glXCopyContext's mask parameter is now unsigned long, per GLX spec


Please report any problems with this release ASAP.  Bugs should be filed
on the Mesa3D website at sourceforge.

After 3.2 is wrapped up I hope to release 3.3 beta 1 soon afterward.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-bug] Doesn't compile #defines in src/vbrender.c

[Brian Paul]

Keith Whitwell wrote:
> 
> Marco Tessore wrote:
> >
> > My system (Slackware 7.0) doesn't compile macros written on multiple
> > lines.
> > I must compat like the file in attachment.
> > Sorry for my English and thank you for Mesa
> >
> > Marco Tessore <[EMAIL PROTECTED]>
> >
> >   --
> 
> This is very strange... so strange I have trouble beleiving that it is really
> true.
> 
> That type of #define is used throughout mesa and just about every other major
> piece of software.  Are you only seeing troubles in vbrender.c?
> 
> What version of gcc are you using?  (run 'gcc -v') ?
> 
> Can anyone else with slackware 7.0 confirm/deny the problem?
> 
> Keith

I wonder if there are some CR (ascii 13) characters in there causing
the problem?

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

[Mesa-dev] check-in: triangle antialiasing done

[Brian Paul]

Last night I finished my antialiased triangle code for Mesa 3.3.
It seems to work pretty well.  It could stand some performance
tuning but it'll always be considerably slower than non-
antialiased triangles.

I believe this was the last bit of OpenGL functionality which was
missing in Mesa.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

[Mesa-dev] move to sourceforge.net

[Brian Paul]

As I've said before, I'm going to be moving the Mesa project to
SourceForge.net in the near future.

Those of you on the Mesa developer's list should visit
www.sourceforge.net, register yourselves as users and join the
[EMAIL PROTECTED] mailing list.  I will not be automatically
moving the members from the old list to the new list.

As soon as Mesa 3.2 is done (within the next few weeks, hopefully)
I'd like to move the CVS repository to sourceforge.

Reminder: the Mesa bug database on SourceForge is up and running now.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] size of GLcontext

[Brian Paul]

emanuel stiebler wrote:
> 
> Hi,
> 
> Is it true, that the size of GLcontext is about 75 KByte ?

sizeof(GLcontext) ~= 72KB in Mesa 3.3.  With all the other structs
and arrays that it points to it's probably several times that size.


> Is there any chance to get it smaller ?

Not much smaller.

What's the problem?

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] glPopAttrib and clear color

[Brian Paul]

Eero Pajarre wrote:
> 
> While searching for a bug (which was elsewhere),
> I noticed that glPopAttrib doesn't seem to
> call the necessary driver functions for
> restoring the current "clear color"
> 
> And there might be similar problems with the
> write masks...
> 
> And I guess this is a typo:
>if ((ctx->Color.BlendSrcRGB != oldBlendSrc ||
> ctx->Color.BlendSrcRGB != oldBlendDst) &&
> ^^^
> 
> These seem to be both in the default and the 3_2 branch
> (unless somebody has fixed then in the last couple of days)

Thanks.  I'll fix this ASAP.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] zbuffer & osmesa

[Brian Paul]

emanuel stiebler wrote:
> 
> Hi all,
> 
> In osmesa, i can allocate my own framebuffer, which resides on my pci-card.
> But, what is the suggested/clean way to do the same with the depth-buffer ?
> 
> Because I'm writing a driver for a card which has a rendering processor, it
> would be "nice" if the depth-buffer would be on the card, and not in main
> memory.

You're writing a new driver but using OSMesa?  OSMesa was never intented
for a hardware implementation.  I think you could use OSMesa as a _model_
for a driver but not as a hardware driver in and of itself.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

[Mesa-dev] check-in: runtime-selectable depth buffer size

[Brian Paul]

I've checked in some changes for Mesa 3.3 so that it can support
different sizes of depth buffers at runtime.  Previously you had
to recompile for 16 or 32bpp depth values.  That was bad for the
new hardware device drivers.

Now you can choose any depth from 0 to 32 bits.  For software
rendering, if depthBits <= 16 GLushorts are used for the depth
buffer, else GLuints are used.  The upper most significant bits
of each value are left at zero when depthBits < 16 or < 32.

The depthbuffer span read/write functions in the device driver
interface always read/write 32-bit values.  If the hardware
depth buffer is 16bpp you'll need to convert.  It's a small
performance hit but that's a software-fallback path anyway.
I've implemented this in the 3dfx driver.

Mesa's pseudo glXChooseVisual() function has been modified a bit
for the GLX_DEPTH_SIZE option.  The OpenGL spec says that if you
pass GLX_DEPTH_SIZE=1 (which is what GLUT and most apps do) then
OpenGL should use the deepest depth buffer available.  If I'd
have done that then you'd get a 32bpp depth buffer.  A 32bpp
buffer is considerably slower than 16bpp.  Rather than impose
this performance hit on everyone I changed glXChooseVisual to
use 16bpp if GLX_DEPTH_SIZE=1 is passed in.  If you really want
a 24bpp buffer just pass GLX_DEPTH_SIZE=24, for example.

Since there's other ways in which Mesa's pseudo GLX varies from
the spec I don't think this is too big of deal.  Apps which really
care about visuals and their performance probably shouldn't use
glXChooseVisual anway.

Finally, there is an overflow problem with 32-bit depth buffers when
software rendering (fragment Z interpolation).  I haven't studied it
yet but it can probably be solved.  Until then, a 31-bit depth buffer
is the practical limit (and imposed by glXChooseVisual).

Just for fun I also tested weird values like 17bpp, 9bpp and 3bpp.
They work.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] mesadev src/colortab.c patch

[Brian Paul]

relnev wrote:
> 
> Patch for colortab.c. _mesa_GetColorTableParameteriv didn't support
> the PROXY_TEXTURE formats..

Thanks.  I've applied the patch to Mesa 3.3 (and back-ported it to 3.2).

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] mesadev mipmap.c patch

[Brian Paul]

relnev wrote:
> 
> A two line patch against src-glu/mipmap.c for gluScaleImage to allow
> GL_BGR and GL_BGRA formats

Thanks. I've applied the patch.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Compilation warnings

[Brian Paul]

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi all
> 
> I got the following compilation informational warnings for the latest Mesa3.3
> At the moment I have no time to look into it. Maybe they are harmless.
> 
>Jouk
> 
> cc /include=([-.include],[])/define=(FBIND=1) MATRIX.C
> 
>if (mask == MASK_IDENTITY) {
> ...^
> %CC-I-QUESTCOMPARE1, In this statement, the unsigned expression "mask" is being
> compared with an equality operator to a constant whose value is negative.  This
> might not be what you intended.
> at line number 767 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_2223.MESA.SRC]MA
> TRIX.C;1
> 
>else if ((mask & MASK_2D_NO_ROT) == MASK_2D_NO_ROT)
> ^
> %CC-I-QUESTCOMPARE1, In this statement, the unsigned expression "(mask&((1<<4)|(
> 1<<8)|(1<<1)|(1<<9)|(1<<2)|(1<<6)|(1<<(10+16))|(1<<14)|(1<<3)|(1<<7)|(1<<11)|(1<
> <(15+16" is being compared with an equality operator to a constant whose val
> ue is negative.
>   This might not be what you intended.
> at line number 770 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_2223.MESA.SRC]MA
> TRIX.C;1
> 
>else if ((mask & MASK_2D) == MASK_2D)
> ^
> %CC-I-QUESTCOMPARE1, In this statement, the unsigned expression "(mask&((1<<8)|(
> 1<<9)|(1<<2)|(1<<6)|(1<<(10+16))|(1<<14)|(1<<3)|(1<<7)|(1<<11)|(1<<(15+16" i
> s being compared with an equality operator to a constant whose value is negative
> .  This might n
> ot be what you intended.
> at line number 777 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_2223.MESA.SRC]MA
> TRIX.C;1
> 
>else if ((mask & MASK_3D_NO_ROT) == MASK_3D_NO_ROT)
> ^
> %CC-I-QUESTCOMPARE1, In this statement, the unsigned expression "(mask&((1<<4)|(
> 1<<8)|(1<<1)|(1<<9)|(1<<2)|(1<<6)|(1<<3)|(1<<7)|(1<<11)|(1<<(15+16" is being
>  compared with an equality operator to a constant whose value is negative.  This
>  might not be w
> hat you intended.
> at line number 797 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_2223.MESA.SRC]MA
> TRIX.C;1
> 
>else if ((mask & MASK_3D) == MASK_3D)
> ^
> %CC-I-QUESTCOMPARE1, In this statement, the unsigned expression "(mask&((1<<3)|(
> 1<<7)|(1<<11)|(1<<(15+16" is being compared with an equality operator to a c
> onstant whose value is negative.  This might not be what you intended.
> at line number 809 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_2223.MESA.SRC]MA
> TRIX.C;1

Can you try inserting (GLuint) casts into the #defines for those tokens in
matrix.c?


> cc /include=([-.include],[])/define=(FBIND=1) GLAPI.C
> 
>if (i >= 0)
> ...^
> %CC-I-QUESTCOMPARE, In this statement, the unsigned expression "i" is being comp
> ared with a relational operator to a constant whose value is not greater than ze
> ro.  This might not be what you intended.
> at line number 260 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_2223.MESA.SRC]GL
> API.C;1

Fixed by changing GLuint to GLint.  I've checked this in.



> cc /include=([-.include],[])/define=(FBIND=1) CONFIG.C
> 
>   if ((h = (GLenum) gl_lookup_enum_by_name(hname)) != -1 &&
> ..^
> %CC-I-QUESTCOMPARE1, In this statement, the unsigned expression "(h=(GLenum)gl_l
> ookup_enum_by_name(...))" is being compared with an equality operator to a const
> ant whose value is negative.  This might not be what you intended.
> at line number 229 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_2223.MESA.SRC]CO
> NFIG.C;1
> 
>   (v = (GLenum) gl_lookup_enum_by_name(vname)) != -1)
> ..^
> %CC-I-QUESTCOMPARE1, In this statement, the unsigned expression "(v=(GLenum)gl_l
> ookup_enum_by_name(...))" is being compared with an equality operator to a const
> ant whose value is negative.  This might not be what you intended.
> at line number 230 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_2223.MESA.SRC]CO
> NFIG.C;1

I've cleaned this up and checked it in.

Thanks for the info.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] runtime errors is Mesa3.3

[Brian Paul]

"Jacob (=Jouk) Jansen" wrote:
> 
> [EMAIL PROTECTED] wrote on 23-FEB-2000 16:40:03.97
> 
> >"Jacob (=Jouk) Jansen" wrote:
> > I may have located the problem in xmesa2.c:
> >
> > if (xmesa->xm_buffer->buffer != XIMAGE) {
> ^^
> backpixmap
> 
> >   /* back buffer is a pixmap */
> >   xmesa->xm_buffer->back_clear_func = clear_back_pixmap;
> >}
> >
> [snip]
> >
> >Try the change I show above.
> Thanks, that works

I'm checking it in now.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] runtime errors is Mesa3.3

[Brian Paul]

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi
> 
> Brian wrote:
> >Yesterday I checked in a few changes to xmesaP.h, xmesa1.c and xmesa2.c
> >which fixed some problems with 24bpp rendering and buffer clearing.
> >
> >Can you get a more detailed stack trace?  Setting the MESA_XSYNC env var
> >first will force Xlib to operate synchronously and should make it easier
> >to locate the problem.
> 
> I may have located the problem in xmesa2.c:
> 
> if (xmesa->xm_buffer->buffer != XIMAGE) {
^^
backpixmap


>   /* back buffer is a pixmap */
>   xmesa->xm_buffer->back_clear_func = clear_back_pixmap;
>}
> 
> If I leave this part out it works fine. Probaly the condition
> xmesa->xm_buffer->buffer != XIMAGE
>  is fullfilled while it should not use the clear_back_pixmap function!!!


Try the change I show above.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] runtime errors is Mesa3.3

[Brian Paul]

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi all,
> 
> When running xlockmore with Mesa3.3 this morning (MET) I get in some of the
> demos this runtime error
> polka-jj) xlock -nice 0 -modelist allgl -inwindow
> X Error of failed request:  BadDrawable (invalid Pixmap or Window parameter)
>   Major opcode of failed request:  70 (X_PolyFillRectangle)
>   Resource id in failed request:  0x0
> Serial number of failed request:  5197
>   Current serial number in output stream:  5298
> %XLIB-E-ERROREVENT, error event received from server
> %TRACE-E-TRACEBACK, symbolic stack dump follows
>   imagemoduleroutine line  rel PC   abs PC
> 0 80B80480 80B80480
> 0 80B80670 80B80670
> 0 80B8392C 80B8392C
> 0 80B7EA18 80B7EA18
> 0 80B07BD0 80B07BD0
>  XLOCK  XLOCK  justDisplay  32864 32B4 001232B4
>  XLOCK  XLOCK  main 33928 6068 00126068
>  XLOCK  XLOCK  __main   0 0070 00120070
>  XLOCK  0 0022D680 0023D680
> 0 83A1D3D4 83A1D3D4
> polka-jj)
> 
> Yesterday's morning (MET) Mesa3.3 did not show this behaviour (I only have
> to change the 2 sharable libraries to get the effect or not)
> Who did change the X-driver?
> Why was it changed?
> What was changed?
> How can this problem be fixed?

Yesterday I checked in a few changes to xmesaP.h, xmesa1.c and xmesa2.c
which fixed some problems with 24bpp rendering and buffer clearing.

Can you get a more detailed stack trace?  Setting the MESA_XSYNC env var
first will force Xlib to operate synchronously and should make it easier
to locate the problem.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

[Mesa-dev] check-in: AA triangle code

[Brian Paul]

I've checked in a few new files which implement antialiased triangles.
The code isn't finished yet- this is just a checkpoint.  I need to fix
a bug involving edges with very small slopes and the mipmap lod
computation hasn't been implemented yet.  Finally, it will need some
optimization.

The code is disabled for the time being.  If you want to play with it
edit triangles.c and enable the code for _mesa_set_aa_triangle_function().

AA triangles is the last feature of OpenGL which Mesa didn't have.
Still, this is a low priority project for me which I've been working
on for a few hours here & there over the past months.  I'm not commiting
to finishing it for Mesa 3.3.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] matrix stacks

[Brian Paul]

Eero Pajarre wrote:
> 
> I just tried to run my program, which I have developed with
> Win32+Mesa+3dfx, with Win32+Nvidia Open GL+Geforce.
> 
> It did not work ;-(
> 
> I tracked down the reason: I was pushing two times a matrix into
> the projection stack. Geforce driver apparently only
> implements two-level projection stack, which is OK
> according to OpenGL spec.
> 
> 1) I guess the Mesa default might as well be the allowed minimum.

I don't feel strongly about this.  Anyone else?


> 2) when looking at matrix.c I noticed that the overflow conditions
> are different for Modelview and for (projection & texture).
> I think that the ModelView is ok and Projection & Texture are wrong.
> (With the current code, if I define MAX_PROJECTION_STACK_DEPTH == 2
> it will allow two push operations, which I think is not
> how Red Book describes "stack depth == 2))

You're right.  I'm fixing it.


> 3) I think than in types.h all the stacks could be allocated to
> be one element smaller, this because the top of stack is kept
> in separate location. (but I did not check this too well).

Right.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] mesa 3.2 texture.c fix..

[Brian Paul]

relnev wrote:
> 
> This small patch fixes a problem when using a shared palette with
> textures (EXT_shared_texture_palette) for mesa32 (even if
> SHARED_TEXTURE_PALETTE_EXT was enabled, texObj was used to check for the
> current palette format).

Thanks.  I've committed the fix to the 3.2 and 3.3 branches.


> And, in the current dev sources, line 482 of Make-config is missing a
> trailing /

Line 482 looks OK to me, as do the neighboring lines.  Are you sure
your Make-config is up to date?

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Re: [mesa] Link information in Mesa 3.3?

[Brian Paul]

Thomas Tanner wrote:
> 
> On 16-Feb-2000 Brian Paul wrote:
> > Thanks.  I'd like to elaborate on this.  The Linux/OpenGL standard
> > calls for libGL.so to be built with implicit links to all other
> > libraries which it depends on.  I've been working on fixing this
> > in the old-style makefiles.  I'll be checking that in soon.
> >
> > Here's what the old-style makefiles are going to do:
> >
> > libGL.so implicitly links with:
> >   libX11
> >   libXext
> >   libm
> >   libpthread
> 
>  We'll need a check for other multithreading APIs too, right?

I haven't tested the pthread code on anything but Linux.
So, if we're using Linux, link with libpthread, don't otherwise.


> >   libglide2x / libglide3x  if build with 3dfx support
> >   libvga  if build with SVGA driver
> >
> > libGLU.so implicitly links with:
> >   libGL
> >   libm
> >
> > libglut.so implicitly links with:
> >   libGLU
> >   libGL
> >   libX11
> >   libXmu
> >   libXt
> >   libXi
> >   libm
> >
> > I've removed the -lICE and -lSM libs since I don't see the need
> > for them.
> >
> > Can we implement the same thing with libtool?
> 
>  Sure.

Thanks, Thomas.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Question about ProjectionMatrix

[Brian Paul]

Michael Vance wrote:
> 
> On Wed, Feb 16, 2000 at 01:54:51PM -0700, Brian Paul wrote:
> 
> > > Where can I find information about the values in ctx->ProjectionMatrix?
> >
> > Not sure I understand your question.
> 
> Where are the values for ctx->ProjectionMatrix generated? I assume
> they're from a series of:
> 
> glMatrixMode( GL_PROJECTION );
> glLoadIdentity( );
> glOrtho( 0, w, h, 0, 0, 1.0 );
> 
> style API calls. The question is poor, I admit. I was just wondering
> why certain values where, say, -1, or even, according to gdb -0 (ie,
> if this is out of the ordinary), and if these values were perhaps due
> to my rendering setup (below).

In src/matrix.c you'll find the sources for glOrtho() and glFrustum().
They simply build a 4x4 matrix and multiply it with the current
(projection) matrix.


> > I guess I'll need more info on your "rasterization only interface".
> 
> I do all of my own transformation, clipping and projection. The only
> manipulation of the modelview or projection matrices comes from a call
> to glOrtho(). All vertices are specified with x,y screen coordinates
> and a z value between 0 and -1.0. The texture coordinates are supplied
> with a homogenous w coordinate.

Hmmm, I'm not sure what the implications of using fog in this
scenario are.  I've never dealt with this.


> > I was working on a bug fix for LINEAR fog in the 3dfx driver yesterday.
> > Maybe related?
> 
> This is actually with the software renderer. I was able to resolve
> these issues by fiddling with the start/end. For a glOrtho with 0,1.0
> near/far I got appropriate fogging by setting the start to 0.995 and
> the end to 1.0. I assume this is because a great deal of my data is
> clustered towards the far clip plane (terrain data).

Could be.


> However, I am currently exploring a problem with the GL_LINEAR FX fog
> mode, but I was looking into why all of my oow coordinates are set to
> 1.0 in my grVertex structures.

Well, I fixed a bug in the FX driver whereby changes to fog GL_START
and GL_END weren't being caught by the driver.  I haven't checked in
the change yet.

Along the way however, I found that when using an orthographic projection
matrix that all the w coords in the FX driver are 1.  This is correct,
according to the OpenGL spec.  The problem is Glide uses the W coordinate
to compute fog.  It looks like we'll have to stash a scaled/biased?
version of the Z coord into the W coord when using an ortho projection
in order to make fog work.

I'll look into this.


> There did seem to be a large problem with the way the fog tables were
> calculated for FX, given that I got a table filled with 0xFF for the
> start/end I described above.
> 
> > You're looking at _mesa_fog_rgba_pixel()?  The sign of eyez doesn't
> > really matter since for LINEAR and EXP we use the absolute vale and
> > in the EXP2 case we're squaring that value.
> 
> What about the zero values for tmp I was seeing (0 value for the
> variable 'd' in gl_fog_rgba_pixels())? This was causing no fogging in
> the EXP and EXP2 cases because eyez always ended up as 0, f became
> 2.81, clamped to 1.0, and no fogging provided.

d = projectionMatrix[14] = -(far + near) / (far - near) where
near and far are the parameters given to glOrtho.
If you're setting near=0 and far=1 then d should be -1.
If that's not the case, something is very wrong somewhere.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Question about ProjectionMatrix

[Brian Paul]

Michael Vance wrote:
> 
> This is all with respect to software Mesa:
> 
> Where can I find information about the values in ctx->ProjectionMatrix?

Not sure I understand your question.


> I'm tracing through the glFog code, and for the
> code I'm testing the value of eyez is always zero, so for EXP and EXP2
> modes, the e^tmp value is always 1.0, and therefore no fogging is
> provided. Is this a problem with rasterization only interfaces?

I guess I'll need more info on your "rasterization only interface".


> I'm also getting very unexpected behaviour from LINEAR, but I'll have
> more about that later.

I was working on a bug fix for LINEAR fog in the 3dfx driver yesterday.
Maybe related?


> Also, any reason why eyez is calculated differently in EXP,EXP2
> vs. LINEAR? There's an additional negation in the LINEAR case.

You're looking at _mesa_fog_rgba_pixel()?  The sign of eyez doesn't
really matter since for LINEAR and EXP we use the absolute vale and
in the EXP2 case we're squaring that value.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

[Mesa-dev] check-in: Linux library dependency changes

[Brian Paul]

As I wrote earlier, I changed the old-style Makefile so that the
libGL, libGLU, and libglut libraries are implicitly linked with
the libraries that each is dependent on.

This is done with the GL_LIB_DEPS, GLU_LIB_DEPS, GLUT_LIB_DEPS and
APP_LIB_DEPS vars in the Make-config file.  These are used in the
bin/mklib.linux script.

Non-Linux configs haven't been changed.  The old XLIBS var was just
replaced by APP_LIB_DEPS.  People who use OSes other than Linux
are welcome to change the library dependences on those systems.

Also, thread safety is now enabled by default for all Linux configs.

I encourage people to download and test these changes and report any
problems.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Re: [mesa] Link information in Mesa 3.3?

[Brian Paul]

Thomas Tanner wrote:
> 
> On 13-Feb-00 Brian Paul wrote:
> >> Is there any reason Mesa 3.3 is building without link information
> >> in the library? Those of us who dlopen() the library get a dl_error
> >> because we can't anticipate the need of, say, Glide.
> > I guess you're using the GNU configure scripts, right?
> ...
> > Using the GNU Makefiles:
> > % ldd libGL.so.1
> > libc.so.6 => /lib/libc.so.6 (0x4024d000)
> > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000)
> >
> > This is a problem in the configure or libtool scripts.  Hopefully
> > Thomas Tanner (or someone knowledgable in GNU configure) can look
> > into this.
> 
>  That's a bug in the libtool CVS snapshot Mesa 3.3 is using.
>  I'll try to fix it ASAP.


Thanks.  I'd like to elaborate on this.  The Linux/OpenGL standard
calls for libGL.so to be built with implicit links to all other
libraries which it depends on.  I've been working on fixing this
in the old-style makefiles.  I'll be checking that in soon.

Here's what the old-style makefiles are going to do:

libGL.so implicitly links with:
libX11
libXext
libm
libpthread
libglide2x / libglide3x  if build with 3dfx support
libvga  if build with SVGA driver

libGLU.so implicitly links with:
libGL
libm

libglut.so implicitly links with:
libGLU
libGL
libX11
libXmu
libXt
libXi
libm

I've removed the -lICE and -lSM libs since I don't see the need
for them.

Can we implement the same thing with libtool?

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa 3.2 FX driver RGB lookup tables

[Brian Paul]

Neal Tringham wrote:
> 
> (I actually posted this message a week or so ago, but I haven't seen a
> reply and I've noticed that the header was malformed for some reason -
> it both sent and copied the message to Mesa-Dev.  So I'm resending it in
> case it didn't actually get sent out by the list.  In any case, help
> would be appreciated.)

Sorry, I haven't had time to investigate and reply to anything but
simple questions lately.

I wish more people on this list would help with problem solving.



> Neal Tringham <[EMAIL PROTECTED]> writes
> >On a vaguely related note, I'm still getting occasional problems
> >with red to blue colour swapping with Mesa 3.2 on Banshee and Voodoo 2
> >cards (only, as far as I can tell, and quite trivial problems compared
> >to what used to happen), so I'd be grateful if someone could point me in
> >the direction of the lookup table that I think has been added to fix
> >this problem since Mesa 3.1.
> 
> Actually, I think I may have found the tables now, assuming they're the
> FX_PixelToR (G, B) ones near the top of src \ fx \ fxdd.c.

That's it.


>  However,
> what I haven't been able to find is where they appear in the write paths
> (my problems are with writing out coloured lines and coloured debug text
> using glBitmap rather than with reading).  I can see where they're used
> in fxDDReadRGBASpan and fxDDReadRGBAPixels, but I can't find any
> equivalent calls in e.g fxDDWriteRGBAPixels.

The span-writing functions use the LFB_WRITE_SPAN_MESA macro which
is conditionally defined for RGB vs BGR order.

AFAIK, the RGB vs BGR problem was only on pixel read-back, not
writing.  If we indeed have to write different pixel formats depending
on a runtime condition then the code is broken.

I don't have a Banshee card to test with.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

[Mesa-dev] Re: [mesa] Link information in Mesa 3.3?

[Brian Paul]

Michael Vance wrote:
> 
> Is there any reason Mesa 3.3 is building without link information
> in the library? Those of us who dlopen() the library get a dl_error
> because we can't anticipate the need of, say, Glide.

I guess you're using the GNU configure scripts, right?

Using the old-style Makefiles:

% ldd libGL.so.1
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40242000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x402e7000)
libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x402f5000)
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40308000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x40354000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4035c000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40365000)
libglide2x.so => /usr/local/lib/libglide2x.so (0x4037d000)
libm.so.6 => /lib/libm.so.6 (0x404aa000)
libc.so.6 => /lib/libc.so.6 (0x404c6000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000)

Using the GNU Makefiles:

% ldd libGL.so.1
libc.so.6 => /lib/libc.so.6 (0x4024d000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000)


This is a problem in the configure or libtool scripts.  Hopefully
Thomas Tanner (or someone knowledgable in GNU configure) can look
into this.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Texture reference counting (+note about WIN32 compilation)

[Brian Paul]

Eero Pajarre wrote:
> 
> In my application I noticed than when I
> repeat a mixture of glGenTextures and then
> glDeleteTextures, my texture id numbers from
> glGenTextures seem to go up all the time.
> (I had specific conditions, like I hardly ever
> had the texture to be deleted as the current
> texture.)
> 
> When I tried to track what is happening using the debugger
> I noticed that in texobj.c the gl_DeleteTextures never
> called gl_free_texture_object,  the reason being that the
> RefCount field was always 1 when here.
> 
> It appears that the texture object is generated with
> RefCount=1 and all the other operations are symmetric
> pairs, so I don't really understand how the value is going
> to get to 0 as expected here...
> 
> I still assume I am missing something, but what?

If you're calling glDeleteTexture() on a texture which
is currently bound to a texture target (GL_TEXTURE_[123]D)
then the texture can't be deleted until the texture object
is unbound.  Try unbinding the texture object first with
glBindTexture(GL_TEXTURE_2D, 0) and trace through
glDeleteTextures() again.


> PS.
> 
> The current CVS doesn't compile on WIN32 using
> the Makefile.fx
> 
> fixes needed:
> Lines 70 and 149 in glthreads should refer to same WIN32 symbol.
> (I changed it here to use WIN32, but would WIN32_THREADS
> be better??)

It should be WIN32_THREADS everywhere.  To actually enable thread
safety on Win32 you'll need the equivalent of -DWIN32_THREADS in
your project/makefile.


> Line 162 in glthreads should be:
> #define _glthread_DECLARE_STATIC_MUTEX(name)  static _glthread_Mutex name = {0}
> (notice the braces at the end.)
> 
> I will look at how to really implement the macros.

OK.  I don't think it's urgent though.

I've been spending a lot of time on thread safety for Linux.  However,
only the OS/Mesa driver is truly thread safe at this time.  The other
drivers will need some mutex locks.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] mesa_3_2_dev, glinfo

[Brian Paul]

emanuel stiebler wrote:
> 
> Hi,
> 
> why is glinfo reporting a version 3.1, and not 3_2_dev ?

Because I hadn't updated it yet.  I just fixed it.
There are several other places where version strings
have to be checked/updated.  I'll try to do that soon.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] compile problems, win32, mesa_3_2_dev

[Brian Paul]

emanuel stiebler wrote:
> 
> Hi,
> 
> tried:
> 
> nmake /f nmake.mak alldynamic (with the CVS of todays morning) i get:
> 
>Creating library .\Release\glu32\GLU32.lib and object
> .\Release\glu32\GLU32.exp
> tess_fist.obj : error LNK2001: unresolved external symbol
> _tess_clip_polygons
> .\Release\glu32\GLU32.dll : fatal error LNK1120: 1 unresolved externals

tess_clip_polygons() is defined in tess_clip.c.  Are you sure that
tess_clip.c is being compiled successfully?

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa 3.2 for 3dfx / Windows crash problem on Voodoo 1 / Rush boards

[Brian Paul]

Daryll Strauss wrote:
> 
> On Fri, Feb 04, 2000 at 03:47:05PM +, Neal Tringham wrote:
> > FX_grTexCombine_NoLock(GR_TMU1, GR_COMBINE_FUNCTION_ZERO,
> > GR_COMBINE_FACTOR_NONE, GR_COMBINE_FUNCTION_ZERO,
> > GR_COMBINE_FACTOR_NONE, FXFALSE,FXFALSE);
> >
> > call for the (LODBlend is false and tmu!=FX_TMU1) case with
> >
> > if (fxMesa->haveTwoTMUs)
> 
> It's a good fix. I added that case to the code after reading a comment
> from Carmack that indicated that leaving the second TMU active, even if
> it wasn't used, could be a serious performance hit. Of course, if you
> only have one TMU, making that call is bad news. Thanks for the
> patch. It should definetly go in. I think it'll help a few of the
> Banshee users as well.

I'll fix this in the Mesa tree and will bring it into the DRI tree
in my next branch.

Thanks, Neal.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] 3.3 source file re-org

[Brian Paul]

Brian Paul wrote:
> 
> I've reorganized the contexts of some of the 3.3 source files.
   
   contents

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

[Mesa-dev] 3.3 source file re-org

[Brian Paul]

I've reorganized the contexts of some of the 3.3 source files.

Removed:
glmisc.c
glmisc.h

New:
buffers.c   - glRead/DrawBuffers, glClear, etc
buffers.h
hint.c  - glHint and related funcs
hint.h
state.c - state management, used to be in context.c
state.h

I've updated all the Makefiles (except for src/mms_depend for VMS)
so there shouldn't be any compilation problems.

Also rearranged some of the dispatch code to better facilitate
integration with XFree86.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] 3.2_dev errors?

[Brian Paul]

wmilas wrote:

> > fresh checkout, ./bootstrap, ./configure, make
> >
> > After doing the above, it looks like none of the SVGA directory is being
> > compiled. ie, no .o files.
> > ./config does spit out:
> > checking for vga.h... yes
> > checking for main in -lvga... yes
> > and later on:
> > creating src/SVGA/Makefile
> >
> > Yet it doesnt look like any of it actually gets compiled
> >
> > Wayde
> 
> Actually, it does seem to compile everything in src/SVGA. they are .lo's :P
> They just arent getting linked in for some reason.

Is there a SVGA/libMesaSVGA.la file?

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] 3.2_dev errors?

[Brian Paul]

Wayde Milas wrote:
> 
> Compiling cvs 3.2_dev as of today yields wierd lib errors when running a
> OGL app. Im getting:
> sh: error in loading shared libraries: /usr/local/lib/libGL.so:
> undefined symbol: __clear_color16
> 
> This seems to have cropped up in the last coupla weeks. Any ideas?

Looks like that's coming from the new SVGA driver code.

Are you compiling with ./configure ; make or the old Makefile.X11 method?

Make sure src/SVGA/svgamesa16.c is getting compiled OK.

No one else has reported this so far.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

[Mesa-dev] Mesa on sourceforge / bug database

[Brian Paul]

As I mentioned last month, I intend to move the Mesa project onto
SourceForge.net at http://mesa3d.sourceforge.net/

CJ Beyer and I have now moved the web pages and ftp content to
sourceforge.  The www.mesa3d.org IP number will get reassigned
to the new server in the near future.

Also, the bug database is now ready.  Mesa bugs should be filed
at http://sourceforge.net/bugs/?group_id=3  There is a link to
this page from the Documentation/Help Mesa web page.

The Mesa CVS repository will probably be moved after the 3.2 release.

VA Linux Systems hosts both the www.mesa3d.org domain and SourceForge
so the transition shouldn't be difficult.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

[Mesa-dev] texdown.c

[Brian Paul]

Lately I've been curious about the performance of glTexImage2D under
various conditions so last night I whipped up a new test program.
I've check it in demos/texdown.c

You can use the keyboard to change texture size, format, datatype,
toggle scaling/biasing, glTexSubImage loading, etc. and see the
performance in Mtexels/second and MB/second.

I'd like to further optimize glTex[Sub]Image performance in the
future.  In the mean time, this program is interesting to play
with.

I'd like to re-implement texdown.c as a glean test in the future.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] XMesaBufferList

[Brian Paul]

Michael Vance wrote:
> 
> On Thu, Jan 27, 2000 at 12:19:48PM -0700, Brian Paul wrote:
> 
> > So, you're all set now?
> 
> Yep. Offhand, do you know if similar problems exist with other glX
> implementations?

A real implementation of GLX shouldn't have any such problems.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] XMesaBufferList

[Brian Paul]

Michael Vance wrote:
> 
> On Thu, Jan 27, 2000 at 11:49:45AM -0700, Brian Paul wrote:

> > Have you looked at glXReleaseBuffersMESA(Display, GLXDrawable)?
> > If you call this function after destroying your window, Mesa
> > will free the internal XMesaBuffer associated with the drawable.
> 
> No, I have not. This did the trick, though, thanks! I just did it
> after the destroy context call.

So, you're all set now?


> > has been closed is a problem.  I don't know of a way to determine
> > if a given Display * is valid.
> 
> Neither do I, and a quick scan of the XLib manual didn't clue me in. I
> take it this stuff is a result of the 3Dfx drawable weirdness because
> of Glide?

It's not Glide related.  Mesa needs to associate a bunch of private
data with each X Drawable, Visual, etc.  Being a client-side library,
Mesa has no way to offically attach its data to those X data types.
And since Mesa can't know when X Drawables and Visuals are destroyed,
it doesn't know when to free the private associated data.

The garbage collection routine tries to determine when X drawables
have been destroyed.  When Mesa detects that an X drawable has been
destroyed, the associated data gets freed.  As you've found, there
are ways to foil this.

Since traditional Mesa on X is just an Xlib client, it can't make
all the hooks it needs in order to work just like real GLX.
Every so often, somebody falls into one of these traps.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] XMesaBufferList

[Brian Paul]

Michael Vance wrote:

> 
> Another odd thing is that the XSync() is on the flip side of an #ifdef
> Xfree86Server guard--and I'm using the XFree servers for 3Dfx.

So you're using XFree 3.9 with DRI?  I haven't examined how the
X/Mesa garbage collection mechanism works in there.



> On Thu, Jan 27, 2000 at 11:17:47AM -0700, Brian Paul wrote:
> 
> > Yes, XMesaBufferList should be set to NULL when the last XMesaBuffer
> > is removed from the list.
> 
> Hm, free_xmesa_buffer() is never called after the
> glXDestroyContext(). It seems that because I delete my window and
> display after the glXDestroyContext, the garbage collector doesn't get
> rid of it. Then when we try to garbage collect again, the XSync call
> is on a bad display/window, and hangs.
> 
> Comments?

Have you looked at glXReleaseBuffersMESA(Display, GLXDrawable)?

If you call this function after destroying your window, Mesa
will free the internal XMesaBuffer associated with the drawable.

However, when using the DRI, this really shouldn't be needed.

Calling the XMesaGarbageCollect() function after the display
has been closed is a problem.  I don't know of a way to determine
if a given Display * is valid.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] XMesaBufferList

[Brian Paul]

Michael Vance wrote:
> 
> Does the XMesaBufferList ever get reset to NULL when the last context
> is destroyed?
> 
> I'm seeing lockups in XSync() inside of XMesaGarbageCollect() after
> creating, then destroying, then trying to create again... the first
> time through, XMesaBufferList is NULL, I would assume this would be
> true the second time, also?

Yes, XMesaBufferList should be set to NULL when the last XMesaBuffer
is removed from the list.

>From free_xmesa_buffer():

   for (b=XMesaBufferList; b; b=b->Next) {
  if (b==buffer) {
 /* unlink bufer from list */
 if (prev)
prev->Next = buffer->Next;
 else
XMesaBufferList = buffer->Next;   <=== here


The indicated line will cause XMesaBufferList to be set to
NULL if buffer was the only buffer in the list (since its
Next pointer will be NULL).

Do you have a test program?

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] GLUT in 3.4 distro?

[Brian Paul]

Stephen J Baker wrote:
> On Thu, 27 Jan 2000, Jacob (=Jouk) Jansen wrote:
> 
> > Agreed. I think it would be best to include both (or pointers only) in the
> > Mesa-distribution so that application builders can choose. Remember that
> > (free)glut is only a tool-kit to make programming with OpenGL easier. Our work
> > is the graphics-core. which does not depend on the tool-kit chosen.
> 
> Well, there is an argument that Mesa shouldn't bundle GLUT at all - but
> the rationale is that new Mesa users will want to compile the demo/example
> programs - and for that they need GLUT - so we might as well bundle it in
> and save the extra search/download effort.

At some point in the future, I might further split up the Mesa
distro:  main lib, GLU lib, glut, and demos.

People will probably soon switch to the SI GLU library.
GLUT could be mirrored on the Mesa ftp site w/ precompiled libs for
Linux, BSD, etc.

In any case, I don't have time to change this in the near future.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] GLUT in 3.4 distro?

[Brian Paul]

Stephen J Baker wrote:
> 
> On Wed, 26 Jan 2000, Adam D. Moss wrote:
> 
> > Stephen J Baker wrote:
> > > I was wondering about whether we should consider
> > > dropping GLUT from the next major Mesa distribution
> > > (3.4 I guess) and replacing it with 'freeglut'
> >
> > FWIW I think that this is a good idea, though I
> > can't say whether freeglut is mature enough for the
> > 3.4 timescale.
> 
> It *is* rather new code (the first public version is
> only ~3 weeks old) - but like I said - it seems to
> work flawlessly on every test I've tried it with,
> and I'm now using it routinely.  If there was more
> time to work on it, I'm not quite sure what you'd
> use that time to do...apart from run more tests.
> However, since it already runs all the GLUT and Mesa
> example code, it's hard to imagine anyone writing
> more test code to exercise it further.
> 
> We really need people to test it with more real
> applications.
> 
> What is the 3.4 timescale anyway?
> 
> Perhaps it should go into the 3.3 codebase immediately
> and we could back it out again for 3.4 if we are
> snowed under with complaints.  That's what an
> unstable odd-numbered release is *for* - right?
> 
> One other issue that I can see is that freeglut
> currently only works under Windoze and X - not
> MacOS, BeOS, etc, etc.   I don't know if that's
> a problem or not.

I didn't even know that freeglut existing until this morning.

What exactly are the terms of Mark's copyright on GLUT?
I couldn't find it after a quick browse of the GLUT distro.

I don't see an urgency to replace GLUT with freeglut in the
Mesa distro.

I'd like to get 3.2 finished in the next couple weeks
and release 3.3 beta at about the same time.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa-3.3 CVS link error

[Brian Paul]

Dieter Nützel wrote:
> 
> What's the problem here?
> 
> rm -fr .libs/libGL.la .libs/libGL.* .libs/libGL.*
> gcc -shared  accum.lo alpha.lo alphabuf.lo attrib.lo bbox.lo bitmap.lo
> blend.lo clip.lo colortab.lo config.lo context.lo copypix.lo cva.lo
> debug_xform.lo depth.lo dispatch.lo dlist.lo drawpix.lo enable.lo
> enums.lo eval.lo extensions.lo feedback.lo glapi.lo glapinoop.lo
> glthread.lo fog.lo get.lo glmisc.lo hash.lo imaging.lo image.lo light.lo
> lines.lo logic.lo masking.lo matrix.lo mem.lo mmath.lo pb.lo pipeline.lo
> pixel.lo points.lo polygon.lo quads.lo rastpos.lo readpix.lo rect.lo
> scissor.lo shade.lo span.lo stages.lo stencil.lo teximage.lo texobj.lo
> texstate.lo texture.lo translate.lo triangle.lo varray.lo vb.lo
> vbcull.lo vbfill.lo vbindirect.lo vbrender.lo vbxform.lo vector.lo
> vertices.lo winpos.lo xform.lo zoom.lo -Wl,--whole-archive
> X86/.libs/libMesaX86.al OSmesa/.libs/libMesaOS.al X/.libs/libMesaX11.al
> -Wl,--no-whole-archive  X86/.libs/libMesaX86.al
> OSmesa/.libs/libMesaOS.al X/.libs/libMesaX11.al -lc  -Wl,-soname
> -Wl,libGL.so.1 -o .libs/libGL.so.1.2.030300
> X86/.libs/libMesaX86.al(glapi_x86.lo): In function `glAccum':
> glapi_x86.lo(.text+0x0): multiple definition of `glAccum'
> glapi.lo(.text+0xc98): first defined here
> X86/.libs/libMesaX86.al(glapi_x86.lo): In function `glAlphaFunc':
> glapi_x86.lo(.text+0x10): multiple definition of `glAlphaFunc'
> glapi.lo(.text+0x3c8): first defined here
> 
> [snip]
> 
> X86/.libs/libMesaX86.al(glapi_x86.lo): In function
> `glMultTransposeMatrixdARB':
> glapi_x86.lo(.text+0x3b60): multiple definition of
> `glMultTransposeMatrixdARB'
> glapi.lo(.text+0x75ac): first defined here
> X86/.libs/libMesaX86.al(glapi_x86.lo): In function
> `glMultTransposeMatrixfARB':
> glapi_x86.lo(.text+0x3b80): multiple definition of
> `glMultTransposeMatrixfARB'
> glapi.lo(.text+0x75e0): first defined here
> collect2: ld returned 1 exit status
> make[2]: *** [libGL.la] Error 1
> make[2]: Leaving directory `/usr/local/Mesa/src'
> make[1]: *** [check-recursive] Error 1
> make[1]: Leaving directory `/usr/local/Mesa/src'
> make: *** [check-recursive] Error 1
> 1.900u 1.250s 0:03.41 92.3% 0+0k 0+0io 28707pf+0w

Make sure you do a clean build.  The x86-optimized dispatch
functions will collide with the ones in glapi.c if you
don't recompile everything.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] SIGSEGV with Mesa3.1 and Feedback Mode

[Brian Paul]

Richard Guenther wrote:
> 
> Hi!
> 
> I get SIGSEGVs in feedback.c:gl_do_feedback_vertex()
> at the line
> 
>gl_feedback_vertex( ctx, win, color, VB->IndexPtr->data[v], tc );
> 
> VB->IndexPtr is NULL.
> 
> The fault is on my side, though as I rendered geometry without
> Normals in twoside-lightning mode.
> But at least, it shouldnt segfault!?

I'll put in a test for NULL and return an index = 0 in that case.

KeithW, is VB->IndexPtr only valid in color-index mode?

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] SSE info

[Brian Paul]

ralf willenbacher wrote:
> 
> mitch wrote:
> >
> > If I compile SSE support into mesa, can it access the registers without
> > patching the kernel?
> 
> no.. it would produce illegal instructions
> 
> > Does the kernel patch just allow multiple uses or
> > how does that work and what do I need to do? It would be nice if I could
> > just compile with SSE support and not have to recompile my kernel.
> 
> the kernel does not save/restore the xmm regs when switching a task
> without the sse patch

Ralf,

Do you know if an upcoming version of the kernel will fix this?

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] todays cvs

[Brian Paul]

mitch wrote:
> 
> to add to this, I went back to my mesa 3.2 cvs from two weeks ago and now
> everything works just fine. Is the current 3.2 broke or did I miss some
> new update or compile method?

It should work.  You'll have to provide more details in order to get
help.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] compile error

[Brian Paul]

mitch wrote:
> 
> Mesa 3.2 compiles just fine but when I tried to build the current 3.3
> cvs with SSE support, I got the following error
> 
> svgamesa.c:246: structure has no member named `SetBuffer'
> svgamesa.c: In function `SVGAMesaCreateContext':
> svgamesa.c:388: too few arguments to function `gl_create_framebuffer'
> svgamesa.c:332: warning: `rgb_flag' might be used uninitialized in this
> function
> svgamesa.c:335: warning: `index_bits' might be used uninitialized in
> this function
> svgamesa.c:336: warning: `redbits' might be used uninitialized in this
> function
> svgamesa.c:336: warning: `greenbits' might be used uninitialized in this
> function
> svgamesa.c:336: warning: `bluebits' might be used uninitialized in this
> function
> svgamesa.c:336: warning: `alphabits' might be used uninitialized in this
> function
> make[3]: *** [svgamesa.lo] Error 1
> make[3]: Leaving directory `/home/mit/mesa/Mesa/src/SVGA'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/home/mit/mesa/Mesa/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/mit/mesa/Mesa'
> make: *** [all-recursive-am] Error 2

Someone contributed an updated SVGA driver.  It works with 3.2 but
hasn't
been updated for 3.3 yet.  Remove -DSVGA from your compiler flags for
now.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Status of EXT_fragment_lighting and EXT_light_texture?

[Brian Paul]

Gareth Hughes wrote:
> 
> Okay, I'll target the work for 3.5 then.  I've reread the specs
> (including the patent issue stuff) - are we even allowed to do this?
> Can we get permission from SGI to implement both extensions?

I don't know.  Someone will have to ask SGI.  I'm too busy.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] RGB5_A1 for 3dfx mesa

[Brian Paul]

Eero Pajarre wrote:
> 
> I have a patch which adds support for RGB5_A1 internal
> texture format for mesa/3dfx driver.
> 
> (Now it is an appropriate time to inform me that the 3dfx does
> not really support this internal format, and I have imagined
> that the color quality improved when compared to RGBA4)
> 
> The patch contains following:
> 
> 1) one line change, which I think is a bugfix for an issue
> which becomes visible with this internal type
> 
> 2) the required case alternatives to texture code
> 
> 3) a minor, but noticeable, performance improvement
> for PPro (and later), at least with MS compilers.
> This changes some unsigned short temporary
> variables to unsigned (and save PPRO from 16<->32 bit problems)
> 
> I can separate the last issue if needed.
> 
> Would this be ok for 3.3? If yes I can post this to
> the mailing list, or to Brian.
> 
> The fix does not contain the code needed to reply
> to the R/G/B bit length queries (When I did this I
> couldn't find this code in (FX) mesa at all)

You can send me the patch.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Status of EXT_fragment_lighting and EXT_light_texture?

[Brian Paul]

"Hughes, Gareth" wrote:
> 
> Any news/updates on the Mesa implementations of these specs?  I was under
> the impression someone was implementing EXT_fragment_lighting, but haven't
> really heard or seen anything about this lately.

I don't think anyone is working on it.  All I saw was talk, no code.


> If no one is currently working on these extensions, I will (targetted at a
> 3.4/5 timeframe if 3.3 is going out with XFree86 4.0).

I think I'm going to feature-freeze 3.3 pretty soon so that 3.3/3.4 can
safely make it into XFree86 4.0.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] 3.3 & VMS

[Brian Paul]

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi,
> 
> The VMS compile support is up to date. So no objections to create a distribution
> from my side.

Thanks, Jouk!

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Bug in picking mode

[Brian Paul]

Holger Waechtler wrote:
> 
> Hi Brian, hi everybody else,
> 
> Mesa reports wrong depth values in picking mode. Try the pickdepth demo
> from the Red Book examples to see.
> 
> The problem is in feedback.c (gl_select_triangle, gl_select_line and
> gl_select_points):
> 
>   gl_update_hitflag( ctx, VB->Win.data[v0][3] / DEPTH_SCALE );
>   gl_update_hitflag( ctx, VB->Win.data[v1][3] / DEPTH_SCALE );
>   gl_update_hitflag( ctx, VB->Win.data[v2][3] / DEPTH_SCALE );
> 
> should be:
> 
>   gl_update_hitflag( ctx, VB->Win.data[v0][2] / DEPTH_SCALE );
>   gl_update_hitflag( ctx, VB->Win.data[v1][2] / DEPTH_SCALE );
>   gl_update_hitflag( ctx, VB->Win.data[v2][2] / DEPTH_SCALE );
> 
> Complete patch is attached. Could you check it in, Brian ?

Done.  Thanks, Holger.  I meant to investigate this bug but didn't
have the time yet.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

[Mesa-dev] Mesa 3.2, 3.3 heads-up

[Brian Paul]

Status report on Mesa 3.2 / 3.3:

It looks like we'll need Mesa 3.3 for the XFree86 4.0 release
since the new dispatch mechanism is needed for the new libGL.so
design.  The timetable is a bit aggressive so here's the plan.

First, Mesa 3.2 (the stabilization of 3.1) is just about ready.
The only major outstanding bug is a polygon culling bug.  I'm
going to work on that very soon.

Next, Mesa 3.3 will have to feature freeze soon.  The only significant
changes are the new dispatch mechanism and some device driver
changes.  These are documented in the Mesa-3.3/docs/RELNOTES file.
Remaining work includes the assembly language dispatch optimization
and merging of the latest 3.1 bug fixes into the 3.3 trunc.

Those of you who have worked on Mesa device drivers should check
that those drivers have been updated for Mesa 3.3.  See the
docs/RELNOTES for info on the changes.  The OS/Mesa, X/Mesa and
3Dfx/Mesa drivers are already done.

I urge people to get the latest 3.3 sources and compile/test on
your system.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

[Mesa-dev] Help wanted: x86 assembly code for API dispatch

[Brian Paul]

Mesa 3.3 features a new API dispatch system.  In order make it as
efficient as possible it should be implemented with assembly
language.  I'm looking for a volunteer to help with this.

Basically, all of the GL entrypoints/functions need to be implemented
with a tiny assembly language routine which gets a pointer to the
current dispatch table and then does a jump through the table to
the actual implementation of that function.  Arguments to the function
shouldn't have to be copied into a new stack frame (activation record).

Actually, once one of these assembly routines are implemented, the rest
should be trivial to implement.  A few simple macros might do the job
for the entire set of entrypoints.

An x86 implementation is needed first.  Any volunteers?  I'm
prepared to work with whoever volunteers to make this as easy
as possible.

Thanks.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Fullscreen 3dfx problems?

[Brian Paul]

Bernd Kreimeier wrote:
> 
> Jim Kutter writes:
>  > i.e. 512x384 just displays in part of the screen, or worse yet, it falls
>  > back to mesa software.
> 
> On a related note, is there any way to prevent the fallback
> to software, and have glXCreateContext fail instead?

No.


> The automatic fallback into software rendering covers nearly
> 50% of our support calls for Q3A at the moment, as a lot of
> users fail to distinguish "Mesa software GL is slow"  from
> "Q3A is slow!".
> 
> "Can't find/access Banshee/3dfx..." etc. get lost in the
> log output and ignored.
> 
> We also have confusion about GL_VERSION returning 3.1 beta
> for 3.2, etc.

3.1 beta != 3.2.

There should be no confusion there.


> Is there any chance nice to set this
> string automatically during configure, with proper GL
> version, Mesa version, and creator/creation date?

It should be fine as-is.  The problem, I think, is people
using 3.1 BETA version.  Whenever I see people mention 3.1
beta in their bug report my first response is to tell them
to upgrade to 3.1 final.


> That way
> support/FAQs can ask for the value of this string. Q3A
> selects its GLs in a way confusing to users, and often
> picks a software-only /usr/lib/libGL.so installed by the
> distro.
> 
> Further: if we submitted patches for more detailed
> GL_RENDERER information, is there a preferred format for
> this string? We would like to identify pure passthrough
> (VG, V2) and troublesome (VR) cards reliably, as they
> require different X11 handling (focus). I am even tempted
> to add PCI vendor/device ID (or some string mapping) here,
> in case we have to deal with oddball boards.

I haven't looked at the format for GL_RENDERER for the 3Dfx
driver lately but I thought it was detailed enough to determine
the type of card you're using.

If not and you want to change it, please don't break backward
compatibility.


> With Banshee, V3/4/5 we might also have to distinguish
> Glide based fullscreen (if any) from X-in-window, for
> XFree86-4, if the old mode of operation is still available
> then.

You should be able to determine that from the GL_RENDERER string.

If I'm missing the point, please provide some concrete examples.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Stale lockfile in /cvs/mesa3d/Mesa/src/GGI/default

[Brian Paul]

Jon Taylor wrote:
> 
> Can someone fix this?  I can't commit

Done.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] sse

[Brian Paul]

mitch wrote:
> 
> sorry, one more question. I don't see the sse option in the readme or
> install. How do I configure Mesa with SSE support? Thanks.

SSE/Katmai optimizations are only in Mesa 3.3 now.
You can use the old style makefile targets linux-katmai or
linux-katmai-glide to build.  Or, using autoconfig, type
"./configure --enable-katmai"

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] FX-Mesa and glXDestroyContext() SIGSEGV

[Brian Paul]

Michael Vance wrote:
> 
> On Tue, Jan 04, 2000 at 04:12:22PM -0700, Brian Paul wrote:
> 
> > catching signals and registering atexit() handlers.  However, they're
> > there to solve other problems.
> 
> Right.
> 
> > I'm not sure that testing glbTotNumCtx is the "right" thing to do.
> 
> No, but it's trivial, and works...
> 
> > [ keep contexts in list... ]
> > How does that sound?
> 
> How does the software Mesa driver manage contexts?

That's a broad question.  But I don't believe any of the current drivers
keep a list of all contexts.  We do keep lists of visuals and drawables
in some drivers though.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] FX-Mesa and glXDestroyContext() SIGSEGV

[Brian Paul]

Michael Vance wrote:
> 
> If you happen to register an atexit() handler in your code that calls
> glXDestroyContext(), and then you create a context, FX-Mesa will then
> register an atexit() handler itself. When your program exits, the
> FX-Mesa handler is called first, it brute force deletes the context,
> and then your call in glXDestroyContext() causes memory corruption
> because it doesn't know that the context has been freed already. This
> is bad.
> 
> It would seem the trivial solution is to guard the actual deletion in
> fxMesaDestroyContext() with an if( glbTotNumCtx ) { } after the ref
> count decrement. I can submit a patch to do this if necessary.

Strictly speaking, the FX driver shouldn't be in the business of
catching signals and registering atexit() handlers.  However, they're
there to solve other problems.

I'm not sure that testing glbTotNumCtx is the "right" thing to do.

Perhaps all the contexts we made should be kept in a list.  When
we delete a context remove it from the list, but only after checking
that the context is in fact in the list.

How does that sound?


> Also, is it just me or is the glbTotNumCtx=1 line in cleangraphics() a
> little unsafe? Does the FX driver implicitly reject the notion of
> multiple contexts?

The FX driver when used with traditional/stand-alone Mesa wasn't 
intended to handle multiple contexts (full-screen mode implies one
context) but it often does work.  When the FX driver is used within
the DRI framework multiple contexts are supposed to work as expected.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

[Mesa-dev] Fwd: bug in linux mesa with 3dnow opts.

[Brian Paul]

PimpSmurf wrote:
> 
> make linux-3dnow-glide fails in current 3.1 version also.
> I reported the cvs as doing this, not knowing that it current version
> did also.
> here is the screen dump.
> 
> make[2]: Entering directory `/usr/src/Mesa-3.1/src'
> make[2]: *** No rule to make target `FX/X86/fx_gen_regoff.c', needed by
> `FX/X86/fx_gen_regoff'.  Stop.
> make[2]: Leaving directory `/usr/src/Mesa-3.1/src'
> make[1]: *** [linux-3dnow-glide] Error 2
> make[1]: Leaving directory `/usr/src/Mesa-3.1/src'
> make: *** [linux-3dnow-glide] Error 2
> 
> FX/X86/fx_gen_regoff.c doesn't exist. dont know what is going on here.
> 
> cant find it anywhere either.
> poopoo.
> 
> Any ideas?
> PimpSmurf


What's the story on fx_gen_regoff.c?  I thought this was obsolete.
If so, could someone in the know fix src/Makefile.X11?

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

[Mesa-dev] configure: dec/alpha flags

[Brian Paul]

Someone reported a compiler flag problem using the GNU configure
build method.

The flag -ieee_with_no_inexact must be used when compiling
for the Alpha processor using the DEC compiler.  Otherwise
there's a problem with FP exceptions.

The old-style Mesa makefiles did this but I'm not sure how to
modify the config.sub or config.guess files to do the same.

Can anyone help?

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Build problem with Mesa 3.1 for Windows / FX

[Brian Paul]

Eero Pajarre wrote:
>
> Ok this seems to work:
> (Neal, could you please test this with your VC version?
> and propably it would be best that some Linux/Gcc users
> would try this now as well)
> 
> 1) add FX\X86\fx_3dnow_fastpath.obj to the end of
> X86OBJS variable at makefile.fx.

Done in 3.2 and 3.3 CVS.


> 2) apply the attached patch to
> 
> src/FX/X86/fx_3dnow_fasttmp.h

The patch fails for me.  Could you sent the entire file?


Eero, would you like CVS-write access?

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

[Mesa-dev] dead cvs lock- don't check in

[Brian Paul]

I discovered there's a dead CVS lock half-way through tagging
the sources (mesa_3_1 tag).  I have to wait for VA Linux to
remove it.  Please don't check anything in until this is resolved.
I'll post when it's done.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

[Mesa-dev] 3.1 final released!

[Brian Paul]

I'm happy to announce that Mesa 3.1 is now available!

It's available for download from the Mesa web site at www.mesa3d.org

There's a lot of new things in Mesa 3.1.  Please see the
included docs/VERSIONS and docs/RELNOTES files for details.

I'd like to thank a few people who have made very significant
contributions to Mesa 3.1:

   Keith Whitwell - highly optimized T&L code
   Josh Vanderhoof - x86 assembly language optimizations
   Holger Waechtler - 3DNow! assembly language optimizations
   Gareth Hughes - GLU 1.2 polygon tessellator

My apologies to those I'm forgetting.


Happy Holidays,

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

[Mesa-dev] 3.1 release

[Brian Paul]

I'm planning on making the final 3.1 release really soon now,
maybe today.

Keith and I fixed a few of the recently reported bugs over
the weekend.  I encourage people to update from CVS and test
their apps.  Report problems ASAP.  However, it'll take a
pretty serious bug to stop the release.  I believe 3.1 is
solid enough for >95% of the users.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] texture management

[Brian Paul]

John Carmack wrote:
> 
> Since new driver interfaces have been brought up, here are some thoughts
> about improving texturing:
> 
> With the current architecture, it isn't possible to accelerate
> glCopyTexSubimage, even though most non-voodoo hardware is capable of doing
> it completely asynhronously.  The requirement of having an up-to-date copy
> of the texture in main memory forces a hardware sync and software reading
> of the frame buffer.  There are many interesting rendering algorithms that
> are only feasable with a full speed copytexsubimage.
> 
> Texsubimage (and
> teximage, but that isn't really an issue) still operates at less than half
> the potential speed.  A max-performance implementation would read from the
> client space and write (potentially 16 bit textures) directly to the card's
> command buffers. The current implementation, even on the fast path, first
> reads from the client and writes to the main memory texture, then reads
> from there and writes to the command buffer. 100+ mb/sec texture downloads
> should be possible through the standard api calls.
> 
> It is not uncommon to
> have systems now with 16mb/64mb or 32mb/128mb of video memory vs system
> memory.  Especially when the card is storing 16 bit textures and 32 bit
> mirrors of the textures are stored in main memory, it is obvious that there
> is significant inefficiency.  Avoiding the main memory copies of resident
> textures would make a significant difference with Q3 on 64 mb systems.
> 
> All of these could be addressed by allowing Mesa to manage a texture object
> without having the texels in main memory.
> 
> The memory savings and copytexsubimage features could be enabled with just
> two additions to the current architecture: the driver would need a call
> into mesa to have it free the texels for a given image (or it might just
> free it itself and zero the pointer), and mesa would need another driver
> call to have the driver fill in an image with a texture it is managing when
> it is needed for a software path.
> 
> Getting the max speed texsubimage would need an additional driver entry
> point, called after all the user parameters have been validated, but before
> mesa tries to copy the texels into a main memory buffer.  If the driver
> claims it, mesa would skip the local update (the local image would have
> been freed by the driver).
> 
> One possible objection to this type of arrangement is that a card with 16
> bit textures would have permanently lost the low order bits of the texels
> after upload, and any glGet on the texels would return the lower precision
> values.  I don't think this is non-conformant, but I would like to hear
> other views on it.
> 
> Implementing these features would be fairly easy on the matrox driver (and
> soon the rage pro driver).  Interestingly, this type of architecture is not
> possible on win9x, because parts of win9x can step on video memory and only
> tell you about it after the fact, requiring you to always be able to
> regenerate any needed textures from main memory.


I think we're in complete agreement on the two big things needed:

1. Don't require Mesa core to store a copy of the texture.

2. Implement glTexSubImage functions in the device driver.


One question is this: how early in the glTexImage (or glTexSubImage)
function should the corresponding device driver function be called?

If it's called early, then the driver will have to check quite a bit
of state and perhaps do a lot of work (pixel scale, bias, lookup,
conversion from all possible formats and types, pixel unpacking ,etc)

That's a lot of state examination but in most cases the image is in
a simple format and pixel transfer ops aren't enabled.

If the driver function is called later (after pixel transfer, type
conversion and unpacking), then the driver's function can be much
simpler.

Here's one idea:  have a TexImage2D() driver function which is called
early and a SimpleTexImage2D() function which is called later and
passes data in a simplified format.  The driver could implement
either function, depending on how much the driver writer wanted to do.

Or, if a single TexImage2D() function existed that returned true/false
to indicate success/failure, it could be called at several points
inside glTexImage2D() until it finally worked or we fell all the way
onto the software path.


-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thread support in the GLX code???

[Brian Paul]

Randall Frank wrote:
> 
> Hello,
> I ran into a snag today, it appears that the glx routines
> are not thread aware?  In my example, I am rendering to multiple
> gl contexts simultaneously using pthreads under Linux/Irix.  Mesa
> with thread support enabled seems to work ok, but I had the
> need to make a couple of glx calls, and they failed.  For
> example, glXGetCurrentContext() returned the same context for
> every thread (but glXMakeCurrent() seemed to work).  The code
> runs fine against SGI OpenGL under Irix.  I have not had the time
> to look into it deeply (I rewrote my app so it did not require the
> failing calls), but is this a known problem and is anyone looking
> into it?

Neither the Xlib driver nor the GLX code is thread-safe.  The
people who implemented thread safety only did so for the OSMesa
interface and driver.

I expect that I'll be putting some work into thread safety for
Mesa 3.3.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

[Mesa-dev] Mesa 3.3 check-ins

[Brian Paul]

I've check in a bunch of new stuff into the main / 3.3 branch:

1. Device driver support for hardware stencil buffers.
   Four new functions were needed to access the stencil values when
   falling onto a software path:

   WriteStencilSpan
   ReadStencilSpan
   WriteStencilPixels
   ReadStencilPixels


2. Changed device driver interface for hardware Z buffers.
   These functions were removed:

AllocDepthBuffer
DepthTestSpan
DepthTestPixels
ReadDepthSpanFloat
ReadDepthSpanInt

   and were replaced with:

WriteDepthSpan
ReadDepthSpan
WriteDepthPixels
ReadDepthPixels

   The new functions are more similar to the color and stencil buffer
   functions and remove some complexity from device drivers.


3. The gl_create_framebuffer() function now takes several boolean
   flags to indicate explicitly which ancillary buffers (depth,
   stencil, alpha, accum) should be implemented in software.
   Previously, a depth buffer was being allocated with malloc even
   if a hardware depth buffer was present.


I've updated the Xlib, OSMesa and 3Dfx drivers with the necessary
changes.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] .cvsignore update patch

[Brian Paul]

Ralph Giles wrote:
> 
> Hi everyone,
> 
> Here's a patch against the mesa_3_2_dev branch that updates the .cvsignore
> files to ignore the generated files. It also adds some new ones. I got
> tired of seeing all those '?' lines when I did an update. ;)
> 
> One caveat: One of the more common things left out was the "Makefile". I
> remember there being some talk of still distributing a 'default' Makefile
> at some point. I've only added it to .cvsignore where there isn't
> currently one in cvs, but this can be an annoying bug if you try and add
> such a file in the future.

I've applied your patch (manually).

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] GLX_ARB_get_proc_address

[Brian Paul]

Doh!  The subject should have been GLX_ARB_get_proc_address (note
the X).

The extension adds glXGetProcAddressARB() to GLX, not the core GL.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

[Mesa-dev] GL_ARB_get_proc_address

[Brian Paul]

This extension was approved at this week's OpenGL ARB meeting.
It will operate context independently, for those of you wondering.
I've checked in my changes to support it in Mesa 3.1/3.2.
Implementing it in Mesa 3.3 will take a bit longer.

The latest version of the spec for this extension is at
http://reality.sgi.com/opengl/linux/get_proc_address.spec
Though, there are a few edits pending in order to polish it up.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] New GLU conformance?

[Brian Paul]

"Hughes, Gareth" wrote:
> 
> I've just added the ability to do boundary-only tessellation, ie. just
> output the final contours as line loops.  What are the chances of running
> the new tessellation code through the OpenGL conformance tests?  Can we
> still do that?

I've had the 1.0 conformance tests for a couple years now.  I plan
to do the last testing this weekend.  I'll include GLU tessellation.


> I've run pretty much every test app I have that uses the tessellator and
> they all seem to work pretty well.  There may still be a slight problem with
> the edge flag settings, so I'll be investigating this over the next day or
> two.

OK.

I'm hoping for a final 3.1 release this weekend or early next week
(REALLY!).

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] new transform-functions in SSE-assembly.

[Brian Paul]

Eero Pajarre wrote:
> 
> Andre Werthmann wrote:
> >
> > I have committed the remaining transform-functions written in SSE-assembly.
> > That means now all the transform_points* functions are done in SSE-assembly :)
> >
> > These functions are faster than the fpu-ones, but to get  the most speed out of 
>the SSE the data, the SSE-instructions
> > are working on (transform-matrix,  src_vertices and dst_vertices) must be 16byte 
>aligned.
> >
> > I have to find a way how to do it best (while keeping the code as clean as 
>possible !).
> >
> 
> I updated my copy of the Makefile.fx (for Windows 32 compilation) to
> include the katmai files. I only have a PPRO so I don't know if it
> really
> works, but it compiles and doesn't seem to cause problems on my
> computer.
> 
> So if there are any windows users who can test this please do so...
> 
> I will attach the patch into this message.
> 
> While doing this I noticed that the previous version
> of Makefile.fx did not contain the -DUSE_3DNOW_ASM flag,
> which I included here.
> 
> This addition should propably be done also to the
> 3.2 sources.

I've applied your patch to the main, 3.3 branch.  The katmia
code is not in the 3.1/3.2 branch.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

[Mesa-dev] sourceforge.net

[Brian Paul]

For those of you who haven't heard of it yet, SourceForge is
VA Linux System's new site for hosting of open-source development
projects.  Check it out at www.sourceforge.net  It looks really
promising and is already hosting many projects.  Precision Insight
will be storing its DRI-related work there too.

SourceForge offers everything an open-source project needs:
ftp, http, cvs, mailing lists and bug databases (something I'm
especially anxious to get).

I'd like to move the Mesa project to sourceforge by early next
year.  Since Mesa is currently hosted by VA Linux on openprojects.net
the transition _should_ be straightforward (yeah, I've heard that
one before).

Between my PI work, business trips and Xmas vacation I don't
think I'll have time to oversee the transition until January.

In the mean time, you should visit SourceForge and register
a personal login account.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] In-window-hack for FxMesa on Win32

[Brian Paul]

Eero Pajarre wrote:
> 
> (I think I have mentioned this sometimes before)
> 
> For some unknown reason I cannot get the hot key for
> toggling the in-window rendering for FxMesa to work
>  on my Win95 machine.
> 
> (I guess it must work for other people)
> 
> The attached patch fixes this on my computer.
> It adds one line (case alternative
> WM_SYSKEYDOWN)
> 
> If nobody objects, I suggest adding this to
> 3.2 and 3.3.

Done.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Phong shading integration

[Brian Paul]

JONATHAN DINERSTEIN wrote:
> 
> As an example of the kind of rendering errors I want to get rid of,
> check out:
> http://www.npl.com/~jon/
> 
> It is a jpeg so some amount of loss has happened, but you can still easily see
> the problem.  All I did was have GLUT draw a sphere of about 20 slices by 10
> stacks.  There is no specular or ambient, and I used the default settings for
> LIGHT0.
> 
> As you can see, except where the lighting is really bright, the seam between
> polygons is brighter than the interior of polygons.

This is called "Mach banding" and is a side effect of the way our eyes
perceive intensity changes.


> So, even when doing no
> specular, there's still some rather poor rendering.  I never got this kind of
> error in my own Gouraud engine, so my guess is that this is caused primarily by
> using fixed point math.  Am I wrong here???

The use of fixed point math in itself shouldn't be a problem.  But
one thing that occurs to me is this:  after Mesa computes vertex
colors from the lighting parameters, the color values are stored
as GLubytes.  Perhaps we should store fixed-point values instead
so that the fractional bits aren't lost before rasterization.

I'm not sure this will really help with the Mach banding though.


> If it helps at all, I uploaded my source file (VERY brief).  Also, I got
> virtually identical results between OpenGL under Windows and Mesa on my Linux
> box.

Thanks.  I don't think I'll have any time to investigate this
for a while though.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: glReadPixels/[Mesa-dev] Bugfix for DrawPixel

[Brian Paul]

Bernd Kreimeier wrote:
> 
> Brian Paul wrote:
> > I recently rewrote the fxDDReadRGBASpan() and fxDDReadRGBAPixels()
> > functions.   Before, these functions were returning bad (imprecise)
> > values.  Instead of doing bit masking and shifts a lookup table is
> > now used.
> 
> This is in the 3_2 stable branch I take it?

Yes, and in the 3.3 (main) branch.


> > The initialization of the lookup tables is dependant on the
> > type of 3Dfx card you have.
> > What kind of card do you have?  Can you step through the
> > setup code (see fxInitPixelTables()) and locate the problem?
> 
> We are taking a look. Using Voodoo3 3000 AGP Glide 2.60 and
> Mesa 3.2 from CVS. Haven't checked with V2 (2.53) and VG (2.46) yet.

OK, let us know what you find.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] New GLU

[Brian Paul]

"Hughes, Gareth" wrote:
> 
> > Hi All,
> >
> > I just checked the performance of the new GLU with the text3d demo in
> > xlockmore. (why is the new version only in the 3.2 branch and not in
> > the 3.3?) A lot of letters in the demo are not correctly processed
> > (=look awfull!!!)
> 
> Okay, I'll take a look at that now.
> 
> I'm also cleaning up the warnings I get under both Linux and Win32.
> Anyone mind if I do the NURBS stuff while I'm at it?  Has this been
> changed much in the main branch?

No one has touched the NURBS code in a long time.  Feel free to
clean it up as needed.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Phong shading integration

[Brian Paul]

Brad Grantham wrote:
> 
> > From [EMAIL PROTECTED]  Mon Nov 29 21:56:58 1999
> >   Hi everybody,
> >
> >   I've been needing to produce non-realtime high quality output from
> > OpenGL programs I've already written.  As a result, I'm adding Phong shading to
> > Mesa.  I'd like to do this right, though, so that it can be a standard part of
> > the distribution.  Granted, it won't fit into the standard OpenGL architecture,
> > but I think it would be worth having =).
> 
> Actually, a form of it does.  See below.
> 
> >   Anyway, here's my plans.  Please let me know if anything is off so I
> > can do this right the first time:
> >
> >   o Define GL_PHONG in gl.h as 0x1D02.  Currently unused, immediately
> >   precedes GL_SMOOTH.
> 
> You might be better off incorporating SGI's fragment lighting
> extension into Mesa.  Go to
> http://www.opengl.org/Documentation/Extensions.html for the spec
> ("EXT_fragment_lighting").  Maybe contact Jon Leech at SGI
> ([EMAIL PROTECTED]) to ask about whether SGI would care or even help.
> (While you're at it, put in EXT_light_texture, too. :)
> 
> Fragment lighting adds another set of lights which work on the
> fragment (i.e. pixel) level and have slightly different semantics.
> This is presumably better suited for hardware implementations.  (I
> understand you may want to short-circuit this to get to helping your
> program.)


You should check out the spec for EXT_frament_lighting at
http://reality.sgi.com/ljp_engr/registry/EXT/fragment_lighting.txt

There's some IP/patent issues to consider.

Code-wise, the main things you'll need are normal vector and
eye-coordinate interpolation across triangles.  Eye coordinate
interpolation might be kind of complicated with respect to
perspective projection.  I'd have to carefully read the spec
to know how precise these interpolations must be.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Bugfix for DrawPixel

[Brian Paul]

Michael Vance wrote:
> 
> On Fri, Nov 26, 1999 at 12:48:47PM -0700, Brian Paul wrote:
> 
> > Furthermore, glCopyPixels needed the same fix.
> 
> As an addendum, is there a color swap bug in the 3Dfx glReadPixels
> implementation? I was going to have a hack at fixing it (ReadRGBASpan,
> et al), but there seem to be two separate imps in fxspan.c and
> fxddspan.c...

fxspan.c is obsolete (and should be removed).

I recently rewrote the fxDDReadRGBASpan() and fxDDReadRGBAPixels()
functions.   Before, these functions were returning bad (imprecise)
values.  Instead of doing bit masking and shifts a lookup table is
now used.

The initialization of the lookup tables is dependant on the
type of 3Dfx card you have.

What kind of card do you have?  Can you step through the
setup code (see fxInitPixelTables()) and locate the problem?

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lock on Win32/Rules

[Brian Paul]

"Hughes, Gareth" wrote:
> 
> I'm committing an update to the Win32 makefiles so they build GLU correctly
> with the changes I've done lately.  There seems to be a lock hanging around
> on Win32/Rules...

I don't have permission to remove the lock file.  I've send a
message to the admins ([EMAIL PROTECTED]) to
have it removed.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] I should say 110% done...

[Brian Paul]

Gareth Hughes wrote:
> 
> Okay, I've added some code that gobbles up zero-area ears as the are
> created.  This fixes the last of the problems with the Red Book demos.
> 
> I'm committing those changes now.  So, the clipping/winding rule
> operations are done, and the tessellation itself is done.  Again, I'd be
> happy with a 3.1 release now so I can spend some time bashing on it with
> the ECMWF polygons and things like GLE etc and incorporate any fixes
> into 3.2/3.3.  Brian?

OK, sounds good.  Thanks for your hard work on this project.


> When I get some time, I'll write some READMEs or something about the
> code to expand on the algorithms I've used.  I've had to pretty heavily
> modify the clipping algorithm in particular, so this might be useful for
> those of you who are interested.

Yes, please do so.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Bugfix for DrawPixel

[Brian Paul]

Brian Paul wrote:
> 
> [EMAIL PROTECTED] wrote:
> >
> > Hi,
> >
> > here is a bugfix for DrawPixel:
> >
> > When depth test is disabled but fog enabled, the z-span for "gl_fog_rgba_span"
> > is uninitialized.
> >
> > [Bug found with Flightgears panel & GLX-MGA - I don't know if FlightGear
> >  really wants a fogged panel but that's their bug ;-)]
> 
> Thanks for the patch.  I've applied it to both branches.
> Also, there were actually two places (RGBA and CI paths) which
> needed this change.

Furthermore, glCopyPixels needed the same fix.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Bugfix for DrawPixel

[Brian Paul]

[EMAIL PROTECTED] wrote:
> 
> Hi,
> 
> here is a bugfix for DrawPixel:
> 
> When depth test is disabled but fog enabled, the z-span for "gl_fog_rgba_span"
> is uninitialized.
> 
> [Bug found with Flightgears panel & GLX-MGA - I don't know if FlightGear
>  really wants a fogged panel but that's their bug ;-)]

Thanks for the patch.  I've applied it to both branches.
Also, there were actually two places (RGBA and CI paths) which
needed this change.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] version numbering in 3.2 and 3.3

[Brian Paul]

Ralph Giles wrote:
> 
> On Wed, 24 Nov 1999, Brian Paul wrote:
> 
> > > The mesa_3_2_dev branch still thinks it's 3.1, and our configure script
> > > reports it as such.
> >
> > It's correct as-is.  The mesa_3_2_dev branch will end with the release
> > of Mesa 3.2 but the Mesa 3.1 release is also pending on this branch.
> > 3.2 will be the stabilization of 3.1.
> 
> Ah. Fascinating. :)
> 
> > I know this is a bit of a mess now.  But 3.1 should be released soon.
> > I'm just waiting for the final GLU tessellator code and some bug fixes
> > from Keith Whitwell.  Then, that branch really will be 3.2 code.
> 
> Ok, I guess I'd mis-understood your release plans. Sorry I haven't been
> following the list very carefully lately. I had heard you were switching
> to the even/odd release module, and so assumed that 3.1 would be released
> as 3.2.

After 3.1 is released I expect there will be another batch of bug
reports since a lot of people don't try the beta releases and a _lot_
of code has changed since version 3.0.  The bugs we iron out of 3.1
will result in 3.2, the final, stable release.


> Are there plans for internal changes between 3.1 and 3.2?

No, just bug fixes/cleanup.


> Which one should be be supporting?
> I don't think it makes sense for us (the glx project) to
> track 3.3 for now, since we're trying to get out a release, but I'm
> wondering if we'll want/need to support both 3.1 and 3.2.

3.1/3.2 will be the same, except for bug fixes.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] version numbering in 3.2 and 3.3

[Brian Paul]

Ralph Giles wrote:
> 
> Hello all,
> 
>  Over on the glx list, we've been seeing reports from users confused about
> mesa versions. We're currently tracking 3.2 cvs, and no doubt all this
> will go away when 3.2 is actually released. However, aside from those who
> don't read our documentation, two things seem to be confusing people:
> 
> The mesa_3_2_dev branch still thinks it's 3.1, and our configure script
> reports it as such.

It's correct as-is.  The mesa_3_2_dev branch will end with the release
of Mesa 3.2 but the Mesa 3.1 release is also pending on this branch.
3.2 will be the stabilization of 3.1.

I know this is a bit of a mess now.  But 3.1 should be released soon.
I'm just waiting for the final GLU tessellator code and some bug fixes
from Keith Whitwell.  Then, that branch really will be 3.2 code.


> The documentation in 3.2 and 3.3 in general hasn't been updated with the
> new version numbers.
> 
> Neither of these reassure the less-clueful that they've got the right
> version. :)

Sorry, I know.  But as soon as 3.1 is released things should be clearer.



> Attached are two patches against the 3.2 and 3.3 branches that attempt to
> help with this. The one against 3.2 changes the version declaration, and
> both contain misc. documentation updates. I didn't do the os-specific
> READMEs, but tried to update the main files otherwise. I also made a
> wording change from "copyright" to "license" in the copyright sections,
> which I think is more accurate.
> 
> This is all quite sloppy, and shouldn't be considered a complete fix. I
> just wanted to do a quick partial cleanup.

I'll apply the 3.2 patch after 3.1 is done.  I'll apply the 3.3 patch
ASAP.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Color index question...

[Brian Paul]

Heriberto Delgado wrote:
> 
> I have a question about color index management.  In all the books I've read about
> GL, there is NO definition of how RGB colors must be distributed across color 
>indexes;
> apparently, it's implementation-dependent.  However, if we look at the Palm, we'll 
>see it
> has a "white" screen (by now, it's green, but the soon-to-come Color Palm will have 
>it
> white), and the pixels written to the screen are black, in contraposition with most 
>PC video
> screens.  GL's reference manual says that the default clear color (the one specified 
>with
> glClearColor() ) for RGB windows is (0,0,0), and for color index windows, it must be 
>0.  So
> this ends up in we have a default clear color of "black" for RGB windows, but a 
>"white"
> (color 0) color for color index windows in the Palm!  I perfectly understand one 
>thing is the
> standard, and another thing (sometimes very different) is what people actually do. 
>So, my
> question:  Should I use the color indexes that the Palm uses now (0 = white, max = 
>black), or
> should I remap these indexes to obtain a closer match to the current implementations 
>of GL,
> including Mesa?

In OpenGL the default glClearIndex is zero but that does not imply any
particular color such as black or white.

If your color table/palette is fixed (ala X's StaticColor visual) then
it's up to you (or the OS) to scan the table for the desired color and
use the corresponding index for clearing.

If your color table isn't fixed but shared with other clients then
typically you have to request a read-only or read/write table entry from
the window manager.

So on the color Palm for example, if you want a white background you'll
probably have to ask the Palm OS for the white color index.

The bottom line is: don't hard-code your color indexes.  Cooperate with
the OS or window system's color table allocator.

A color-index OpenGL app which assumes index 0 is black (or white) is
broken.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] glu.h

[Brian Paul]

Eero Pajarre wrote:
> 
> The latest glu.h update causes some problems for VC++ 5.0.
> 
> The compiler gets upset because of the prototype parameter
> names "near" and "far". Apparently it has somekind of deja-vu
> experience because of Microsoft C history.
> 
> So I hope the parameter names can be changed a little.

Done.

-Brian


___
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev