mesa3d-dev

Re: [Mesa3d-dev] undefined macros

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

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi,
> 
> Compiling todays CVS gives me the following undefined macros.
> %LINK-W-NUDFSYMS, 3 undefined symbols:
> %LINK-I-UDFSYM,         FLOAT_COLOR_TO_CHAN
> %LINK-I-UDFSYM,         FLOAT_RGBA_TO_CHAN_RGBA
> %LINK-I-UDFSYM,         LINTERP
> %LINK-W-USEUNDEF, undefined symbol FLOAT_RGBA_TO_CHAN_RGBA referenced
>         in psect $LINK$ offset %X000000F0
>         in module T_IMM_EVAL file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20010103.MESA
> .SRC.TNL]T_IMM_EVAL.OBJ;1
> %LINK-W-USEUNDEF, undefined symbol LINTERP referenced
>         in psect $LINK$ offset %X00000030
>         in module T_VB_RENDER file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20010103.MES
> A.SRC.TNL]T_VB_RENDER.OBJ;1
> %LINK-W-USEUNDEF, undefined symbol FLOAT_COLOR_TO_CHAN referenced
>         in psect $LINK$ offset %X00000040
>         in module T_VB_RENDER file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20010103.MES
> A.SRC.TNL]T_VB_RENDER.OBJ;1
> 
> They seem to be scratched out of the .h files. What was intended here?

Looks like I forgot to check in a file or two.  I'll fix it ASAP.

-Brian

[Mesa3d-dev] undefined macros

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

Hi,

Compiling todays CVS gives me the following undefined macros.
%LINK-W-NUDFSYMS, 3 undefined symbols:
%LINK-I-UDFSYM,         FLOAT_COLOR_TO_CHAN
%LINK-I-UDFSYM,         FLOAT_RGBA_TO_CHAN_RGBA
%LINK-I-UDFSYM,         LINTERP
%LINK-W-USEUNDEF, undefined symbol FLOAT_RGBA_TO_CHAN_RGBA referenced
        in psect $LINK$ offset %X000000F0
        in module T_IMM_EVAL file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20010103.MESA
.SRC.TNL]T_IMM_EVAL.OBJ;1
%LINK-W-USEUNDEF, undefined symbol LINTERP referenced
        in psect $LINK$ offset %X00000030
        in module T_VB_RENDER file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20010103.MES
A.SRC.TNL]T_VB_RENDER.OBJ;1
%LINK-W-USEUNDEF, undefined symbol FLOAT_COLOR_TO_CHAN referenced
        in psect $LINK$ offset %X00000040
        in module T_VB_RENDER file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20010103.MES
A.SRC.TNL]T_VB_RENDER.OBJ;1


They seem to be scratched out of the .h files. What was intended here?

                 Jouk


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

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

  Jouk Jansen
		 
  jo...@hr...

  Technische Universiteit Delft        tttttttttt  uu     uu  ddddddd
  Nationaal centrum voor HREM          tttttttttt  uu     uu  dd    dd
  Rotterdamseweg 137                       tt      uu     uu  dd     dd
  2628 AL Delft                            tt      uu     uu  dd     dd
  Nederland                                tt      uu     uu  dd    dd
  tel. 31-15-2781536                       tt       uuuuuuu   ddddddd

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

Re: [Mesa3d-dev] bugs

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

Hi all,

I wrote on 11-DEC-2000 10:36:53.14

