mesa3d-dev

Re: [Mesa3d-dev] SET_IMMEDIATE macro in tnl/t_context.h

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

Keith Whitwell wrote:
> 

> 
> This makes sense, though I don't understand why it didn't complain to me (it
> did about other similar problems).
> 

Ahh.  You're compiling without threads, so it was hidden.

Keith

Re: [Mesa3d-dev] SET_IMMEDIATE macro in tnl/t_context.h

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

Li Ming wrote:
> 
> Hi,
> 
> Another compilation problem on Irix platform
> ----------symptom----------------
> cc-1133 cc: ERROR File = tnl/t_dlist.c, Line = 97
>   Expression must be a modifiable lvalue.
> 
>         SET_IMMEDIATE( ctx, new_im );
>         ^
> 
> cc-1133 cc: ERROR File = tnl/t_dlist.c, Line = 193
>   Expression must be a modifiable lvalue.
> 
>      SET_IMMEDIATE( ctx, TNL_VB(ctx)->IM );
>      ^
> 
> cc-1133 cc: ERROR File = tnl/t_dlist.c, Line = 204
>   Expression must be a modifiable lvalue.
> 
>      SET_IMMEDIATE( ctx, IM );
> 
> -----------cause-----------------
> This is because in tnl/t_context.h
>  do {                                            \
>      TNL_CURRENT_IM(ctx) = im;                    \
>      _mesa_CurrentInput = im;                     \
>  } while (0)
> 
> TNL_CURRENT_IM(ctx)  will produce a value not suitable put in the left
> side.
> 
> -----------solution----------------
> So maybe this line should be modified to
> ctx->swtnl_im = (void *)im
>

This makes sense, though I don't understand why it didn't complain to me (it
did about other similar problems).

Keith

[Mesa3d-dev] Re: SET_IMMEDIATE macro in tnl/t_context.h

[Li M. <mi...@mp...>]

This problem happens when I use
make -f Makefile.X11 irix6-n32-dso (gcc is the compiler)

It will disappear when using
make -f Makefile.X11 irix6-gcc-n32-sl (gcc is the compiler)

The problem "_P in types.h", which I reported shortly before,
will also go away if using gcc.

Li Ming.



> Li Ming wrote:
>
> > Hi,
> >
> > Another compilation problem on Irix platform
> > ----------symptom----------------
> > cc-1133 cc: ERROR File = tnl/t_dlist.c, Line = 97
> >   Expression must be a modifiable lvalue.
> >
> >         SET_IMMEDIATE( ctx, new_im );
> >         ^
> >
> > cc-1133 cc: ERROR File = tnl/t_dlist.c, Line = 193
> >   Expression must be a modifiable lvalue.
> >
> >      SET_IMMEDIATE( ctx, TNL_VB(ctx)->IM );
> >      ^
> >
> > cc-1133 cc: ERROR File = tnl/t_dlist.c, Line = 204
> >   Expression must be a modifiable lvalue.
> >
> >      SET_IMMEDIATE( ctx, IM );
> >
> > -----------cause-----------------
> > This is because in tnl/t_context.h
> >  do {                                            \
> >      TNL_CURRENT_IM(ctx) = im;                    \
> >      _mesa_CurrentInput = im;                     \
> >  } while (0)
> >
> > TNL_CURRENT_IM(ctx)  will produce a value not suitable put in the left
> > side.
> >
> > -----------solution----------------
> > So maybe this line should be modified to
> > ctx->swtnl_im = (void *)im
> >
> > ---------
> > Li Ming

[Mesa3d-dev] SET_IMMEDIATE macro in tnl/t_context.h

[Li M. <mi...@mp...>]

Hi,

Another compilation problem on Irix platform
----------symptom----------------
cc-1133 cc: ERROR File = tnl/t_dlist.c, Line = 97
  Expression must be a modifiable lvalue.

        SET_IMMEDIATE( ctx, new_im );
        ^

cc-1133 cc: ERROR File = tnl/t_dlist.c, Line = 193
  Expression must be a modifiable lvalue.

     SET_IMMEDIATE( ctx, TNL_VB(ctx)->IM );
     ^

