mesa3d-dev

Re: [Mesa3d-dev] CVS and SSE

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

"Sven M. Hallberg" wrote:
> 
> On Fri, Apr 27, 2001 at 09:59:03AM -0600, Brian Paul wrote:
> > Allen Barnett wrote:
> > >
> > > Hi,
> > >
> > > Yesterday (4/27), I pulled the current CVS version of Mesa. I was hoping
> > > to be able to activate the Intel SSE commands, however the configuration
> > > script tries a test assenble on the file src/X86/katmai_xform_raw3.S,
> > > which does not exist. It looks like the configure script is somewhat out
> > > of sync with the current contents of src/X86/. Is there a simple change
> > > I can make to configure or should I just pull an earlier (3.4.1?)
> > > version of the CVS tree? (The corresponding files do appear in the
> > > XFree86 DRI Mesa source.)
> >
> > I was trying to fix this a few days ago but got stuck.  Your clue
> > about the test assemble of src/X86/katmai_xform_raw3.S helped me find
> > the problem now.  I'm about to check in some updates that should fix
> > this.
> >
> > One problem is still outstanding.  The src/X86/gen_matypes.c file must
> > be compiled and executed in order to generate src/X86/matypes.h before
> > the assembly code can be compiled.  You can do this manually:
> >
> >       cd src/X86
> >       gcc gen_matypes.c -I.. -I../../include -o gen_matypes
> >       ./gen_matypes > matypes.h
> >
> > I don't know how to make configure do this.  When I make the MesaLib-3.5
> > tarballs I'll include matypes.h so it won't be a problem for typical end
> > users.  We developers and CVS users just have to remember to regenerate
> > matypes.h whenever src/mtypes.h changes.
> >
> > I'll check in my updates ASAP.
> >
> > -Brian
> 
> I will have a look at the new matypes.h stuff (hopefully) soon. Brian, can you
> give a (really) brief overview (pseudo-script or whatever) describing how the
> steps needed to generate matypes.h?

I did above.  But really, I'm not sure this is too important.  When
3.5 is released it'll include the matypes.h file.  It's just when
people download from CVS that they have to make/update the matypes.h
file.


> PS: Yes, I am alive. I've just finished my service in the Army and are now
> running on spare time for a couple of months. Right now I'm wading through the
> last 150 CVS commit messages I've missed. :) Just to let everyone know...

OK.

-Brian

Re: [Mesa3d-dev] CVS and SSE

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

On Fri, Apr 27, 2001 at 09:59:03AM -0600, Brian Paul wrote:
> Allen Barnett wrote:
> > 
> > Hi,
> > 
> > Yesterday (4/27), I pulled the current CVS version of Mesa. I was hoping
> > to be able to activate the Intel SSE commands, however the configuration
> > script tries a test assenble on the file src/X86/katmai_xform_raw3.S,
> > which does not exist. It looks like the configure script is somewhat out
> > of sync with the current contents of src/X86/. Is there a simple change
> > I can make to configure or should I just pull an earlier (3.4.1?)
> > version of the CVS tree? (The corresponding files do appear in the
> > XFree86 DRI Mesa source.)
> 
> I was trying to fix this a few days ago but got stuck.  Your clue
> about the test assemble of src/X86/katmai_xform_raw3.S helped me find
> the problem now.  I'm about to check in some updates that should fix
> this.
> 
> One problem is still outstanding.  The src/X86/gen_matypes.c file must
> be compiled and executed in order to generate src/X86/matypes.h before
> the assembly code can be compiled.  You can do this manually:
> 
> 	cd src/X86
> 	gcc gen_matypes.c -I.. -I../../include -o gen_matypes
> 	./gen_matypes > matypes.h
> 
> I don't know how to make configure do this.  When I make the MesaLib-3.5
> tarballs I'll include matypes.h so it won't be a problem for typical end
> users.  We developers and CVS users just have to remember to regenerate
> matypes.h whenever src/mtypes.h changes.
> 
> I'll check in my updates ASAP.
> 
> -Brian

I will have a look at the new matypes.h stuff (hopefully) soon. Brian, can you
give a (really) brief overview (pseudo-script or whatever) describing how the
steps needed to generate matypes.h?


-Sven

PS: Yes, I am alive. I've just finished my service in the Army and are now
running on spare time for a couple of months. Right now I'm wading through the
last 150 CVS commit messages I've missed. :) Just to let everyone know...

-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]

Re: [Mesa3d-dev] CVS and SSE

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