>Since some time (around the same time all the software rastering was put
>in separate directories) I observe the following 2 problems which may or may
>not be related:
>   To test I use the program xlockmore (see ftp://ftp.tux.org./pub/tux/bagleyd/xlockmore/
>
> problems :
>    -in mode moebius a part of the edge is not drawn resulting in a zig-zag
>      line. Mesa3.4 draws it correct
The recent changes of Keith have solved this problem

>    -Occasional xlock crashes in the GL modes due to invalid floats and
>     access violation. I have no idea where to look for the error since
>     normal error messages are not given. So probably a memory leak overwrites
>     the program.
I will check if this problem is gone in some overnight tests. If it is still
there I will report it again, but my guess is that it was related to the
moebius problem.


          Jouk


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

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

  Jouk Jansen
		 
  jo...@hr...

  Technische Universiteit Delft        tttttttttt  uu     uu  ddddddd
  Nationaal centrum voor HREM          tttttttttt  uu     uu  dd    dd
  Rotterdamseweg 137                       tt      uu     uu  dd     dd
  2628 AL Delft                            tt      uu     uu  dd     dd
  Nederland                                tt      uu     uu  dd    dd
  tel. 31-15-2781536                       tt       uuuuuuu   ddddddd

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

Re: [Mesa3d-dev] New TNL module

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

Gareth Hughes wrote:
> 
> Keith Whitwell wrote:
> >
> > I've just committed the first iteration of my reworked software tnl module.
> > The goals of this work are to improve the clarity, flexibility and performance
> > of the t&l module, particularly with regard to driving cards with partial
> > hardware support for the opengl pipeline.
> 
> Great.  From the quick look I've taken, I'm going to enjoy looking at it
> some more ;-)
> 
> I think you've forgotten to commit the array_cache module.  Is this
> right, or is my CVS just playing up?

There's always something that gets missed...  It's committed now.

Keith

Re: [Mesa3d-dev] New TNL module

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

Keith Whitwell wrote:
> 
> I've just committed the first iteration of my reworked software tnl module.
> The goals of this work are to improve the clarity, flexibility and performance
> of the t&l module, particularly with regard to driving cards with partial
> hardware support for the opengl pipeline.

Great.  From the quick look I've taken, I'm going to enjoy looking at it
some more ;-)

I think you've forgotten to commit the array_cache module.  Is this
right, or is my CVS just playing up?

-- Gareth

[Mesa3d-dev] demo subdirs

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

Hi everyone,

I've been quite busy doing cleanup of the automake code (essentially trying to
make 'make dist' work). I think it might be quite convenient to use the dist
targets for whomever makes the releases; at least it doesn't hurt. There is,
however, the issue that the demos are distributed seperately. That's not
really a problem but for it to work with autoconf/make some rearrangement
should be made.

Would you like to see the dist targets function?
If so, would it be feasable to give a single subdir to all the demos, e.g:

demos/book/
      mesademos/
      samples/
      xdemos/
      3Dfx/
      mtdemos/

That way they'd get their own configure script that would be called from the
top-level configure.in on demand (via AC_SUBDIRS).


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

[Mesa3d-dev] New TNL module

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

I've just committed the first iteration of my reworked software tnl module. 
The goals of this work are to improve the clarity, flexibility and performance
of the t&l module, particularly with regard to driving cards with partial
hardware support for the opengl pipeline.

Some highlights of the change:
	
	- tnl pipeline mechanism completely reworked.
		- tnl vertex buffer recast as a struct of pointers with no storage
		- tnl pipeline stages become black boxes, manage their own storage
		- cva and immediate data handled on the same pipeline and vertex buffer
transparently
		- major cleanup of cva code (try and find it...)
	- rework of immediate-mode vertex-copying and fixup
		- copy *untransformed* data only
		- avoid some unnecessary fixup on immediate path
	- rework of DrawArrays/DrawElements/DrawRangeElements per new pipeline code.
	- rework of core mesa statechange operations to try and avoid vertex flushing
(disabled in this commit).
	- lots of other cleanup in tnl.

Almost every file in tnl has been reworked, renamed or removed...  

There is a new module 'array_cache' to manage translations of client data to
formats understandable by 'tnl' as well as any driver-supplied tranformation
code.

This is a large change, and I am aware of at least a few outstanding bugs:

	- wireframe clipping is wrong.
	- demos/fire gives odd looking trees
	- some performance issues remaining  (I do a lot of unnecessary operations at
the moment for debugging)

I've tested only against the Mesa demos so far, so I'm interested to hear how
this works elsewhere.  Don't be too suprised if you see some breakages;
consider this a checkpoint rather than anything final.

In addition I've got a few items left on the todo list:

	- restore support for driver supplied begin/end engines (simple)
	- restore the fx fastpath as an alternate render pipeline stage.
	- lots more testing, including glean and conformance
	- compile better quality display lists.
	