cc-1133 cc: ERROR File = tnl/t_dlist.c, Line = 204
  Expression must be a modifiable lvalue.

     SET_IMMEDIATE( ctx, IM );

-----------cause-----------------
This is because in tnl/t_context.h
 do {                                            \
     TNL_CURRENT_IM(ctx) = im;                    \
     _mesa_CurrentInput = im;                     \
 } while (0)

TNL_CURRENT_IM(ctx)  will produce a value not suitable put in the left
side.

-----------solution----------------
So maybe this line should be modified to
ctx->swtnl_im = (void *)im



---------
Li Ming

[Mesa3d-dev] _P in types.h

[Li M. <mi...@mp...>]

Hi,

I encountered a compilation problem on Irix platform.
in types.h

 struct gl_texture_object {
  ..
  GLint _P;                    /* Highest mipmap level */
  ...
 }

The _P has been defined as a macro in line 42 of /usr/include/ctype.h

  #define _P      0x00000010      /* Punctuation */

So I think

#ifdef _P
#undef _P
#endif

This should be added at the beginning of the types.h.

Li Ming.

[Mesa3d-dev] tgmath.h

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

Hi All,

what is tgmath.h. It is not available on my VMS-box. Leaving it out seems
to work. Is VMS the only system lacking this include file?

         Jouk

P.S. I changed on my system all occurences of "types.h" to "mesa_types.h".
 If Brian says this change is OK I'll check them in this afternoon (MET)
 Otherwise if I hear no objections I'll check them in wednesday morning (MET)
 (tomorrow I'll be off-line)

                  JJ


Ceterum censeo tertium millennium post Christum natum anno MMI incepturum esse

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

  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] Includes using "../"

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

Gareth Hughes wrote:
> 
> Why do some of the files in subfolders under Mesa/src include with
> "../"?  For example, files are picking up the tnl directory files with
> "../tnl/t_context.h" or similar.
> 
> If this is to support automake, please change it so Mesa/src/ is in the
> include path rather than referencing the files with relative paths.
> This is what the old-style makefiles do.
> 

I see only:

[keithw@rover src-flags]$ grep "\.\./" `find . -name \*.[ch]`
./GGI/default/stubs.c:#include "../../swrast/swrast.h"
./GGI/default/stubs.c:#include "../../swrast_setup/swrast_setup.h"
./X/xmesaP.h:#include "../FX/fxdrv.h"

I'm sure these will work fine without the ../, or if not (GGI?) they will by
bringing their makefiles etc into line with the other ones.

Keith

[Mesa3d-dev] Includes using "../"

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

Why do some of the files in subfolders under Mesa/src include with 
"../"?  For example, files are picking up the tnl directory files with 
"../tnl/t_context.h" or similar.

If this is to support automake, please change it so Mesa/src/ is in the 
include path rather than referencing the files with relative paths. 
This is what the old-style makefiles do.

-- Gareth

Re: [Mesa3d-dev] src/types.h

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

"Jacob (=Jouk) Jansen" wrote:
> 
> br...@va... wrote on 17-NOV-2000 16:53:40.03
> To:     "Jacob (=Jouk) Jansen" <jo...@hr...>
> CC:
> Subj:   Re: [Mesa3d-dev] src/types.h
> 
> >"Jacob (=Jouk) Jansen" wrote:
> >>
> >> Hi all,
> >>
> >> src/types.h gives problems on my VMS machine because it is sometimes mixed-up
> >> for the system include file types.h. My suggestion is to give it another name
> >> but which???
> >
> >Once upon a time, the dlist.h source file was just named list.h and
> >people said that their compilers were getting a system list.h file
> >instead.  So I renamed list.h to dlist.h.  I wondered how types.h
> >worked for those same people.
> The problem arose when I switched the threads on. <pthread.h> includes
> somewhere <types.h>, which is supposed to be the system one, however mesa's
> one was taken.
> 
> >My understanding of #include is that #include "quotes.h" should
> >search the current directory then -I directories before the
> >system include directories.  Conversely, #include <brackets.h>
> >should search the system directories first.  I lost my copy of
> >the K&R book years ago.  Can someone verify this?
> In that case my prepocessor is buggy!
> 
> >Are you sure that there's no accidental use of #include <types.h>?
> >Or perhaps you need the equivalent to -I. for your compiler?
> see above