Allen Barnett wrote:
> 
> Hi,
> 
> Yesterday (4/27), I pulled the current CVS version of Mesa. I was hoping
> to be able to activate the Intel SSE commands, however the configuration
> script tries a test assenble on the file src/X86/katmai_xform_raw3.S,
> which does not exist. It looks like the configure script is somewhat out
> of sync with the current contents of src/X86/. Is there a simple change
> I can make to configure or should I just pull an earlier (3.4.1?)
> version of the CVS tree? (The corresponding files do appear in the
> XFree86 DRI Mesa source.)

I was trying to fix this a few days ago but got stuck.  Your clue
about the test assemble of src/X86/katmai_xform_raw3.S helped me find
the problem now.  I'm about to check in some updates that should fix
this.

One problem is still outstanding.  The src/X86/gen_matypes.c file must
be compiled and executed in order to generate src/X86/matypes.h before
the assembly code can be compiled.  You can do this manually:

	cd src/X86
	gcc gen_matypes.c -I.. -I../../include -o gen_matypes
	./gen_matypes > matypes.h

I don't know how to make configure do this.  When I make the MesaLib-3.5
tarballs I'll include matypes.h so it won't be a problem for typical end
users.  We developers and CVS users just have to remember to regenerate
matypes.h whenever src/mtypes.h changes.

I'll check in my updates ASAP.

-Brian

[Mesa3d-dev] CVS and SSE

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

Hi,

Yesterday (4/27), I pulled the current CVS version of Mesa. I was hoping
to be able to activate the Intel SSE commands, however the configuration
script tries a test assenble on the file src/X86/katmai_xform_raw3.S,
which does not exist. It looks like the configure script is somewhat out
of sync with the current contents of src/X86/. Is there a simple change
I can make to configure or should I just pull an earlier (3.4.1?)
version of the CVS tree? (The corresponding files do appear in the
XFree86 DRI Mesa source.)

Thanks,
Allen

Re: [Mesa3d-dev] swrast fog broken

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

Brian Paul wrote:
> 
> Keith Whitwell wrote:
> >
> > Has anyone else seen this?  (samples/fog, isosurf fog mode)
> >
> > I'm trying to get a dri driver built so I can determine if it's swrast or tnl
> > that's broken.
> 
> Looks broken here too.  I don't know when that might have happened.

Oh, samples/fog and isosurf look OK with the R128 3.5 DRI driver so
it's probably a swrast problem.

-Brian

Re: [Mesa3d-dev] swrast fog broken

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

Keith Whitwell wrote:
> 
> Has anyone else seen this?  (samples/fog, isosurf fog mode)
> 
> I'm trying to get a dri driver built so I can determine if it's swrast or tnl
> that's broken.

Looks broken here too.  I don't know when that might have happened.

-Brian

[Mesa3d-dev] swrast fog broken

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

Has anyone else seen this?  (samples/fog, isosurf fog mode) 

I'm trying to get a dri driver built so I can determine if it's swrast or tnl
that's broken.

Keith

[Mesa3d-dev] Windows, DOS, DJGPP, etc support

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

The Mesa source code and device driver interface has changed a lot between
Mesa 3.4 and 3.5.  This has mostly been driven by the needs of the DRI
hardware drivers.  The source code is much more modular and flexible now.
We've kept the XMesa, OSMesa and FXMesa drivers up to date with these changes,
but none of the other drivers.

So as it looks now, we'll have to drop support for the Windows, DOS, DJGPP,
GGI, etc drivers in Mesa 3.5 since nobody's been maintaining them.  I intend
to update the BeOS driver when I get some time.

I know people are still interested in using Mesa on Windows and DOS but
people don't seem inclined to help maintain these drivers.  So I'm asking
for volunteers for this work.  Any takers?

If you volunteer you should setup an account for yourself on SourceForge.
I'll then give you CVS-write permission so that you can modify the driver
sources and project/makefiles as needed.

I'm not going to hold up the 3.5 release waiting for volunteers.  If someone
does offer to do the work I'll work with them to get it done on time for 3.5.

Thanks.

-Brian

Re: [Mesa3d-dev] CULL_MASK_ACTIVE

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

Keith Whitwell wrote:
> 
> Gareth Hughes wrote:
> >
> > Shall I get rid of all the _masked functions (ie. C versions as well)?
> 
> I don't see any need to keep them.

Great, just wanted to be sure...

-- Gareth

Re: [Mesa3d-dev] CULL_MASK_ACTIVE

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