Anyway, enjoy...

Keith

Re: [Mesa3d-dev] glxext.h

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

On Mon, Dec 11, 2000 at 08:44:50AM -0700, Brian Paul wrote:
> 2. The glxext.h file is broken.  It #defines GLX_SGIS_multisample but
> doesn't define any of the extension's new tokens.  I've made a temporary
> fix and will report the problem to SGI.

Is it correct that glxext.h should be installed along with the other glx
headers? I guess, since glx.h includes it (if GLX_GLXEXT_LEGACY isn't
defined). What does GLX_GLXEXT_LEGACY mean?


Regards,
Sven

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

[Mesa3d-dev] make dist?

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

Should I try making the dist targets work, i.e. let automake know about all
files that should go into a distribution?

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

Re: [Mesa3d-dev] GGI

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

On Thu, Dec 21, 2000 at 02:28:57PM -0800, Jon Taylor wrote:
> GGI extensions (of which GGIMesa is one) require the auto* build system 
> to be used.

OK, I understand.

> > Looks ugly. My last try on compiling with autoconfmake chocked on the GGI
> > driver, too. Disabling it in configure.in, OK?
> 
> 	It works fine for me.  Do you have GGI installed, or no?  Anyway, the 

Yes I have. But maybe it's an old version. I'll reenable the GGI code in
configure.in, my fault.


> whole build is now broken for me:
> 
> $ ./bootstrap
> 
> autoheader: error: AC_CONFIG_HEADERS not found in configure.in
Makes no sense: AM_CONFIG_HEADER is used.
> automake: no `Makefile.am' found or specified
Makes no sense: Makefile.am is there.
> configure.in:3: error: Autoconf version 2.49c or higher is required for 
> this script

I guess the first two errors are caused by autoconf/automake choking because
of my use of autoconf 2.49c.

> 	The latest version of autoconf on alpha.gnu.org is 2.49b.  Where can I 
> find 2.49c and why is it necessary to use the absolute newest test 
> releases of autoconf?

2.49c is in CVS (:pserver:an...@su...:/cvs). I use it because
I just like getting all the latest features and I figured it would be suitable
to have it used in development. First thing that comes to mind right now is
the AC_CONFIG_FILES macro that conveniently allows dynamic specification of
output files.

There's only one inconvenience: The newest automake doesn't deal with the
newest libtool correctly: It requires the ltconfig script which is no longer
used by libtool. It is simple, however to patch the current CVS version of
automake: in line 196 remove ltconfig from @libtoolize_files. That's it.



-- 
"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] Need notification.

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

On Thu, Dec 21, 2000 at 04:13:29PM -0700, Keith Whitwell wrote:
> You can also subscribe to mesa3d-cvs and monitor that list for checkins to
> Makefile.X11 and Make-config.

Oh ok, I'll do that.

Sven

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

Re: [Mesa3d-dev] GGI

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

Sven M. Hallberg wrote:

> Hi again,
> 
> Question: Is the GGI driver disabled in the current version? 

	No.  I build it all the time.  It is broken currently, but that's another 
story....

> src/Makefile.X11
> doesn't build any GGI stuff. 

	It isn't supposed to.  That's why it has the .X11 on the end |->.  Also, 
GGI extensions (of which GGIMesa is one) require the auto* build system 
to be used.

> Plus there is no system-specific Makefile in
> src/GGI and the toplevel Makefile.X11 runs make in that dir without arguments.

	See above.  You must use the auto* build system to build GGIMesa.

 
> Looks ugly. My last try on compiling with autoconfmake chocked on the GGI
> driver, too. Disabling it in configure.in, OK?

	It works fine for me.  Do you have GGI installed, or no?  Anyway, the 
whole build is now broken for me:

$ ./bootstrap

autoheader: error: AC_CONFIG_HEADERS not found in configure.in
automake: no `Makefile.am' found or specified
configure.in:3: error: Autoconf version 2.49c or higher is required for 
this script

	The latest version of autoconf on alpha.gnu.org is 2.49b.  Where can I 
