mesa3d-dev

Re: [Mesa3d-dev] Proposed new DD texture interface

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

Gareth Hughes wrote:
> 
> After looking into the current single-copy texture mechanism, I'd like
> to propose a couple of changes.  This will involve completely removing
> the old interface, as well as providing a much more driver-friendly
> approach to texture image storage.  Many of these ideas are similar to
> features found in the SI, at least from the top level.  The
> implementation of these ideas would be quite different in our case,
> however.
> 
> First, we add a struct gl_texture_format as follows:
> 
> struct gl_texture_format {
>    GLint internalFormat;        /* Mesa format */
> 
>    GLint redSize;
>    GLint greenSize;
>    GLint blueSize;
>    GLint alphaSize;
>    GLint luminanceSize;
>    GLint intensitySize;
>    GLint indexSize;
> 
>    GLint bytesPerTexel;
> 
>    /* Functions to return individual texels.
>     */
>    void (*extractTexel)(...);
>    ...
> };
> 
> We define a set of these structures:
> 
> const struct gl_texture_format gl_tex_format_argb8888 = {
>    MESA_FORMAT_ARGB8888,
>    8, 8, 8, 8, 0, 0, 0,
>    4,
>    ...
> };
> 
> const struct gl_texture_format gl_tex_format_rgb565 = {
>    MESA_FORMAT_RGB565,
>    5, 6, 5, 0, 0, 0, 0,
>    2,
>    ...
> };

Do these structs initialize the extractTexel function pointer?
I don't think they can.  Or the driver would have to override
the defaults.


> and so on.
> 
> We add a pointer to such a structure to struct gl_texture_image, and add
> a driver callback to allow the driver to select the best format.  Thus,
> _mesa_TexImage*() has something like the following:
> 
>    struct gl_texture_format *texFormat;
> 
>    texFormat = (*ctx->Driver.ChooseTextureFormat)( ... );
> 
>    texImage->texFormat = texFormat;
> 
>    texImage->RedBits = texFormat->redSize;
>    texImage->GreenBits = texFormat->greenSize;
>    texImage->BlueBits = texFormat->blueSize;
>    texImage->AlphaBits = texFormat->alphaSize;
>    texImage->IntensityBits = texFormat->intensitySize;
>    texImage->LuminanceBits = texFormat->luminanceSize;
>    texImage->IndexBits = texFormat->indexSize;

It seems redundant to store the bits/channel info in both structs, but
that's a minor issue.


> The Driver.TexImage* callbacks are now no longer allowed to fail.

Because it'll be up to core Mesa to unpack and store the texture image
under all circumstances?

I'm a bit worried about expecting core Mesa to do all this.  Consider
a card that uses some sort of tiled texture memory layout.  I think it
should be up to the driver to handle image conversion for something
like this and not burdon core Mesa with strange conversion routines.

The idea behind the texutil.c functions was to simply provide some
helper routines for drivers.  Drivers can take them or leave them.


> _mesa_TexImage* hands control over to the driver, which does any
> driver-specific work (such as the tdfx driver making sure the aspect
> ratio is okay), before calling the _mesa_convert_teximage helper
> function.  I still have to work out the nicest way to handle this, as
> _mesa_convert_teximage or equivalent has changed quite a bit.  It may be
> that the core Mesa code actually does the image conversion with the
> information returned from the driver callback.

Core Mesa never directly calls the texutil.c functions at this time.



> Basically, _mesa_convert_teximage has a couple of layers of conversion
> function tables, depending on the input and output formats etc.  This
> allows MMX-optimized conversion routines to be used in a variety of
> situations.  Things like the current pixelstore attributes, whether the
> image needs rescaling, and whether the input and output types are
> supported are used to determine if a fast conversion can be done.  If a
> fast conversion can be done, the function tables are used to select the
> correct function and we're done.  If not, _mesa_convert_teximage will
> fall back to doing a generic image conversion.

OK.


> The critical difference here is that the driver selects the internal
> format to be used (like MESA_FORMAT_ARGB4444, MESA_FORMAT_AL88 etc), and
> the conversion function is guaranteed to return a tightly-packed image
> with that type.  The conversion function is smart enough to pack RGB
> input data into RGBA textures, or alpha/luminance only data into an AL88
> texture and so on.  We do not need extra internal types to handle this.

Are you saying something new here?  This is the way things currently work.


> The software rasterizer uses the texFormat->extractTexel()-like
> functions to extract individual or blocks of texels.  The SI has a
> number of texel extraction functions per format, to support textures
> with and without borders and so on.  The correct one would be plugged
> into texImage->extract().  This means that the image can be converted
> once only, stored in a hardware-friendly format, and interacted with by
> the software rasterizer.  I think this is nicer than having to unconvert
> the entire image when there's a software fallback.

I like this too.  The trick is not penalizing the performance of software
Mesa (like the Xlib driver).  I think that the optimized textured triangle
functions (for example) could detect when the texture image is in a
simple GLubyte, GL_RGB format and directly address texels.  It would be
the unoptimized cases, like mipmapped textures, where we might be
incurring a new performance hit.  Even that could probably be avoided
with some extra code.