Gareth Hughes wrote:
> 
> Keith Whitwell wrote:
> >
> > Gareth Hughes wrote:
> > >
> > > Kieth, this is gone for good, never to return, correct?  I can delete
> > > X86/*_masked*.S?
> >
> > Fire away.
> 
> Shall I get rid of all the _masked functions (ie. C versions as well)?

I don't see any need to keep them.

Keith

Re: [Mesa3d-dev] CULL_MASK_ACTIVE

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

Keith Whitwell wrote:
> 
> Gareth Hughes wrote:
> >
> > Kieth, this is gone for good, never to return, correct?  I can delete
> > X86/*_masked*.S?
> 
> Fire away.

Shall I get rid of all the _masked functions (ie. C versions as well)?

-- Gareth

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

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

Brian Paul wrote:
> 
> Gareth Hughes wrote:
> >
> > CVSROOT:        /cvsroot/mesa3d
> > Module name:    Mesa
> > Repository:     Mesa/src/X86/
> > Changes by:     gareth@usw-pr-cvs1.     01/03/28 12:44:44
> >
> > Log message:
> >   New type system for assembly code.  Asm files should now include
> >   matypes.h, which includes assyntax.h and is generated from the core Mesa
> >   header files.
> 
> What do you think of including the generated "X86/matypes.h" file
> in CVS?
> 
> That'll save people the task of compiling it themselves.  I do
> this with the sources generated by the python scripts in Mesa/bin/.
> 
> Otherwise, we should add Makefile rules to compile and run gen_matypes.

We have them.  It's only built if you choose one of the -x86 configs
(and I'm filling in the missing ones in Make-config now).  I'd prefer to
have this built on the fly, as it's more likely to change regularly than
the other generated source files.

-- Gareth

Re: [Mesa3d-dev] CULL_MASK_ACTIVE

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

Gareth Hughes wrote:
> 
> Kieth, this is gone for good, never to return, correct?  I can delete
> X86/*_masked*.S?

Fire away.

Keith

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

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

Gareth Hughes wrote:
> 
> CVSROOT:        /cvsroot/mesa3d
> Module name:    Mesa
> Repository:     Mesa/src/X86/
> Changes by:     gareth@usw-pr-cvs1.     01/03/28 12:44:44
> 
> Log message:
>   New type system for assembly code.  Asm files should now include
>   matypes.h, which includes assyntax.h and is generated from the core Mesa
>   header files.

What do you think of including the generated "X86/matypes.h" file
in CVS?

That'll save people the task of compiling it themselves.  I do
this with the sources generated by the python scripts in Mesa/bin/.

Otherwise, we should add Makefile rules to compile and run gen_matypes.

-Brian

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

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

Gareth Hughes wrote:
> 
> CVSROOT:        /cvsroot/mesa3d
> Module name:    Mesa
> Repository:     Mesa/src/swrast/
> Changes by:     gareth@usw-pr-cvs1.     01/03/28 12:40:52
> 
> Log message:
>   More texture format updates.  Drivers now need only plug an appropriate
>   format into texImage->TexFormat, the rest is handled by core Mesa.


There's a problem.

The internalFormat parameter from glTexImage*D() is no longer being
stored as-is.  Instead, it's now a constant in each of the predefined
gl_texture_format structs.

When someone calls glGetTexLevelParameter(target, level,
GL_TEXTURE_INTERNAL_FORMAT, &value), value should return the
orginally requested internalFormat, not the best match, as
we're now doing.

The spec isn't 100% clear on this but that's what the SI does
and what Mesa used to do.

I can restore this if you're too busy.

If the user really wants to know how their texture was actually
stored, the only info they can get is via the GL_TEXTURE_RED/
GREEN/BLUE/ALPHA/LUMINANCE_SIZE, etc queries.

-Brian

[Mesa3d-dev] CULL_MASK_ACTIVE

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

Kieth, this is gone for good, never to return, correct?  I can delete
X86/*_masked*.S?

-- Gareth

Re: [Mesa3d-dev] Texture formats

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

Brian Paul wrote:
> 
> Right.  Though it's the format that would be GL_COLOR_INDEX and the
> internalFormat would be GL_COLOR_INDEX_*.

Indeed :-)

> That sounds right.  I'd have to review the code to say for certain.

Cool.

> I think a few more utility routines may be in order.  Because in all
> the drivers' TexImage*() functions we always have to do something
> like this (lots of details omitted):
> 
> if (anyPixelTransferOps) {
>     allocate tempBuffer
>     _mesa_transfer_teximage(dest = tempBuffer, source = userData)
>     _mesa_convert_texsubimage2d(dest = texImage->Data, src = tempBuffer);
>     free tempBuffer
> }
> else {
>    _mesa_convert_texsubimage2d(dest = texImage->Data, src = tempBuffer);
> 
> }
> 
> In the 3dfx driver it's more complicated because of the image
> rescaling that's sometimes needed.

Hence my earlier argument that _mesa convert_texsubimage2d() shouldn't
be allowed to fail :-)

-- Gareth

Re: [Mesa3d-dev] Texture formats

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

Gareth Hughes wrote:
> 
> Brian Paul wrote:
> >
> > In the s/w rasterizer I've been replacing the texture Format and Type
> > checks with comparisons against the new MESA_FORMAT_* tokens.
> >
> > And in the texture-object-completeness function, I'm going to check
> > if all mipmaps are of the same format by comparing the TexFormat field
> > instead of the Format/Type fields.
> >
> > So, the Type field really might not be needed anymore.  However, it
> > wouldn't be bad to keep it around a bit longer, I think.
> 
> Sounds good.
> 
> I have a quick question regarding color lookup tables.  If a driver
> doesn't support paletted textures, the only failure case is when the
> data format is a GL_COLOR_INDEX(_*) type and the internalFormat is
> GL_COLOR_INDEX, right?  If the internalFormat is anything else, it goes
> through the color lookup table, which defaults to 0 for all channels,
> right?

Right.  Though it's the format that would be GL_COLOR_INDEX and the
internalFormat would be GL_COLOR_INDEX_*.


> So, if I've got this right, the driver would have to inspect
> internalFormat if the data format was GL_COLOR_INDEX(_*) and choose an
> appropriate final destination format, skip the first conversion pass,
> call the texstore functions to perform the LUT conversion, and then call
> _mesa_convert_texsubimage*() to convert the GLchan-based post-LUT image
> to the final image format.  Does this sound correct?

That sounds right.  I'd have to review the code to say for certain.

I think a few more utility routines may be in order.  Because in all
the drivers' TexImage*() functions we always have to do something
like this (lots of details omitted):

if (anyPixelTransferOps) {
    allocate tempBuffer
    _mesa_transfer_teximage(dest = tempBuffer, source = userData)
    _mesa_convert_texsubimage2d(dest = texImage->Data, src = tempBuffer);
    free tempBuffer
}
else {
   _mesa_convert_texsubimage2d(dest = texImage->Data, src = tempBuffer);

}


In the 3dfx driver it's more complicated because of the image
rescaling that's sometimes needed.

-Brian

Re: [Mesa3d-dev] Texture formats

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

Brian Paul wrote:
> 
> In the s/w rasterizer I've been replacing the texture Format and Type
> checks with comparisons against the new MESA_FORMAT_* tokens.
> 
> And in the texture-object-completeness function, I'm going to check
> if all mipmaps are of the same format by comparing the TexFormat field
> instead of the Format/Type fields.
> 
> So, the Type field really might not be needed anymore.  However, it
> wouldn't be bad to keep it around a bit longer, I think.

Sounds good.

I have a quick question regarding color lookup tables.  If a driver
doesn't support paletted textures, the only failure case is when the
data format is a GL_COLOR_INDEX(_*) type and the internalFormat is
GL_COLOR_INDEX, right?  If the internalFormat is anything else, it goes
through the color lookup table, which defaults to 0 for all channels,
right?

So, if I've got this right, the driver would have to inspect
internalFormat if the data format was GL_COLOR_INDEX(_*) and choose an
appropriate final destination format, skip the first conversion pass,
call the texstore functions to perform the LUT conversion, and then call
_mesa_convert_texsubimage*() to convert the GLchan-based post-LUT image
to the final image format.  Does this sound correct?

-- Gareth

Re: [Mesa3d-dev] Texture formats

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

Gareth Hughes wrote:
> 
> I'm restoring the behaviour of texImage->Format, and will set
> texImage->IntFormat to the GL format corresponding to the internal Mesa
> format instead of the internalFormat parameter given by the user.  This
> gives the behaviour I'm looking for (ie. users can find out what format
> the texture is stored in, and by checking the individual component sizes
> can acurately determine how the image is stored).
> 
> As far as I can tell, the texImage->Type field is redundant.  We have
> the number of bytes per texel stored in texImage->TexFormat->TexelBytes,
> and can thus remove the use of texImage->Type in texstore.c.  We'll need
> to keep the information around so the software rasterizer can determine
> if it can use an optimize CHAN_TYPE texture sampling function.  Thus,
> I'll remove the BaseFormat field from gl_texture_format, but keep and
> rename the BaseType field.  The software rasterizer will then check the
> gl_texture_format's Type field as required.

In the s/w rasterizer I've been replacing the texture Format and Type
checks with comparisons against the new MESA_FORMAT_* tokens.

And in the texture-object-completeness function, I'm going to check
if all mipmaps are of the same format by comparing the TexFormat field
instead of the Format/Type fields.

So, the Type field really might not be needed anymore.  However, it
wouldn't be bad to keep it around a bit longer, I think.

-Brian

Re: [Mesa3d-dev] Texture formats

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

Gareth Hughes wrote:
> 
> I'm restoring the behaviour of texImage->Format, and will set
> texImage->IntFormat to the GL format corresponding to the internal Mesa
> format instead of the internalFormat parameter given by the user.

Man, I need a coffee...

Old:

   texImage->Format
   texImage->Type
   texImage->IntFormat

New:

   texImage->Format			/* Regular base format */
   texImage->TexFormat->Type		/* Internal format type */
   texImage->TexFormat->IntFormat	/* Internal GL format */