find 2.49c and why is it necessary to use the absolute newest test 
releases of autoconf?

Jon

Re: [Mesa3d-dev] Need notification.

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

Jon Taylor wrote:
> 
> Sven M. Hallberg wrote:
> 
> > Me again.
> >
> > I've dug into the autoconfmake build system and noticed that the source file
> > lists in various Makefile.am's are horribly outdated.
> 
>         Not in the main branch it isn't.  I spent several weeks updating the 3.5
> auto* build system, and unless any new files have been added to the tree
> over the last week or so it should still be current.
> 
> > I just wanted to ask
> > everyone to send a short notice to the list whenever they make _any_ changes
> > to the manual make build system so I can apply them to the autoconfmake system
> > as well.
> 
>         You should familiarize yourself with the changes I've made to the auto*
> build system.  They aren't too extensive, but they are there.
> 

You can also subscribe to mesa3d-cvs and monitor that list for checkins to
Makefile.X11 and Make-config.

Keith

Re: [Mesa3d-dev] Need notification.

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

Sven M. Hallberg wrote:

> Me again.
> 
> I've dug into the autoconfmake build system and noticed that the source file
> lists in various Makefile.am's are horribly outdated. 

	Not in the main branch it isn't.  I spent several weeks updating the 3.5 
auto* build system, and unless any new files have been added to the tree 
over the last week or so it should still be current.

> I just wanted to ask
> everyone to send a short notice to the list whenever they make _any_ changes
> to the manual make build system so I can apply them to the autoconfmake system
> as well.

	You should familiarize yourself with the changes I've made to the auto* 
build system.  They aren't too extensive, but they are there.

Jon

[Mesa3d-dev] autoconfmake bugs fixed

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

So here it is finally, someone should close the following bugs:


Bug #126494: Fixed.

Bug #114967: Fixed.

Bug #122196: Can be closed, existing Makefile is already correct.

Bug #122198: Regenerated the file lists by simply putting in *.[ch] found in
             the corresponding source directory. Library and checks build,
             All demos I tried ran fine. -> Can be closed.

Bug #122644: Appears fixed already. Checks for cpuid, MMX, and 3Dnow all
             return "yes" on my system. -> Can be closed.


I've already checked the changes into CVS, so everyone please try the
autoconfmake build mechanism on your systems and report any issues remaining
(submit them to the bug database at sourceforge and drop a note on the list).


Regards,
Sven

PS: I've used the very latest versions of autoconf, automake, and libtool from
their respective CVS repositories. This is reflected in some changes. So be
sure to get those before you try to run the bootstrap script!

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

[Mesa3d-dev] GGI

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

Hi again,

Question: Is the GGI driver disabled in the current version? src/Makefile.X11
doesn't build any GGI stuff. Plus there is no system-specific Makefile in
src/GGI and the toplevel Makefile.X11 runs make in that dir without arguments.

Looks ugly. My last try on compiling with autoconfmake chocked on the GGI
driver, too. Disabling it in configure.in, OK?

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

[Mesa3d-dev] Need notification.

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

Me again.

I've dug into the autoconfmake build system and noticed that the source file
lists in various Makefile.am's are horribly outdated. I just wanted to ask
everyone to send a short notice to the list whenever they make _any_ changes
to the manual make build system so I can apply them to the autoconfmake system
as well.

Thanks,
Sven

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

[Mesa3d-dev] off-line

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

FYI, I'll be (mostly) off-line from tomorrow until Jan 2.  Please
try to help each other out with your questions and problems.

Happy holidays!

-Brian

Re: [Mesa3d-dev] 8 TMUs & ATIX_texture_env_combine3

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

Daniel Vogel wrote:
> 
> On Sat, Dec 16, 2000 at 08:52:53PM -0700, Keith Whitwell wrote:
> >
> > I plan to extend it out to 8 in 3.5 development.  The t&l module supports 12,
> > the software rasterizer pretty much supports an infinite number, the core
> > state management code currently is limited to 4 but can easily extend that out
> > to 8 by rearranging some flags.
> 
> Sweet.
> 
> > > On a different note, would there be any legal issues implementing
> > > ATIX_texture_env_combine3 in Mesa?
> >
> > Don't know, sorry.
> 
> I guess I'll have to email someone at ATI.