> Brian, I'm not sure if you're going to get this, and I know you said you
> were going to look into a texel extraction interface as well.  I wanted
> to let you know where I'm going with this to avoid duplicate work and
> let you comment on my thoughts.

I hadn't done any work on this yet.  We can do it together.

I think the first things to do are:

1. Add the ExtractTexel() function pointer to the gl_texture_image struct.

2. Remove the Driver.GetTexImage() code and write new code to use the
   ExtractTexel() function.

I'll need some clarifications on the issues above before doing more.

-Brian

[Mesa3d-dev] Test, please ignore

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

A post I made yesterday hasn't made it through yet...

-- Gareth

[Mesa3d-dev] Mesa-3.5 CVS: vtxfmt.h missing?

[Dieter <Die...@ha...>]

Hello Keith,

I've tried to compile the DRI CVS mesa-3-5-branch and got this:

ln -s /opt/Mesa/src/vtxfmt.c vtxfmt.c
rm -f vtxfmt.h
ln -s /opt/Mesa/src/vtxfmt.h vtxfmt.h
make[4]: *** No rule to make target `/opt/Mesa/src/vtxfmt_tmp.h', needed by 
`vtxfmt_tmp.h'.  Stop.
make[4]: Leaving directory `/tmp/INSTALL/SOURCE/dri/xc/xc/lib/GL/mesa/src'
make[3]: *** [includes] Error 2
make[3]: Leaving directory `/tmp/INSTALL/SOURCE/dri/xc/xc/lib/GL'
make[2]: *** [includes] Error 2
make[2]: Leaving directory `/tmp/INSTALL/SOURCE/dri/xc/xc/lib'
make[1]: *** [includes] Error 2
make[1]: Leaving directory `/tmp/INSTALL/SOURCE/dri/xc/xc'
make: *** [World] Error 2

Mesa CVS taken today.

Thanks,
	Dieter
-- 
Dieter Nützel
Graduate Student, Computer Science

University of Hamburg
Department of Computer Science
Cognitive Systems Group
Vogt-Kölln-Straße 30
D-22527 Hamburg, Germany

email: nu...@ko...
@home: Die...@ha...

[Mesa3d-dev] Proposed new DD texture interface

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

After looking into the current single-copy texture mechanism, I'd like
to propose a couple of changes.  This will involve completely removing
the old interface, as well as providing a much more driver-friendly
approach to texture image storage.  Many of these ideas are similar to
features found in the SI, at least from the top level.  The
implementation of these ideas would be quite different in our case,
however.

First, we add a struct gl_texture_format as follows:

struct gl_texture_format {
   GLint internalFormat;	/* Mesa format */

   GLint redSize;
   GLint greenSize;
   GLint blueSize;
   GLint alphaSize;
   GLint luminanceSize;
   GLint intensitySize;
   GLint indexSize;

   GLint bytesPerTexel;

   /* Functions to return individual texels.
    */
   void (*extractTexel)(...);
   ...
};

We define a set of these structures:

const struct gl_texture_format gl_tex_format_argb8888 = {
   MESA_FORMAT_ARGB8888,
   8, 8, 8, 8, 0, 0, 0,
   4,
   ...
};

const struct gl_texture_format gl_tex_format_rgb565 = {
   MESA_FORMAT_RGB565,
   5, 6, 5, 0, 0, 0, 0,
   2,
   ...
};

and so on.

We add a pointer to such a structure to struct gl_texture_image, and add
a driver callback to allow the driver to select the best format.  Thus,
_mesa_TexImage*() has something like the following:

   struct gl_texture_format *texFormat;

   texFormat = (*ctx->Driver.ChooseTextureFormat)( ... );

   texImage->texFormat = texFormat;

   texImage->RedBits = texFormat->redSize;
   texImage->GreenBits = texFormat->greenSize;
   texImage->BlueBits = texFormat->blueSize;
   texImage->AlphaBits = texFormat->alphaSize;
   texImage->IntensityBits = texFormat->intensitySize;
   texImage->LuminanceBits = texFormat->luminanceSize;
   texImage->IndexBits = texFormat->indexSize;

The Driver.TexImage* callbacks are now no longer allowed to fail. 
_mesa_TexImage* hands control over to the driver, which does any
driver-specific work (such as the tdfx driver making sure the aspect
ratio is okay), before calling the _mesa_convert_teximage helper
function.  I still have to work out the nicest way to handle this, as
_mesa_convert_teximage or equivalent has changed quite a bit.  It may be
that the core Mesa code actually does the image conversion with the
information returned from the driver callback.

Basically, _mesa_convert_teximage has a couple of layers of conversion
function tables, depending on the input and output formats etc.  This
allows MMX-optimized conversion routines to be used in a variety of
situations.  Things like the current pixelstore attributes, whether the
image needs rescaling, and whether the input and output types are
supported are used to determine if a fast conversion can be done.  If a
fast conversion can be done, the function tables are used to select the
correct function and we're done.  If not, _mesa_convert_teximage will
fall back to doing a generic image conversion.