Well, if you really can't fix this problem we can rename types.h.
It's not a big deal.  Now would be the time to do it since we're
making lots of changes.

-Brian

Re: [Mesa3d-dev] src/types.h

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

br...@va... wrote on 17-NOV-2000 16:53:40.03
To:	"Jacob (=Jouk) Jansen" <jo...@hr...>
CC:	
Subj:	Re: [Mesa3d-dev] src/types.h

>"Jacob (=Jouk) Jansen" wrote:
>> 
>> Hi all,
>> 
>> src/types.h gives problems on my VMS machine because it is sometimes mixed-up
>> for the system include file types.h. My suggestion is to give it another name
>> but which???
>
>Once upon a time, the dlist.h source file was just named list.h and
>people said that their compilers were getting a system list.h file
>instead.  So I renamed list.h to dlist.h.  I wondered how types.h
>worked for those same people.
The problem arose when I switched the threads on. <pthread.h> includes
somewhere <types.h>, which is supposed to be the system one, however mesa's
one was taken. 

>My understanding of #include is that #include "quotes.h" should
>search the current directory then -I directories before the
>system include directories.  Conversely, #include <brackets.h>
>should search the system directories first.  I lost my copy of
>the K&R book years ago.  Can someone verify this?
In that case my prepocessor is buggy!

>Are you sure that there's no accidental use of #include <types.h>?
>Or perhaps you need the equivalent to -I. for your compiler?
see above


Ceterum censeo tertium millennium post Christum natum anno MMI incepturum esse

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

  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] src/types.h

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

Keith Whitwell wrote:
> 
> "Jacob (=Jouk) Jansen" wrote:
> >
> > Hi all,
> >
> > src/types.h gives problems on my VMS machine because it is sometimes mixed-up
> > for the system include file types.h. My suggestion is to give it another name
> > but which???
> >
> 
> Maybe context.h, as that is the major structure defined there.  There is
> already a context.h, but I don't think merging them would be a disaster.

I'd actually like to trim-down context.h.  The idea being that
context.h exports the top-level interface to Mesa which GLX (for
example) would use.  My other goal is to make the top-level
interface look more like the SI's.

-Brian

Re: [Mesa3d-dev] src/types.h

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

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi all,
> 
> src/types.h gives problems on my VMS machine because it is sometimes mixed-up
> for the system include file types.h. My suggestion is to give it another name
> but which???

Once upon a time, the dlist.h source file was just named list.h and
people said that their compilers were getting a system list.h file
instead.  So I renamed list.h to dlist.h.  I wondered how types.h
worked for those same people.

My understanding of #include is that #include "quotes.h" should
search the current directory then -I directories before the
system include directories.  Conversely, #include <brackets.h>
should search the system directories first.  I lost my copy of
the K&R book years ago.  Can someone verify this?

Are you sure that there's no accidental use of #include <types.h>?
Or perhaps you need the equivalent to -I. for your compiler?

-Brian

Re: [Mesa3d-dev] src/types.h

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

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi all,
> 
> src/types.h gives problems on my VMS machine because it is sometimes mixed-up
> for the system include file types.h. My suggestion is to give it another name
> but which???
> 

Maybe context.h, as that is the major structure defined there.  There is
already a context.h, but I don't think merging them would be a disaster.

Keith

[Mesa3d-dev] src/types.h

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

Hi all,

src/types.h gives problems on my VMS machine because it is sometimes mixed-up
for the system include file types.h. My suggestion is to give it another name
but which???

              Jouk


Ceterum censeo tertium millennium post Christum natum anno MMI incepturum esse

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

  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

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

[Mesa3d-dev] suspicious compiler informationals

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

Hi

Hi,

the following compiler informationals seem to indicate that something is not
realy correct:

c /include=([-.include],[])/define=(PTHREADS=1)/name=(as_is,short) /obj=[.tnl]t
_vbxform.obj [.tnl]t_vbxform.c

      if ((flags&VERT_TEX3_ANY) && VB->TexCoordPtr[3] == &prev->v.TexCoord[3])
...................................................^
%CC-I-SUBSCRBOUNDS, In this statement, an array is being accessed outside the bo
unds specified for the array type.
at line number 218 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001117.MESA.SRC.TN
L]T_VBXFORM.C;1

         COPY_4FV( next->TexCoord[3][dst], prev->TexCoord[3][src] );
.........^
%CC-I-SUBSCRBOUNDS, In the initializer for _tmp, an array is being accessed outs
ide the bounds specified for the array type.
at line number 219 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001117.MESA.SRC.TN
L]T_VBXFORM.C;1

         COPY_4FV( next->TexCoord[3][dst], prev->TexCoord[3][src] );
.........^
%CC-I-SUBSCRBOUNDS, In this statement, an array is being accessed outside the bo
unds specified for the array type.
at line number 219 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001117.MESA.SRC.TN
L]T_VBXFORM.C;1

         COPY_4FV( next->TexCoord[3][dst], prev->TexCoord[3][src] );
.........^
%CC-I-SUBSCRBOUNDS, In this statement, an array is being accessed outside the bo
unds specified for the array type.
at line number 219 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001117.MESA.SRC.TN
L]T_VBXFORM.C;1

         COPY_4FV( next->TexCoord[3][dst], prev->TexCoord[3][src] );
.........^
%CC-I-SUBSCRBOUNDS, In this statement, an array is being accessed outside the bo
unds specified for the array type.
at line number 219 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001117.MESA.SRC.TN
]T_VBXFORM.C;1

         COPY_4FV( next->TexCoord[3][dst], prev->TexCoord[3][src] );
.........^
%CC-I-SUBSCRBOUNDS, In this statement, an array is being accessed outside the bo
unds specified for the array type.
at line number 219 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001117.MESA.SRC.TN
L]T_VBXFORM.C;1


                       Jouk


Ceterum censeo tertium millennium post Christum natum anno MMI incepturum esse

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

  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

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

[Mesa3d-dev] Compiling Mesa 3.4 on Windows

[Joshua N. <jn...@ac...>]

To get Mesa 3.4 to compile on Windows, I needed a few trivial changes:


1. windows.h wants to get included before mesa_wgl.h; it needs

RCS file: /shared/development/CVS/hmesa/src-glu/gluP.h,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 gluP.h
33a34,40
> #ifdef _WIN32
> #define WIN32_LEAN_AND_MEAN 1
> #include <windows.h>
> #undef WIN32_LEAN_AND_MEAN
> #endif
>
>

RCS file: /shared/development/CVS/hmesa/src-glut/glutbitmap.h,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 glutbitmap.h
11a12,18
>
> #ifdef _WIN32
> #define WIN32_LEAN_AND_MEAN 1
> #include <windows.h>
> #undef WIN32_LEAN_AND_MEAN
> #endif
>


2. Compiling for Windows, glut still looks for MESA to be defined to
compile for Mesa. I just added the definition to the makefile, and it
worked fine:

RCS file: /shared/development/CVS/hmesa/WIN32/RULES/lib.glut32,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 lib.glut32
19c19
< CPPOPTS = $(CPPOPTS) /DBUILD_GLUT32
---
> CPPOPTS = $(CPPOPTS) /DBUILD_GLUT32 /DMESA



3. The make file for the demos adds too many 'd's to the debug .lib
names:

RCS file: /shared/development/CVS/hmesa/WIN32/RULES/progs.demos,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 progs.demos
16,22d15
< !IF ("$(USE_SYSGL)" == "0") && ("$(DEBUG)" == "1")
< EXELIBS=$(EXELIBS:.lib=d.lib)
< !IF "$(RUNTIMELIBS)" != ""
< RUNTIMELIBS=$(RUNTIMELIBS:.dll=d.dll)
< !ENDIF
< !ENDIF
<