Some background for people thinking about extensions -- the software
rasterizer is the key to implementing any extension.  Ususally we can't make
use of the extension even on hardware that supports it until the software
rasterizer code has been written.  The reason is fallbacks - there is almost
always going to be some way to expose the effects of the extension on an
already existing fallback path -- if the software rasterizer doesn't support
the extension, we can't get these new fallback paths right...

Thus it's possible for interested parties to advance the (potential) state of
hardware acceleration under Mesa without ever touching a card at all...

Keith

Re: [Mesa3d-dev] 8 TMUs & ATIX_texture_env_combine3

[Daniel V. <vo...@lo...>]

On Sat, Dec 16, 2000 at 08:52:53PM -0700, Keith Whitwell wrote:
> 
> I plan to extend it out to 8 in 3.5 development.  The t&l module supports 12,
> the software rasterizer pretty much supports an infinite number, the core
> state management code currently is limited to 4 but can easily extend that out
> to 8 by rearranging some flags.

Sweet.

> > On a different note, would there be any legal issues implementing
> > ATIX_texture_env_combine3 in Mesa?
> 
> Don't know, sorry.

I guess I'll have to email someone at ATI.



                            Daniel Vogel, Programmer, Loki Software Inc.

Re: [Mesa3d-dev] 8 TMUs & ATIX_texture_env_combine3

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

Daniel Vogel wrote:
> 
> hi`
> 
> I noticed that software Mesa 3.5 currently supports 4 TMUs. Is there an
> easy way to extend that to 8 (with a define or something like that)?

I plan to extend it out to 8 in 3.5 development.  The t&l module supports 12,
the software rasterizer pretty much supports an infinite number, the core
state management code currently is limited to 4 but can easily extend that out
to 8 by rearranging some flags.
 
> On a different note, would there be any legal issues implementing
> ATIX_texture_env_combine3 in Mesa?

Don't know, sorry.

> I am doing some research in my spare time with regards to scaleability
> and as software Mesa is the only implementation I am aware of that
> currently supports 4 texturing units I am tempted to spend some time
> adding the ATIX_texture_env_combine3 extension to Mesa if it isn't too
> complex and there are no IP issues.

I wouldn't be suprised to see other implementations ramping up for more units
in the near future.  

Keith

[Mesa3d-dev] 8 TMUs & ATIX_texture_env_combine3

[Daniel V. <vo...@lo...>]

hi`

I noticed that software Mesa 3.5 currently supports 4 TMUs. Is there an
easy way to extend that to 8 (with a define or something like that)?

On a different note, would there be any legal issues implementing
ATIX_texture_env_combine3 in Mesa?

I am doing some research in my spare time with regards to scaleability
and as software Mesa is the only implementation I am aware of that
currently supports 4 texturing units I am tempted to spend some time
adding the ATIX_texture_env_combine3 extension to Mesa if it isn't too
complex and there are no IP issues.

 

                            Daniel Vogel, Programmer, Loki Software Inc.

Re: [Mesa3d-dev] bugs

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