Still:

   texImage->TexFormat->MesaFormat	/* MESA_FORMAT_* */

So, texImage->Format is initialized by core Mesa before the DD texture
image function is called.  All the driver (or texstore utils) needs to
do plug in an appropriate format into texImage->TexFormat.

-- Gareth

[Mesa3d-dev] Texture formats

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

I'm restoring the behaviour of texImage->Format, and will set
texImage->IntFormat to the GL format corresponding to the internal Mesa
format instead of the internalFormat parameter given by the user.  This
gives the behaviour I'm looking for (ie. users can find out what format
the texture is stored in, and by checking the individual component sizes
can acurately determine how the image is stored).

As far as I can tell, the texImage->Type field is redundant.  We have
the number of bytes per texel stored in texImage->TexFormat->TexelBytes,
and can thus remove the use of texImage->Type in texstore.c.  We'll need
to keep the information around so the software rasterizer can determine
if it can use an optimize CHAN_TYPE texture sampling function.  Thus,
I'll remove the BaseFormat field from gl_texture_format, but keep and
rename the BaseType field.  The software rasterizer will then check the
gl_texture_format's Type field as required.

-- Gareth

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

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

Gareth Hughes wrote:
> 
> Gareth Hughes wrote:
> >
> > > With these latest changes it appears to me that the Format and Type
> > > fields in gl_texture_image are redundant with respect to the BaseFormat
> > > and BaseType fields in the gl_texture_format struct.  I'd like to
> > > remove Format and Type from the former and use the later instead.
> > > I'll work on that too.
> 
> Don't do this -- it's broken.  At the moment, when the hardware has to
> store GL_ALPHA textures in a GL_LUMINANCE_ALPHA format, for instance,
> texFormat->BaseFormat is incorrectly GL_LUMINANCE_ALPHA instead of
> GL_ALPHA.  This is obviously broken (try running texenv on the 3.5
> radeon driver).
> 
> I'm going to undo and rethink this change.


Yeah, I temporarily forgot about this problem too.  There's a difference
between the actual texture image storage 'format' and the 'format' used
during the texture environment computations.

-Brian

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

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

Gareth Hughes wrote:
> 
> > With these latest changes it appears to me that the Format and Type
> > fields in gl_texture_image are redundant with respect to the BaseFormat
> > and BaseType fields in the gl_texture_format struct.  I'd like to
> > remove Format and Type from the former and use the later instead.
> > I'll work on that too.

Don't do this -- it's broken.  At the moment, when the hardware has to
store GL_ALPHA textures in a GL_LUMINANCE_ALPHA format, for instance,
texFormat->BaseFormat is incorrectly GL_LUMINANCE_ALPHA instead of
GL_ALPHA.  This is obviously broken (try running texenv on the 3.5
radeon driver).

I'm going to undo and rethink this change.

-- 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/src/
> Changes by:     brianp@usw-pr-cvs1.     01/03/27 12:26:37
> 
> Log message:
>   fixed RGBA/RGB typo

Wow, that would explain some of the errors I've been seeing...

Thanks!  Nice catch.

-- Gareth