4. All of the demo programs at need windows.h included before
gl.h/glut.h.



- Josh

Re: [Mesa3d-dev] Optimize Texturing

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

Klaus Niederkrueger wrote:
> 
> My last email proposing an optimized, but not-GL-conformant, Game-Mode has not found many friends, so I guess, that the existing triangle-functions have to be optimized.
> 
> While I don't have the time to do it myself, I have thought of some method that should be taken by someone (that at least is what I hope) to implement them.
> 
> Most OpenGL-games render everything with Mipmapping enabled supposing that you have some Hardware that helps, so I took a look at them.
> 
> The current Mipmapping functions in the Mesa-code use at every plotted pixel a logarithm function to determine, which mipmapping-level should be used. This cannot (at least that I see) be avoided if you use an interpolation between these levels (like GL_xxx_MIPMAP_LINEAR) do.
> 
> But in the other cases I have developed a strategy, that maybe gives a speed-up, but which requires some changes in the source-code that are quite complex:
> 
> If the texturing mode is none of the both above, then evaluate lambda (=mipmap-level) at the three vertices of the triangle. If they all are the same (rounding with 'rint', but I'm not sure of this, maybe rounding with '(int)'), then all the lambda values of the whole triangle will be identical, therefore, you can switch to that mipmap-level and use a normal GL_LINEAR resp. GL_NEAREST-algorithm to do the rest of the work (this evaluates only 3 times 'log' instead of 'number-of-pixel'-times).
> If the three values where different you proceed like it is done now, until the point, where each horizontal line is drawn. There you evaluate 'lambda' at the end and at the beginning of the line (lambda(0) and lambda(n)). Since lambda is a monotonous function, if these values are equal (after rounding) you can use this value to draw the whole line (and what would be in my opinion important is that you don't use gl_write_texture_span at the end, since this is quite slow, but this also requires a lot of work and thought).
> 
> Otherwise you proceed like it is done right now.
> 
> How often to I have to evaluate the log-function with the two methods?
> Suppose the triangle had n lines with m pixels each.
>                 Now     New method
> Best            n*m     3
> Medium          n*m     2*n (+3)
> Worst           n*m     n*m + 2*n (+3)
> 
> Another thing that could be implemented is a function
> float fast_log_2 (float arg)
> that does the following:
> 
>   -- convert 'arg' to an 'int'
>   -- if (int)arg is smaller then e.g. 64 look the value up in a static array that is being created at start time.
>   -- otherwise use '(int)arg>>1' until this value is smaller than e.g. 64 in which case you can use the array above and sum to the value the number of times you used '>>1'.
> 
> This way you get an integer-log-2 function and you don't have to use 'log(arg)*(1/log(2)). I believe that this function should be faster than the normal one (but you can use it only for calculations where you don't want to interpolate over the 'lambda'-mipmapping-levels).
> 
> Maybe someone has the time and the patience to play around with my ideas, I believe that they would give a very high performance gain.
> 
> The main difficulty is in introducing the calculation of the log-functions at the three vertices, since the file s_tritemp.h had to be changed.
> 
> So again, I hope someone tries my ideas. I think it really is important, that some optimization happens. It was being pointed out on the newsgroup, that 3d-hw is so cheap nowadays, that software-rendering is not important anymore, but I think this is really not true (it is not important if you use Windows: I have a 486, an K6 and an K6-2 at home and only the later has a ATI-Mach 64 which I use with utah-glx, but 30% of the time I start an application it hangs the machine, I worked in a company using Linux on all systems and none of the systems had running 3d-acceleration, here at the university I asked the system administrator if some of the 50 machines had hw-acceleration under Linux and none had, so I think software-rendering is right now, the only way to use 3d on Linux (without XFree 4.0, which I have never seen running anyway)).
> If someone has questions, I hope I can help him. Thanks for your patience reading to this point.

Certainly Mesa's s/w triangle rendering could be made faster but
I don't see myself having the time or inclination to do it.

Regarding your ideas for lambda calculation:

1. The three vertex lambdas will be equal only for triangles that
are nearly parallel to the viewplane.

2. The span end-point lambdas will be equal only for triangles
that are nearly parallel to the eye-space X axis.

If you consider a game like Quake where you're moving through
a 3D environment the floors and ceilings will often satisfy the
second condition but only seldom will a wall satisify the first
condition.  It's important to consider the typical usage patterns
before doing too much work.

-Brian

[Mesa3d-dev] Optimize Texturing

[Klaus N. <kl...@ma...>]

My last email proposing an optimized, but not-GL-conformant, Game-Mode has not found many friends, so I guess, that the existing triangle-functions have to be optimized.

While I don't have the time to do it myself, I have thought of some method that should be taken by someone (that at least is what I hope) to implement them.

Most OpenGL-games render everything with Mipmapping enabled supposing that you have some Hardware that helps, so I took a look at them.

The current Mipmapping functions in the Mesa-code use at every plotted pixel a logarithm function to determine, which mipmapping-level should be used. This cannot (at least that I see) be avoided if you use an interpolation between these levels (like GL_xxx_MIPMAP_LINEAR) do.

But in the other cases I have developed a strategy, that maybe gives a speed-up, but which requires some changes in the source-code that are quite complex:

If the texturing mode is none of the both above, then evaluate lambda (=mipmap-level) at the three vertices of the triangle. If they all are the same (rounding with 'rint', but I'm not sure of this, maybe rounding with '(int)'), then all the lambda values of the whole triangle will be identical, therefore, you can switch to that mipmap-level and use a normal GL_LINEAR resp. GL_NEAREST-algorithm to do the rest of the work (this evaluates only 3 times 'log' instead of 'number-of-pixel'-times).
If the three values where different you proceed like it is done now, until the point, where each horizontal line is drawn. There you evaluate 'lambda' at the end and at the beginning of the line (lambda(0) and lambda(n)). Since lambda is a monotonous function, if these values are equal (after rounding) you can use this value to draw the whole line (and what would be in my opinion important is that you don't use gl_write_texture_span at the end, since this is quite slow, but this also requires a lot of work and thought).

Otherwise you proceed like it is done right now.

How often to I have to evaluate the log-function with the two methods?
Suppose the triangle had n lines with m pixels each. 
		Now	New method
Best		n*m	3
Medium		n*m	2*n (+3)
Worst		n*m     n*m + 2*n (+3)


Another thing that could be implemented is a function
float fast_log_2 (float arg)
that does the following: 

  -- convert 'arg' to an 'int'
  -- if (int)arg is smaller then e.g. 64 look the value up in a static array that is being created at start time.
  -- otherwise use '(int)arg>>1' until this value is smaller than e.g. 64 in which case you can use the array above and sum to the value the number of times you used '>>1'.

This way you get an integer-log-2 function and you don't have to use 'log(arg)*(1/log(2)). I believe that this function should be faster than the normal one (but you can use it only for calculations where you don't want to interpolate over the 'lambda'-mipmapping-levels).

Maybe someone has the time and the patience to play around with my ideas, I believe that they would give a very high performance gain.

The main difficulty is in introducing the calculation of the log-functions at the three vertices, since the file s_tritemp.h had to be changed.

So again, I hope someone tries my ideas. I think it really is important, that some optimization happens. It was being pointed out on the newsgroup, that 3d-hw is so cheap nowadays, that software-rendering is not important anymore, but I think this is really not true (it is not important if you use Windows: I have a 486, an K6 and an K6-2 at home and only the later has a ATI-Mach 64 which I use with utah-glx, but 30% of the time I start an application it hangs the machine, I worked in a company using Linux on all systems and none of the systems had running 3d-acceleration, here at the university I asked the system administrator if some of the 50 machines had hw-acceleration under Linux and none had, so I think software-rendering is right now, the only way to use 3d on Linux (without XFree 4.0, which I have never seen running anyway)).
If someone has questions, I hope I can help him. Thanks for your patience reading to this point.

Bye

	Klaus

Re: [Mesa3d-dev] vbindirect.c

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

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi All,
> 
> In src/vbindirect in the latest CVS the macro INIT is not defined resulting
> in unresolved externals. What was intended here?
> 
>               Jouk

Nothing.  I'll add a default null to the include file - there used to be a
swrast flush in there and before that reduced_primitive_change.  These are now
driver issues that core mesa doesn't have to deal with.

Keith

[Mesa3d-dev] vbindirect.c

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

Hi All,

In src/vbindirect in the latest CVS the macro INIT is not defined resulting
in unresolved externals. What was intended here?

              Jouk


Ceterum censeo tertium millennium post Christum natum anno MMI incepturum esse

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

  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] Game-Mode

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

Klaus Niederkrueger wrote:
> 
> Over the last weeks I came to the following conclusion:
> Mesa in software-mode is unusable for many applications (i.e. games and such).
> It is much too slow and the idea I had was to optimize the textured-triangle functions, which for example in the case of mipmapping compute for every drawn pixel a log-function.
> 
> Though optimizing may well be possible it leads to a lot of trouble: The code grows a lot in size and it is more difficult to maintain (e.g. you have texturing mode for minimizing, for maximizing, for perspective_correction and for no perspective correction etc. only these three parameters lead to 16 possibilities and if you take GL_RGB, GL_RGBA, GL_BLEND, GL_DECAL, GL_REPLACE everything is much worse).
> 
> My idea is therefore the following: Check for example at start-time for an environment-variable MESA_FAST_MODE or something and if it is set, all texturing functions are overridden by GL_NEAREST for max and GL_NEAREST_MIPMAP_NEAREST for minimizing pixels, possibly supporting only two color-depths (16 bits and 24 or 32) and optimizing the functions for these screen-settings. I know that this mode would not be OpenGL-compliant, but since it would be optional it should be o.k.
> 
> This way in Linux you would have a 3D-gl that would be universally usable and would then be used by all 3d-applications (in contrast to many programs now like quake, crystal-space etc. that use their own software-rendering or OpenGL-Hardware).
> 
> What do you think?


I'm hesitant to go down that path.  Over the years it's been tempting
to take short-cuts in Mesa by trading off conformance for speed but
I've never done so.  I'm afraid that if we start doing so we'll
wind up with a mess.

I've also found that if you're careful you can accomplish good optimizations
while maintaining conformance.

I think the kinds of changes you suggest could be more easily done in
the application itself.  That way the app might run faster on any OpenGL
implementation.

-Brian

Re: [Mesa3d-dev] Game-Mode

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

On Mon, Nov 13, 2000 at 11:11:20AM +0100, Klaus Niederkrueger wrote:

| My idea is therefore the following:  Check for example at start-time
| for an environment-variable MESA_FAST_MODE or something and if it is
| set, all texturing functions are overridden by GL_NEAREST for max
| and GL_NEAREST_MIPMAP_NEAREST for minimizing pixels, possibly
| supporting only two color-depths (16 bits and 24 or 32) and
| optimizing the functions for these screen-settings.

I would worry that this might break applications.  Some apps specify
particular filtering modes for good reasons of their own; setting the
environment variable would cause those apps to silently produce
incorrect results.

As a general matter, I'd vote to use the software renderer for
fallbacks and for experimental rendering extensions; I wouldn't spend
too much time trying to optimize it for speed these days, since
accelerator hardware is ubiquitous and cheap.

Allen

Re: [Mesa3d-dev] teximage.c

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

Brian Paul wrote:
> 
> "Jacob (=Jouk) Jansen" wrote:
> >
> > br...@va... wrote on 13-NOV-2000 08:41:11.07
> > >"Jacob (=Jouk) Jansen" wrote:
> > >> In teximage.c from the main CVS branche at line 2201 texImage is used without
> > >> any initialization. My compiler chokes on it and I do think the initialization
> > >> is missing.
> > >> In a previous version this happened by
> > >>     texImage = _mesa_select_tex_image(ctx, texUnit, target, level);
> > >> Just above line 2201.
> > >> Should this line be reinserted???
> > >
> > >Yes, I think I made a cut&paste error when I was working on that code.
> > >Namely, I forgot to to do the paste!
> >  Now your code reads:
> >
> >    texUnit = &(ctx->Texture.Unit[ctx->Texture.CurrentUnit]);
> >    texObj = _mesa_select_tex_object(ctx, texUnit, target);
> >    if (!texObj || !texImage ||
> >        target == GL_PROXY_TEXTURE_1D ||
> >        target == GL_PROXY_TEXTURE_2D ||
> >        target == GL_PROXY_TEXTURE_3D) {
> >       gl_error(ctx, GL_INVALID_ENUM, "glGetTexImage(target)");
> >       return;
> >    }
> >
> >    texImage = _mesa_select_tex_image(ctx, texUnit, target, level);
> >    if (!texImage) {
> >       /* invalid mipmap level, not an error */
> >       return;
> >    }
> >
> > Should the
> >    if (!texObj || !texImage ||
> > be replaced by
> >    if (!texObj ||
> 
> It should be if (!texObj || !texUnit ||
> 
> Sorry.  I'll fix it ASAP.

Ugh, no, you were right.  It should just test texObj.

I haven't had my coffee yet.

-Brian

Re: [Mesa3d-dev] teximage.c

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

"Jacob (=Jouk) Jansen" wrote:
> 
> br...@va... wrote on 13-NOV-2000 08:41:11.07
> >"Jacob (=Jouk) Jansen" wrote:
> >> In teximage.c from the main CVS branche at line 2201 texImage is used without
> >> any initialization. My compiler chokes on it and I do think the initialization
> >> is missing.
> >> In a previous version this happened by
> >>     texImage = _mesa_select_tex_image(ctx, texUnit, target, level);
> >> Just above line 2201.
> >> Should this line be reinserted???
> >
> >Yes, I think I made a cut&paste error when I was working on that code.
> >Namely, I forgot to to do the paste!
>  Now your code reads:
> 
>    texUnit = &(ctx->Texture.Unit[ctx->Texture.CurrentUnit]);
>    texObj = _mesa_select_tex_object(ctx, texUnit, target);
>    if (!texObj || !texImage ||
>        target == GL_PROXY_TEXTURE_1D ||
>        target == GL_PROXY_TEXTURE_2D ||
>        target == GL_PROXY_TEXTURE_3D) {
>       gl_error(ctx, GL_INVALID_ENUM, "glGetTexImage(target)");
>       return;
>    }
> 
>    texImage = _mesa_select_tex_image(ctx, texUnit, target, level);
>    if (!texImage) {
>       /* invalid mipmap level, not an error */
>       return;
>    }
> 
> Should the
>    if (!texObj || !texImage ||
> be replaced by
>    if (!texObj ||

It should be if (!texObj || !texUnit ||

Sorry.  I'll fix it ASAP.

-Brian

[Mesa3d-dev] Game-Mode

[Klaus N. <kl...@ma...>]

Over the last weeks I came to the following conclusion:
Mesa in software-mode is unusable for many applications (i.e. games and such).
It is much too slow and the idea I had was to optimize the textured-triangle functions, which for example in the case of mipmapping compute for every drawn pixel a log-function.

Though optimizing may well be possible it leads to a lot of trouble: The code grows a lot in size and it is more difficult to maintain (e.g. you have texturing mode for minimizing, for maximizing, for perspective_correction and for no perspective correction etc. only these three parameters lead to 16 possibilities and if you take GL_RGB, GL_RGBA, GL_BLEND, GL_DECAL, GL_REPLACE everything is much worse).

My idea is therefore the following: Check for example at start-time for an environment-variable MESA_FAST_MODE or something and if it is set, all texturing functions are overridden by GL_NEAREST for max and GL_NEAREST_MIPMAP_NEAREST for minimizing pixels, possibly supporting only two color-depths (16 bits and 24 or 32) and optimizing the functions for these screen-settings. I know that this mode would not be OpenGL-compliant, but since it would be optional it should be o.k.

This way in Linux you would have a 3D-gl that would be universally usable and would then be used by all 3d-applications (in contrast to many programs now like quake, crystal-space etc. that use their own software-rendering or OpenGL-Hardware).

What do you think?

Bye 

	Klaus