The critical difference here is that the driver selects the internal
format to be used (like MESA_FORMAT_ARGB4444, MESA_FORMAT_AL88 etc), and
the conversion function is guaranteed to return a tightly-packed image
with that type.  The conversion function is smart enough to pack RGB
input data into RGBA textures, or alpha/luminance only data into an AL88
texture and so on.  We do not need extra internal types to handle this.

The software rasterizer uses the texFormat->extractTexel()-like
functions to extract individual or blocks of texels.  The SI has a
number of texel extraction functions per format, to support textures
with and without borders and so on.  The correct one would be plugged
into texImage->extract().  This means that the image can be converted
once only, stored in a hardware-friendly format, and interacted with by
the software rasterizer.  I think this is nicer than having to unconvert
the entire image when there's a software fallback.

Brian, I'm not sure if you're going to get this, and I know you said you
were going to look into a texel extraction interface as well.  I wanted
to let you know where I'm going with this to avoid duplicate work and
let you comment on my thoughts.

-- Gareth

Re: [Mesa3d-dev] texutil updates

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

Gareth Hughes wrote:
> 
> Brian Paul wrote:
> >
> > Don't remove the original case.
> >
> > GL_BGR / GL_UNSIGNED_SHORT_5_6_5_REV is equivalent to GL_RGB /
> > GL_UNSIGNED_SHORT_5_6_5.  In both cases, the component packing
> > in the GLushort is RRRRRGGGGGGBBBBB.
> >
> > So, the condition should be:
> >
> >  if ((srcFormat == GL_RGB && srcType == GL_UNSIGNED_SHORT_5_6_5) ||
> >      (srcFormat == GL_BGR && srcType == GL_UNSIGNED_SHORT_5_6_5_REV)) {
> 
> Hmmm...  I'm going to have to read the spec a little more closely.  Given the
> fact that it's 4:30am over here this is frying my brain ;-)

Okay, found the relevant section and I get it now...

-- Gareth

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

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

Brian Paul wrote:
> 
> CVSROOT:        /cvsroot/mesa3d
> Module name:    Mesa
> Repository:     Mesa/docs/
> Changes by:     brianp@usw-pr-cvs1.     01/01/30 10:26:18
> 
> Modified files:
>       Mesa/docs/:
>         CONFORM
> 
>   Revision      Changes    Path
>   1.9           +119 -199  Mesa/docs/CONFORM
> 
> Log message:
>   updated with latest 3.5 results: everything passes

Great stuff!  I experienced some crashes running the conformance tests with 3.5
in glDrawPixels, probably because I hadn't rebuilt enough of the code after
updating.

-- Gareth

[Mesa3d-dev] Latest glext.h file

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

The following patch addresses a couple of issues with version 7 of glext.h,
available now from oss.sgi.com.

According to the GL_ARB_texture_compression spec,

    1.0,  03/24/00 prbrown1: Applied changes approved as part of the extension
                             at the March 2000 ARB meeting, as follows:
                             ...
                             * Renamed TEXTURE_IMAGE_SIZE_ARB to
                               TEXTURE_COMPRESSED_IMAGE_SIZE_ARB.

Version 7 of glext.h seems to have undone this change.  Just bringing this to
your attention, there may very well be a reason for this change that I'm not
aware of.

To build the latest GLperf code on Linux, the GL_COLOR_TABLE_*_EXT tokens had to
be added.  These were taken from the GL_EXT_paletted_texture spec, and are
duplicates of the corresponding values from the OpenGL 1.2 imaging subset.

I recently added support for the soon-to-be-deprecated GL_EXT_texture_env_dot3
to Mesa, to expose the functionality in the Radeon DRI driver.  We will, of
course, update this to the ARB extension when it is finalized, but I've added
the required tokens so we can implement dot product bump mapping now.

(Mesa people:  I've updated Mesa's copy of glext.h to version 7 and will commit
it now, with the following patch applied).

-- Gareth


--- glext.h	Wed Jan 31 01:07:34 2001
+++ glext.h.new	Wed Jan 31 01:14:30 2001
@@ -220,7 +220,7 @@
 #define GL_COMPRESSED_RGB_ARB             0x84ED
 #define GL_COMPRESSED_RGBA_ARB            0x84EE
 #define GL_TEXTURE_COMPRESSION_HINT_ARB   0x84EF
-#define GL_TEXTURE_IMAGE_SIZE_ARB         0x86A0
+#define GL_TEXTURE_COMPRESSED_IMAGE_SIZE_ARB 0x86A0
 #define GL_TEXTURE_COMPRESSED_ARB         0x86A1
 #define GL_NUM_COMPRESSED_TEXTURE_FORMATS_ARB 0x86A2
 #define GL_COMPRESSED_TEXTURE_FORMATS_ARB 0x86A3
@@ -842,6 +842,14 @@
 #define GL_COLOR_INDEX8_EXT               0x80E5
 #define GL_COLOR_INDEX12_EXT              0x80E6
 #define GL_COLOR_INDEX16_EXT              0x80E7
+#define GL_COLOR_TABLE_FORMAT_EXT         0x80D8
+#define GL_COLOR_TABLE_WIDTH_EXT          0x80D9
+#define GL_COLOR_TABLE_RED_SIZE_EXT       0x80DA
+#define GL_COLOR_TABLE_GREEN_SIZE_EXT     0x80DB
+#define GL_COLOR_TABLE_BLUE_SIZE_EXT      0x80DC
+#define GL_COLOR_TABLE_ALPHA_SIZE_EXT     0x80DD
+#define GL_COLOR_TABLE_LUMINANCE_SIZE_EXT 0x80DE
+#define GL_COLOR_TABLE_INTENSITY_SIZE_EXT 0x80DF
 #define GL_TEXTURE_INDEX_SIZE_EXT         0x80ED
 #endif
 
@@ -1494,6 +1502,11 @@
 #define GL_TEXTURE_COLOR_WRITEMASK_SGIS   0x81EF
 #endif
 
+#ifndef GL_EXT_texture_env_dot3
+#define GL_DOT3_RGB_EXT                   0x8740
+#define GL_DOT3_RGBA_EXT                  0x8741
+#endif
+
 
 /*************************************************************/
 
@@ -3027,6 +3040,10 @@
 extern void APIENTRY glIglooInterfaceSGIX (GLenum, const GLvoid *);
 #endif /* GL_GLEXT_PROTOTYPES */
 typedef void (APIENTRY * PFNGLIGLOOINTERFACESGIXPROC) (GLenum pname, const
GLvoid *params);
+#endif
+
+#ifndef GL_EXT_texture_env_dot3
+#define GL_EXT_texture_env_dot3 1
 #endif

Re: [Mesa3d-dev] texutil updates

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

Brian Paul wrote:
> 
> Don't remove the original case.
> 
> GL_BGR / GL_UNSIGNED_SHORT_5_6_5_REV is equivalent to GL_RGB /
> GL_UNSIGNED_SHORT_5_6_5.  In both cases, the component packing
> in the GLushort is RRRRRGGGGGGBBBBB.
> 
> So, the condition should be:
> 
>  if ((srcFormat == GL_RGB && srcType == GL_UNSIGNED_SHORT_5_6_5) ||
>      (srcFormat == GL_BGR && srcType == GL_UNSIGNED_SHORT_5_6_5_REV)) {

Hmmm...  I'm going to have to read the spec a little more closely.  Given the
fact that it's 4:30am over here this is frying my brain ;-)

Either way, I agree that having both cases is useful.  I should said "add" not
"change to".

-- Gareth

Re: [Mesa3d-dev] texutil updates

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

Gareth Hughes wrote:
> 
> I'm in the process of moving the Radeon DRI driver over to Mesa's
> single-copy texture mechanism.  I'm using this opportunity to wrap up my
> changes to texutil.c and friends, which includes full MMX assembly
> optimizations for most of the interesting cases.
> 
> I've noticed that this is special-cased:
> 
>       case MESA_R5_G6_B5:
>          if (srcFormat == GL_RGB && srcType == GL_UNSIGNED_SHORT_5_6_5) {
>             ...
>          }
> 
> However, later we see this:
> 
>       case MESA_A4_R4_G4_B4:
>          /* store as 16-bit texels (GR_TEXFMT_ARGB_4444) */
>          if (srcFormat == GL_BGRA && srcType == GL_UNSIGNED_SHORT_4_4_4_4_REV){
>             ...
>          }
> 
> And this:
> 
>       case MESA_A1_R5_G5_B5:
>          /* store as 16-bit texels (GR_TEXFMT_ARGB_1555) */
>          if (srcFormat == GL_BGRA && srcType == GL_UNSIGNED_SHORT_1_5_5_5_REV){
>              ...
>          }
> 
> In all cases, the data is memcpy'd to the final destination image.  I'm
> going to change the first case to this:
> 
>       case MESA_R5_G6_B5:
>          if (srcFormat == GL_BGR && srcType == GL_UNSIGNED_SHORT_5_6_5_REV) {
>             ...
>          }

Don't remove the original case.

GL_BGR / GL_UNSIGNED_SHORT_5_6_5_REV is equivalent to GL_RGB /
GL_UNSIGNED_SHORT_5_6_5.  In both cases, the component packing
in the GLushort is RRRRRGGGGGGBBBBB.

So, the condition should be:

 if ((srcFormat == GL_RGB && srcType == GL_UNSIGNED_SHORT_5_6_5) ||
     (srcFormat == GL_BGR && srcType == GL_UNSIGNED_SHORT_5_6_5_REV)) {



> to fit with the rest of the cases and to make it actually useful to Mesa
> drivers that use little-endian texture images.  If you don't want this
> to happen, scream now...

-Brian

[Mesa3d-dev] texutil updates

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

I'm in the process of moving the Radeon DRI driver over to Mesa's
single-copy texture mechanism.  I'm using this opportunity to wrap up my
changes to texutil.c and friends, which includes full MMX assembly
optimizations for most of the interesting cases.

I've noticed that this is special-cased:

      case MESA_R5_G6_B5:
         if (srcFormat == GL_RGB && srcType == GL_UNSIGNED_SHORT_5_6_5) {
            ...
         }

However, later we see this:

      case MESA_A4_R4_G4_B4:
         /* store as 16-bit texels (GR_TEXFMT_ARGB_4444) */
         if (srcFormat == GL_BGRA && srcType == GL_UNSIGNED_SHORT_4_4_4_4_REV){
            ...
         }

And this:

      case MESA_A1_R5_G5_B5:
         /* store as 16-bit texels (GR_TEXFMT_ARGB_1555) */
         if (srcFormat == GL_BGRA && srcType == GL_UNSIGNED_SHORT_1_5_5_5_REV){
             ...
         }

In all cases, the data is memcpy'd to the final destination image.  I'm
going to change the first case to this:

      case MESA_R5_G6_B5:
         if (srcFormat == GL_BGR && srcType == GL_UNSIGNED_SHORT_5_6_5_REV) {
            ...
         }

to fit with the rest of the cases and to make it actually useful to Mesa
drivers that use little-endian texture images.  If you don't want this
to happen, scream now...

-- Gareth

Re: [Mesa3d-dev] GGIMesa + libtool problem

[Jon T. <jt...@lu...>]

Lee Brown wrote:

> On Wed, 17 Jan 2001, Jon Taylor wrote:
> 
>> Normal X11-target builds appear to work fine, but when I enable GGI 
>> support it builds OK but dies during the final link step with:
> 
> 
> Jon,
> 
> Did you ever find the problem here?

	Nope.  It remains a problem, and I haven't got the time to track it all 
the way down right now.

Jon

Re: [Mesa3d-dev] GGIMesa + libtool problem

[Lee B. <le...@i-...>]

On Wed, 17 Jan 2001, Jon Taylor wrote:
> Normal X11-target builds appear to work fine, but when I enable GGI 
> support it builds OK but dies during the final link step with:

Jon,

Did you ever find the problem here?

Just curious.

lee




> 
> libtool: link: cannot find the library `'
> 
>    I've looked everywhere I can think of, but I can't seem to find where 
> this is coming from.  Sven?  Any ideas?
> 
> Jon
> 
> 
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> http://lists.sourceforge.net/lists/listinfo/mesa3d-dev
-- 
Lee Brown Jr.
le...@i-...

RE: [Mesa3d-dev] GGIMesa + libtool problem

[Lee B. <le...@i-...>]

I just though of one more thing.  Here's the bootstrap program I use.

-- 
Lee Brown Jr.
le...@i-...

RE: [Mesa3d-dev] GGIMesa + libtool problem

[Lee B. <le...@i-...>]

> 	Please do.  What's your GGI installation look like?  Did you do anything 

I believe my GGI installation is standard.  

> unusual there?  I think that might be the problem.  libtool tends to 
> barf when told to link a libtool-using package (like Mesa) with 
> alread-installed libtool convenience libraries (.la files, like LibGGI).

One thing I noticed is that in the m4 directory there is a file called
"libtool.m4".  You may try getting rid of that guy.  I did. 

Another thing.  Do you have a Makefile.am in src/array_cache?  I didn't. This
was giving linking errors when compiling the demos, so I made one. This
shouldn't affect the main build though.

The only other thing I did was to make small changes for the conditionals. I
don't think this is the source of the problem.

Attached are my configure.in, src/Makefile.am, src/GGI/Makefile.am files.
There is nothing special about any of them, but I include them in case you
want to compare.   

I hope this helps.  Let me know if yours still doesn't compile.  I am sure we
can get to the bottom of this.  

Lee






> Jon
> 
> 
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> http://lists.sourceforge.net/lists/listinfo/mesa3d-dev
-- 
Lee Brown Jr.
le...@i-...

Re: [Mesa3d-dev] GGIMesa + libtool problem

[Marcelo E. M. <mar...@bi...>]

>> Jon Taylor <jt...@lu...> writes:

 > unusual there?  I think that might be the problem.  libtool tends to 
 > barf when told to link a libtool-using package (like Mesa) with 
 > alread-installed libtool convenience libraries (.la files, like LibGGI).

 I'm sorry I wasn't clear in the last mail.  The .la file *is* the
 problem (or at least it was last time I looked at this).  libtool is
 not reading .la files recursively.  Try getting it out of the way to
 see what happens.

--
Marcelo

RE: [Mesa3d-dev] GGIMesa + libtool problem

[Jon T. <jt...@lu...>]

> On Wed, 17 Jan 2001, Jon Taylor wrote:
>> Normal X11-target builds appear to work fine, but when I enable GGI 
>> support it builds OK but dies during the final link step with:
>> > libtool: link: cannot find the library `'
>> > I've looked everywhere I can think of, but I can't seem to find where 
>> this is coming from.  Sven?  Any ideas?
>> > Jon
 >

> Are you talking about 
> 
> ./configure --with-ggi=/usr/local
> make
> 
> Then you get an error at the linking?

	I always get that error no matter what I do.

 
> I sent an email to Brian Paul stating that  I managed to get the cvs to build
> with  
> 
> libtool 1.3.5
> automake 1.4
> autoconf 2.13

	I've been using the CVS versions of all of those tools, so I figured I'd 
try falling back to the versions you used.  No luck, it gives me the 
exact same error.

 
> When I compile with 
> 
> ./configure --with-ggi=/usr/local
> make
> 
> Mine compiles and links fine. I would be happy to share what I know with you.

	Please do.  What's your GGI installation look like?  Did you do anything 
unusual there?  I think that might be the problem.  libtool tends to 
barf when told to link a libtool-using package (like Mesa) with 
alread-installed libtool convenience libraries (.la files, like LibGGI).

Jon

Re: [Mesa3d-dev] GGIMesa + libtool problem

[Lee B. <le...@i-...>]

On Wed, 17 Jan 2001, Jon Taylor wrote:
> Normal X11-target builds appear to work fine, but when I enable GGI 
> support it builds OK but dies during the final link step with:
> 
> libtool: link: cannot find the library `'
> 
>    I've looked everywhere I can think of, but I can't seem to find where 
> this is coming from.  Sven?  Any ideas?
> 
> Jon
> 

Are you talking about 

./configure --with-ggi=/usr/local
make

Then you get an error at the linking?


I sent an email to Brian Paul stating that  I managed to get the cvs to build
with  

libtool 1.3.5
automake 1.4
autoconf 2.13

When I compile with 

./configure --with-ggi=/usr/local
make

Mine compiles and links fine. I would be happy to share what I know with you.

Lee




> 
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> http://lists.sourceforge.net/lists/listinfo/mesa3d-dev
-- 
Lee Brown Jr.
le...@i-...

Re: [Mesa3d-dev] GGIMesa + libtool problem

[Marcelo E. M. <mar...@bi...>]

>> Jon Taylor <jt...@lu...> writes:

 >    I've looked everywhere I can think of, but I can't seem to find where 
 > this is coming from.  Sven?  Any ideas?

 Do you have a libggi.la file somewhere in the path there libraries are
 being looked for?

--
Marcelo

[Mesa3d-dev] GGIMesa + libtool problem

[Jon T. <jt...@lu...>]

     Normal X11-target builds appear to work fine, but when I enable GGI 
support it builds OK but dies during the final link step with:

libtool: link: cannot find the library `'

   I've looked everywhere I can think of, but I can't seem to find where 
this is coming from.  Sven?  Any ideas?

Jon

Re: [Mesa3d-dev] bug in sphere normal

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

Stephen Tse wrote:
> 
> Brian Paul <br...@va...> writes:
> 
> > Well, when I first wrote gluSphere() I didn't have the SI code to
> > compare to.  And, I don't recall comparing SGI's gluSphere to Mesa's
> > gluSphere at that level of attention.
> 
> What's SI code? standard code?

Sample Implementation.  http://oss.sgi.com/projects/ogl-sample/


> > If you rotate/transform the sphere in the right way, you may find
> > that Mesa's gluSphere looks "more accurate".
> 
> Okay =).
> 
> > > BTW, does the conformance test (which covers GL part for sure) cover
> > > GLU and GLUT parts as well?
> >
> > GLU, but not in too much detail.  GLUT has its own set of self-test
> > programs.
> 
> The conformance test is available only to the OpenGL licensee, right?
> How can Mesa get access to it? Via your company, valinux?

I've got the conformance tests.


> Do you know if there is an open-source equivalent for the test suits?
> glean is one of them, but it's not actively maintained anymore, I'm
> afriad.

Where'd you get that idea?  Glean's been pretty active in the past
few months.

-Brian

Re: [Mesa3d-dev] bug in sphere normal

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

Brian Paul wrote:
> 
> > > But Mesa's GLU tessellator and NURBS code isn't nearly as good as the
> > > SI code.
> >
> > Can you be more specific? As a matter of fact, I am studying closely
> > the codes of mesa's glu for personal interests. SGI's codes are not
> > meant for easy human reading.
> 
> Mesa's polygon tessellator doesn't have the GLU 1.2 features.
> Gareth Hughes worked on this for a while but didn't have time to
> complete the work.  I'm sure he'd agree that it's a big job.
> Also Mesa's GLU NURBS tessellator doesn't handle trimming or a
> few other features.

*shudder*

Oh yes, it's a large problem.  Thankfully, I actually understand it now
and could do a much better job of updating Mesa's GLU than the previous
attempt.

However, with the SI code publicly available, there isn't as much of a
need for this to be done.  I've got a lot of other things to work on, so
this would be near the bottom of my TODO list (if it were on there at
all).

-- Gareth

Re: [Mesa3d-dev] bug in sphere normal

[Allen A. <ak...@po...>]

On Tue, Jan 16, 2001 at 06:35:38PM -0800, Stephen Tse wrote:
| Do you know if there is an open-source equivalent for the test suits?
| glean is one of them, but it's not actively maintained anymore, I'm
| afriad. 

Glean is still under active development, but not very many people
have contributed tests.  Would you like to? :-)

(BTW, you're correct that there hasn't been an official "release" of
glean in a long time.  However, that's partly because it's relatively
convenient to get a copy of the current code by checking it out from
the CVS tree.)

Allen

Re: [Mesa3d-dev] bug in sphere normal

[Stephen T. <ste...@sf...>]

Brian Paul <br...@va...> writes:

> Well, when I first wrote gluSphere() I didn't have the SI code to
> compare to.  And, I don't recall comparing SGI's gluSphere to Mesa's
> gluSphere at that level of attention.

What's SI code? standard code?

> 
> If you rotate/transform the sphere in the right way, you may find
> that Mesa's gluSphere looks "more accurate".

Okay =).