Brian Paul wrote:
> 
> Brian Paul wrote:
> >
> > "Jacob (=Jouk) Jansen" wrote:
> > >
> > > Hi all,
> > >
> > > Since some time (around the same time all the software rastering was put
> > > in separate directories) I observe the following 2 problems which may or may
> > > not be related:
> > >    To test I use the program xlockmore (see ftp://ftp.tux.org./pub/tux/bagleyd/xlockmore/
> > >
> > >  problems :
> > >     -in mode moebius a part of the edge is not drawn resulting in a zig-zag
> > >       line. Mesa3.4 draws it correct
> >
> > This looks like a glPolygonMode() bug.  The interior edges in the quad
> > strip shouldn't be rendered.  Keith could probably find this pretty
> > quickly.
> >
> > >     -Occasional xlock crashes in the GL modes due to invalid floats and
> > >      access violation. I have no idea where to look for the error since
> > >      normal error messages are not given. So probably a memory leak overwrites
> > >      the program.
> >
> > Which modes or programs in particular cause this?
> 
> I found the problem.
> 
> gloss has an FP exception if I run with "setenv MESA_DEBUG FP".
> 
> The problem is in the texgen code.  In the template function
> for texgen_sphere_map() the VB->tmp_f array is NULL and being
> allocated on the spot.  However, its contents are undefined.
> 
> Below is a simple patch which just changes the MALLOC to a CALLOC
> so the array is initialized to zero.
> 
> I know Keith's been changing the vertex buffer code so I'll
> wait for him to comment before committing this.

I'll check this change into my codebase.  The name of that file has changed
(there's no need for a _tmp file any longer).  Don't worry about committing
it.

In fact, I'd be happiest if people held off all commits to the tnl/ directory
until I get this code in.

Keith

Re: [Mesa3d-dev] bugs

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

Brian Paul wrote:
> 
> "Jacob (=Jouk) Jansen" wrote:
> >
> > Hi all,
> >
> > Since some time (around the same time all the software rastering was put
> > in separate directories) I observe the following 2 problems which may or may
> > not be related:
> >    To test I use the program xlockmore (see ftp://ftp.tux.org./pub/tux/bagleyd/xlockmore/
> >
> >  problems :
> >     -in mode moebius a part of the edge is not drawn resulting in a zig-zag
> >       line. Mesa3.4 draws it correct
> 
> This looks like a glPolygonMode() bug.  The interior edges in the quad
> strip shouldn't be rendered.  Keith could probably find this pretty
> quickly.

I'm reworking the edgeflag/polygon-mode code to be transparent and robust. 
Don't bother too much about bugs in the existing code.

Keith

Re: [Mesa3d-dev] bugs

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

Brian Paul wrote:
> 
> "Jacob (=Jouk) Jansen" wrote:
> >
> > Hi all,
> >
> > Since some time (around the same time all the software rastering was put
> > in separate directories) I observe the following 2 problems which may or may
> > not be related:
> >    To test I use the program xlockmore (see ftp://ftp.tux.org./pub/tux/bagleyd/xlockmore/
> >
> >  problems :
> >     -in mode moebius a part of the edge is not drawn resulting in a zig-zag
> >       line. Mesa3.4 draws it correct
> 
> This looks like a glPolygonMode() bug.  The interior edges in the quad
> strip shouldn't be rendered.  Keith could probably find this pretty
> quickly.
> 
> >     -Occasional xlock crashes in the GL modes due to invalid floats and
> >      access violation. I have no idea where to look for the error since
> >      normal error messages are not given. So probably a memory leak overwrites
> >      the program.
> 
> Which modes or programs in particular cause this?


I found the problem.

gloss has an FP exception if I run with "setenv MESA_DEBUG FP".

The problem is in the texgen code.  In the template function
for texgen_sphere_map() the VB->tmp_f array is NULL and being
allocated on the spot.  However, its contents are undefined.

Below is a simple patch which just changes the MALLOC to a CALLOC
so the array is initialized to zero.

I know Keith's been changing the vertex buffer code so I'll
wait for him to comment before committing this.

-Brian



*** t_texgen_tmp.h      2000/11/16 21:05:42     1.1
--- t_texgen_tmp.h      2000/12/15 22:57:19
***************
*** 291,297 ****
     GLfloat (*f)[3], *m;
  
     if (!VB->tmp_f) 
!       VB->tmp_f = (GLfloat (*)[3]) MALLOC(VB->Size * sizeof(GLfloat) * 3);
  
     if (!VB->tmp_m) 
        VB->tmp_m = (GLfloat *) MALLOC(VB->Size * sizeof(GLfloat));
--- 291,297 ----
     GLfloat (*f)[3], *m;
  
     if (!VB->tmp_f) 
!       VB->tmp_f = (GLfloat (*)[3]) CALLOC(VB->Size * sizeof(GLfloat) * 3);
  
     if (!VB->tmp_m) 
        VB->tmp_m = (GLfloat *) MALLOC(VB->Size * sizeof(GLfloat));