> > BTW, does the conformance test (which covers GL part for sure) cover
> > GLU and GLUT parts as well?
> 
> GLU, but not in too much detail.  GLUT has its own set of self-test
> programs.

The conformance test is available only to the OpenGL licensee, right?
How can Mesa get access to it? Via your company, valinux?

Do you know if there is an open-source equivalent for the test suits?
glean is one of them, but it's not actively maintained anymore, I'm
afriad. 


- Stephen

Re: [Mesa3d-dev] bug in sphere normal

[Dieter <Die...@ha...>]

> > Second, "xlockmore" (mode "text3d") crash all the time with the current
> > Mesa
> > GLU. (The self intersections?)
>
[snip]
>
> > Yes, I "see" that it fails in glide3 (without 3DNow!) but it worked last
> > summer...
> >
> > Gareth's code could handle this all.
>
>
> But other people had more trouble with Gareth's code than either the
> old Mesa tessellator or the SI tessellator.
>
> Ideally, someone will fix whatever bugs there may be in the SI
> tessellator.
>
> -Brian

I agree.

Now, a little more debug output of "xlockmore" (latest 5.01ALPHA03):

SunWave1>gdb xlock/xlock core
GNU gdb 19991004
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `./xlock/xlock -nolock -mode text3d -ttf 
/usr/X11/lib/fonts/ttf/'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/X11R6/lib/libSM.so.6...done.
Reading symbols from /usr/X11R6/lib/libICE.so.6...done.
Reading symbols from /usr/X11R6/lib/libXpm.so.4...done.
Reading symbols from /usr/lib/libgltt.so.2...done.
Reading symbols from /usr/lib/libttf.so.2...done.
Reading symbols from /usr/lib/libGL.so.1...done.
Reading symbols from /usr/lib/libGLU.so.1...done.
Reading symbols from /lib/libcrypt.so.1...done.
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Reading symbols from /usr/X11R6/lib/libXext.so.6...done.
Reading symbols from /usr/lib/libstdc++-libc6.2-2.so.3...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /usr/lib/libstdc++-libc6.1-2.so.3...done.
Reading symbols from /lib/libpthread.so.0...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /lib/libnss_compat.so.2...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /usr/X11R6/lib/modules/dri/tdfx_dri.so...done.
Reading symbols from /usr/lib/libglide3.so.3...done.
#0  t3d_anim_default (tp=0x820cfd8) at text3d.cc:475
475         tp->phi   += tp->direction * angle_speed;
(gdb) bt
#0  t3d_anim_default (tp=0x820cfd8) at text3d.cc:475
#1  0x8106166 in Animate (tp=0x820cfd8) at text3d.cc:685
#2  0x8054865 in call_callback_hook (ls=0x0, mi=0x820cfd8) at mode.c:1185
#3  0x804ed37 in runMainLoop (maxtime=0, iconscreen=-1) at xlock.c:1823
#4  0x805024b in justDisplay (display=0x820c950) at xlock.c:2513
#5  0x8051ee4 in main (argc=6, argv=0xbffff4ac) at xlock.c:3597
Current language:  auto; currently c++
(gdb) l
470
471     /*-------------------------------------------------------------*/
472     static void
473      t3d_anim_default(text3dstruct * tp)
474     {
475         tp->phi   += tp->direction * angle_speed;
476         tp->theta += tp->direction * angle_speed;
477     }
478
479     /*-------------------------------------------------------------*/
(gdb) disas
Dump of assembler code for function t3d_anim_default:
0x8105cd0 <t3d_anim_default>:   push   %ebp
0x8105cd1 <t3d_anim_default+1>: fldl   0x818e560
0x8105cd7 <t3d_anim_default+7>: mov    %esp,%ebp
0x8105cd9 <t3d_anim_default+9>: sub    $0x14,%esp
0x8105cdc <t3d_anim_default+12>:        mov    0x8(%ebp),%eax
0x8105cdf <t3d_anim_default+15>:        leave
0x8105ce0 <t3d_anim_default+16>:        fildl  0x18(%eax)
0x8105ce3 <t3d_anim_default+19>:        flds   0x40(%eax)
0x8105ce6 <t3d_anim_default+22>:        fxch   %st(1)
0x8105ce8 <t3d_anim_default+24>:        fmul   %st(2),%st
0x8105cea <t3d_anim_default+26>:        faddp  %st,%st(1)
0x8105cec <t3d_anim_default+28>:        fildl  0x18(%eax)
0x8105cef <t3d_anim_default+31>:        fxch   %st(1)
0x8105cf1 <t3d_anim_default+33>:        fstps  0x40(%eax)
0x8105cf4 <t3d_anim_default+36>:        flds   0x44(%eax)
0x8105cf7 <t3d_anim_default+39>:        fxch   %st(1)
0x8105cf9 <t3d_anim_default+41>:        fmulp  %st,%st(2)
0x8105cfb <t3d_anim_default+43>:        faddp  %st,%st(1)
0x8105cfd <t3d_anim_default+45>:        fstps  0x44(%eax)
0x8105d00 <t3d_anim_default+48>:        ret
End of assembler dump.

Reading symbols from /lib/libnss_compat.so.2...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /usr/X11R6/lib/modules/dri/tdfx_dri.so...done.
Reading symbols from /usr/lib/libglide3.so.3...done.
#0  t3d_anim_default (tp=0x820cfd8) at text3d.cc:475
475         tp->phi   += tp->direction * angle_speed;
(gdb) bt
#0  t3d_anim_default (tp=0x820cfd8) at text3d.cc:475
#1  0x8106166 in Animate (tp=0x820cfd8) at text3d.cc:685
#2  0x8054865 in call_callback_hook (ls=0x0, mi=0x820cfd8) at mode.c:1185
#3  0x804ed37 in runMainLoop (maxtime=0, iconscreen=-1) at xlock.c:1823
#4  0x805024b in justDisplay (display=0x820c950) at xlock.c:2513
#5  0x8051ee4 in main (argc=6, argv=0xbffff4ac) at xlock.c:3597
Current language:  auto; currently c++
(gdb) l
470
471     /*-------------------------------------------------------------*/
472     static void
473      t3d_anim_default(text3dstruct * tp)
474     {
475         tp->phi   += tp->direction * angle_speed;
476         tp->theta += tp->direction * angle_speed;
477     }
478
479     /*-------------------------------------------------------------*/
(gdb) disas
Dump of assembler code for function t3d_anim_default:
0x8105cd0 <t3d_anim_default>:   push   %ebp
0x8105cd1 <t3d_anim_default+1>: fldl   0x818e560
0x8105cd7 <t3d_anim_default+7>: mov    %esp,%ebp
0x8105cd9 <t3d_anim_default+9>: sub    $0x14,%esp
0x8105cdc <t3d_anim_default+12>:        mov    0x8(%ebp),%eax
0x8105cdf <t3d_anim_default+15>:        leave
0x8105ce0 <t3d_anim_default+16>:        fildl  0x18(%eax)
0x8105ce3 <t3d_anim_default+19>:        flds   0x40(%eax)
0x8105ce6 <t3d_anim_default+22>:        fxch   %st(1)
0x8105ce8 <t3d_anim_default+24>:        fmul   %st(2),%st
0x8105cea <t3d_anim_default+26>:        faddp  %st,%st(1)
0x8105cec <t3d_anim_default+28>:        fildl  0x18(%eax)
0x8105cef <t3d_anim_default+31>:        fxch   %st(1)
0x8105cf1 <t3d_anim_default+33>:        fstps  0x40(%eax)
0x8105cf4 <t3d_anim_default+36>:        flds   0x44(%eax)
0x8105cf7 <t3d_anim_default+39>:        fxch   %st(1)
0x8105cf9 <t3d_anim_default+41>:        fmulp  %st,%st(2)
0x8105cfb <t3d_anim_default+43>:        faddp  %st,%st(1)
0x8105cfd <t3d_anim_default+45>:        fstps  0x44(%eax)
0x8105d00 <t3d_anim_default+48>:        ret
End of assembler dump.

Conclusion: This seems not to be a GLU bug.

-Dieter

Re: [Mesa3d-dev] bug in sphere normal

[Allen A. <ak...@po...>]

On Tue, Jan 16, 2001 at 03:54:43PM -0700, Brian Paul wrote:
| 
| But other people had more trouble with Gareth's code than either the
| old Mesa tessellator or the SI tessellator.

It's a difficult problem.  Some algorithms handle particular cases
better than others.

| Ideally, someone will fix whatever bugs there may be in the SI
| tessellator.

It would also be great if people could submit test cases to the glean
project.  The best thing to do is to become a developer and just check
in an appropriate test; the next best thing to do is submit the test
data to the gle...@li... mailing list.  In either
case, submitting a test guarantees that future changes to the
tessellator code won't cause regressions.

Allen