mesa3d-dev

Re: [Mesa3d-dev] Mesa autoconf problem

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

On Tue, May 15, 2001 at 07:18:06AM -0600, Brian Paul wrote:
> I should have clarified that I'm looking at the mesa_3_4_branch, not
> the trunk.

OIC. Almost suspected that.


> I'm getting ready to make a 3.4.2 release (just bug fixes) for the
> sake of a stable XFree86 4.1 release.  But for the stand-alone 3.4.2
> release I wanted to fix this configure problem.
> 
> If you could port your changes from the Mesa trunk to the mesa_3_4_branch
> branch that would be great!
> 
> Would you also please double check that the help messages printed with
> ./configure --help consistently use yes/no instead of on/off?  I think
> that's still a problem.

OK, all done!


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 ]

Re: [Mesa3d-dev] xlock's glplanet

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

From:	SMTP%"ke...@va..." 15-MAY-2001 14:57:16.03
To:	"Jacob (=Jouk) Jansen" <jo...@hr...>
CC:	
Subj:	Re: [Mesa3d-dev] xlock's glplanet

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi all,
> 
> Finally I got the glplanet mode in xlockmore running on my VMS machine.
> I made a small change to t_imm_fixup.c (see below). It is a rather "ad hoc"
> fix, since it only corrects the "flag" when it is used and not in the
> location where it should be initialized. Therefore, I do not know if this is
> the only place that may cause problems. This is the reason why I did not
> (yet) have committed the patch. I first want your reaction.
> 
>                 Jouk
> 
> ************
> File $DISK2:[JOUKJ.PUBLIC.MESAGL.MESAGL.MESA.SRC.TNL]T_IMM_FIXUP.C;3
>   842         COPY_4FV( IM->Color[start], ctx->Current.Color);
>   843         IM->Flag[ IM->LastData+1 ] |= VERT_END_VB;
>   844         fixup_first_4f( IM->Color, IM->Flag, VERT_END_VB, start,
> ******
> File $DISK2:[JOUKJ.PUBLIC.MESAGL.MESAGL.MESA.SRC.TNL]T_IMM_FIXUP.C;2
>   842         COPY_4FV( IM->Color[start], ctx->Current.Color);
>   843         fixup_first_4f( IM->Color, IM->Flag, VERT_END_VB, start,
> ************

OK I'll look at where this is coming from.

Keith
================== RFC 822 Headers ==================
Return-Path: ke...@va...
Received: from mail.valinux.com (198.186.202.175)
	 by dutsm1205.stm.tudelft.nl (V5.1-15D, OpenVMS V7.2-1 Alpha);
	Tue, 15 May 2001 14:57:11 +0200 (MET_DST)
Received: from async4-18.nas.onetel.net.uk ([212.67.114.4] helo=valinux.com)
	by mail.valinux.com with asmtp 
	(Cipher SSLv3:EXP1024-RC4-SHA:128) (Exim 3.22 #1 (Debian))
	id 14zeNv-0000Qj-00; Tue, 15 May 2001 05:57:08 -0700
Sender: keithw
Message-ID: <3B0...@va...>
Date: Tue, 15 May 2001 06:59:17 -0600
From: Keith Whitwell <ke...@va...>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Jacob (=Jouk) Jansen" <jo...@hr...>
CC: MES...@li...
Subject: Re: [Mesa3d-dev] xlock's glplanet
References: <010...@hr...>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-RBL-Warning: (dialups.mail-abuse.org) See <URL:http://mail-abuse.org/dul/>


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] Mesa autoconf problem

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

"Sven M. Hallberg" wrote:
> 
> On Mon, May 14, 2001 at 01:12:16PM -0600, Brian Paul wrote:
> >
> > I'm trying to understand an autoconf problem and am looking for some
> > answers and/or advice.
> >
> > Mesa bug 423843 is as follows:
> >
> >                  When specified --enable-x86 in command line (in my
> >                  case, on Am486 processor I doesn't want to build MMX
> >                  support) I don't have compiling of any assembler source
> >                  in src/X86.
> >
> >                  In configure script there are lines to check whether
> >                  binutils support cpuid but where we check if have_x86
> >                  variable has "on" value.
> >                  But if I specify --enable-x86 in command line value
> >                  have_x86 variable has "yes" of "no" value, not "on" or
> >                  "off".
> >
> >                  Small workaround patch:
> >                  *** configure.old Thu Feb 8 05:27:38 2001
> >                  --- configure Mon May 14 11:27:51 2001
> >                  *************** esac
> >                  *** 2684,2689 ****
> >                  --- 2684,2694 ----
> >                  if test "${enable_x86+set}" = set; then
> >                  enableval="$enable_x86"
> >                  have_x86=$enableval
> >                  + if test "x$have_x86" = xyes; then
> >                  + have_x86=on
> >                  + else
> >                  + have_x86=off
> >                  + fi
> >                  fi
> >
> >                  if test "x$have_x86" = xon; then
> >
> >
> > The basic issue is this: should boolean configuration variables use
> > the values "yes/no" or "on/off"?  There doesn't seem to be any consistency
> > to this.
> >
> > If --enable-x86 is specified to configure, $enable_x86 and $have_x86
> > are set to "yes".  But $have_x86 is tested for "on" in several places
> > in the configure script.  Something's wrong.
> >
> > Is there any reason why "yes/no" shouldn't be used everywhere?
> 
> Are you looking at the right configure.in? As far as I can see yes/no is
> consistently used in the latest revision (1.53). I think I can actually
> remember stumbling across the yesno/onoff issue myself and cleaning it up.

I should have clarified that I'm looking at the mesa_3_4_branch, not
the trunk.

I'm getting ready to make a 3.4.2 release (just bug fixes) for the
sake of a stable XFree86 4.1 release.  But for the stand-alone 3.4.2
release I wanted to fix this configure problem.

If you could port your changes from the Mesa trunk to the mesa_3_4_branch
branch that would be great!

Would you also please double check that the help messages printed with
./configure --help consistently use yes/no instead of on/off?  I think
that's still a problem.

-Brian

Re: [Mesa3d-dev] xlock's glplanet

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

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi all,
> 
> Finally I got the glplanet mode in xlockmore running on my VMS machine.
> I made a small change to t_imm_fixup.c (see below). It is a rather "ad hoc"
> fix, since it only corrects the "flag" when it is used and not in the
> location where it should be initialized. Therefore, I do not know if this is
> the only place that may cause problems. This is the reason why I did not
> (yet) have committed the patch. I first want your reaction.
> 
>                 Jouk
> 
> ************
> File $DISK2:[JOUKJ.PUBLIC.MESAGL.MESAGL.MESA.SRC.TNL]T_IMM_FIXUP.C;3
>   842         COPY_4FV( IM->Color[start], ctx->Current.Color);
>   843         IM->Flag[ IM->LastData+1 ] |= VERT_END_VB;
>   844         fixup_first_4f( IM->Color, IM->Flag, VERT_END_VB, start,
> ******
> File $DISK2:[JOUKJ.PUBLIC.MESAGL.MESAGL.MESA.SRC.TNL]T_IMM_FIXUP.C;2
>   842         COPY_4FV( IM->Color[start], ctx->Current.Color);
>   843         fixup_first_4f( IM->Color, IM->Flag, VERT_END_VB, start,
> ************

OK I'll look at where this is coming from.

Keith

[Mesa3d-dev] xlock's glplanet

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

Hi all,

Finally I got the glplanet mode in xlockmore running on my VMS machine.
I made a small change to t_imm_fixup.c (see below). It is a rather "ad hoc"
fix, since it only corrects the "flag" when it is used and not in the
location where it should be initialized. Therefore, I do not know if this is
the only place that may cause problems. This is the reason why I did not
(yet) have committed the patch. I first want your reaction.

                Jouk




************
File $DISK2:[JOUKJ.PUBLIC.MESAGL.MESAGL.MESA.SRC.TNL]T_IMM_FIXUP.C;3
  842         COPY_4FV( IM->Color[start], ctx->Current.Color);
  843         IM->Flag[ IM->LastData+1 ] |= VERT_END_VB;
  844         fixup_first_4f( IM->Color, IM->Flag, VERT_END_VB, start, 
******
File $DISK2:[JOUKJ.PUBLIC.MESAGL.MESAGL.MESA.SRC.TNL]T_IMM_FIXUP.C;2
  842         COPY_4FV( IM->Color[start], ctx->Current.Color);   
  843         fixup_first_4f( IM->Color, IM->Flag, VERT_END_VB, start, 
************

Number of difference sections found: 1
Number of difference records found: 2

DIFFERENCES /IGNORE=()/MERGED=1/OUTPUT=$DISK2:[JOUKJ.PUBLIC.MESAGL.MESAGL.MESA.SRC.TNL]MAIL.TXT;1-
    $DISK2:[JOUKJ.PUBLIC.MESAGL.MESAGL.MESA.SRC.TNL]T_IMM_FIXUP.C;3-
    $DISK2:[JOUKJ.PUBLIC.MESAGL.MESAGL.MESA.SRC.TNL]T_IMM_FIXUP.C;2


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] Mesa autoconf problem

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

On Mon, May 14, 2001 at 01:12:16PM -0600, Brian Paul wrote:
> 
> I'm trying to understand an autoconf problem and am looking for some
> answers and/or advice.
> 
> Mesa bug 423843 is as follows:
> 
>                  When specified --enable-x86 in command line (in my 
>                  case, on Am486 processor I doesn't want to build MMX 
>                  support) I don't have compiling of any assembler source 
>                  in src/X86. 
> 
>                  In configure script there are lines to check whether 
>                  binutils support cpuid but where we check if have_x86 
>                  variable has "on" value. 
>                  But if I specify --enable-x86 in command line value 
>                  have_x86 variable has "yes" of "no" value, not "on" or 
>                  "off". 
> 
>                  Small workaround patch: 
>                  *** configure.old Thu Feb 8 05:27:38 2001 
>                  --- configure Mon May 14 11:27:51 2001 
>                  *************** esac 
>                  *** 2684,2689 **** 
>                  --- 2684,2694 ---- 
>                  if test "${enable_x86+set}" = set; then 
>                  enableval="$enable_x86" 
>                  have_x86=$enableval 
>                  + if test "x$have_x86" = xyes; then 
>                  + have_x86=on 
>                  + else 
>                  + have_x86=off 
>                  + fi 
>                  fi 
> 
>                  if test "x$have_x86" = xon; then 
> 
> 
> The basic issue is this: should boolean configuration variables use
> the values "yes/no" or "on/off"?  There doesn't seem to be any consistency
> to this.
> 
> If --enable-x86 is specified to configure, $enable_x86 and $have_x86
> are set to "yes".  But $have_x86 is tested for "on" in several places
> in the configure script.  Something's wrong.
> 
> Is there any reason why "yes/no" shouldn't be used everywhere?

Are you looking at the right configure.in? As far as I can see yes/no is
consistently used in the latest revision (1.53). I think I can actually
remember stumbling across the yesno/onoff issue myself and cleaning it up.

-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] Mesa autoconf problem

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

I'm trying to understand an autoconf problem and am looking for some
answers and/or advice.

Mesa bug 423843 is as follows:

                 When specified --enable-x86 in command line (in my 
                 case, on Am486 processor I doesn't want to build MMX 
                 support) I don't have compiling of any assembler source 
                 in src/X86. 

                 In configure script there are lines to check whether 
                 binutils support cpuid but where we check if have_x86 
                 variable has "on" value. 
                 But if I specify --enable-x86 in command line value 
                 have_x86 variable has "yes" of "no" value, not "on" or 
                 "off". 

                 Small workaround patch: 
                 *** configure.old Thu Feb 8 05:27:38 2001 
                 --- configure Mon May 14 11:27:51 2001 
                 *************** esac 
                 *** 2684,2689 **** 
                 --- 2684,2694 ---- 
                 if test "${enable_x86+set}" = set; then 
                 enableval="$enable_x86" 
                 have_x86=$enableval 
                 + if test "x$have_x86" = xyes; then 
                 + have_x86=on 
                 + else 
                 + have_x86=off 
                 + fi 
                 fi 

                 if test "x$have_x86" = xon; then 


The basic issue is this: should boolean configuration variables use
the values "yes/no" or "on/off"?  There doesn't seem to be any consistency
to this.

If --enable-x86 is specified to configure, $enable_x86 and $have_x86
are set to "yes".  But $have_x86 is tested for "on" in several places
in the configure script.  Something's wrong.

Is there any reason why "yes/no" shouldn't be used everywhere?

-Brian

Re: [Mesa3d-dev] IFLOOR(1.99999) == 2

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

Josh Vanderhoof wrote:
> 
> The current IFLOOR/ICEIL gets the wrong answer on .99999 + any odd
> integer.
> 
> Here are some better routines.  IFLOOR_4M and ICEIL_4M are 70% faster
> but have less range.
> 
> Josh
> 
> /*
>  Use fast rounding mode and correct result afterward.
> */
> static inline int
> IFLOOR(float f)
> {
>         int i = IROUND(f);
> 
>         return (i > f) ? i - 1 : i;
> }
> 
> /*
>  IEEE floor for computers that round to nearest or even.
> 
>  'f' must be between -4194304 and 4194303.
> 
>  This floor operation is done by "(iround(f + .5) + iround(f - .5)) >> 1",
>  but uses some IEEE specific tricks for better speed.
> */
> static inline int
> IFLOOR_4M(float f)
> {
>         int ai, bi;
>         double af, bf;
> 
>         af = (3 << 22) + 0.5 + (double)f;
>         bf = (3 << 22) + 0.5 - (double)f;
> 
> #if defined(__GNUC__) && defined(__i386__)
>         /*
>          GCC generates an extra fstp/fld without this.
>         */
>         asm ("fstps %0" : "=m" (ai) : "t" (af) : "st");
>         asm ("fstps %0" : "=m" (bi) : "t" (bf) : "st");
> #else
>         {
>                 union { int i; float f; } u;
>                 u.f = af; ai = u.i;
>                 u.f = bf; bi = u.i;
>         }
> #endif
> 
>         return (ai - bi) >> 1;
> }
> 
> /*
>  Use fast rounding mode and correct result afterward.
> */
> static inline int
> ICEIL(float f)
> {
>         int i = IROUND(f);
> 
>         return (i < f) ? i + 1 : i;
> }
> 
> /*
>  IEEE ceil for computers that round to nearest or even.
> 
>  'f' must be between -4194304 and 4194303.
> 
>  This ceil operation is done by "(iround(f + .5) + iround(f - .5) + 1) >> 1",
>  but uses some IEEE specific tricks for better speed.
> */
> static inline int
> ICEIL_4M(float f)
> {
>         int ai, bi;
>         double af, bf;
> 
>         af = (3 << 22) + 0.5 + (double)f;
>         bf = (3 << 22) + 0.5 - (double)f;
> 
> #if defined(__GNUC__) && defined(__i386__)
>         /*
>          GCC generates an extra fstp/fld without this.
>         */
>         asm ("fstps %0" : "=m" (ai) : "t" (af) : "st");
>         asm ("fstps %0" : "=m" (bi) : "t" (bf) : "st");
> #else
>         {
>                 union { int i; float f; } u;
>                 u.f = af; ai = u.i;
>                 u.f = bf; bi = u.i;
>         }
> #endif
> 
>         return (ai - bi + 1) >> 1;
> }
> 


Thanks, Josh.  I was having some trouble with the IFLOOR macro in the
s/w texturing routines a while back.  The tests/texwrap program sometimes
exhibited bands of mis-weighted pixels during GL_LINEAR filtering because
of this.


-Brian

[Mesa3d-dev] IFLOOR(1.99999) == 2

[Josh V. <ho...@na...>]

The current IFLOOR/ICEIL gets the wrong answer on .99999 + any odd
integer.

Here are some better routines.  IFLOOR_4M and ICEIL_4M are 70% faster
but have less range.

Josh


/*
 Use fast rounding mode and correct result afterward.
*/
static inline int
IFLOOR(float f)
{
	int i = IROUND(f);

	return (i > f) ? i - 1 : i;
}

/*
 IEEE floor for computers that round to nearest or even.

 'f' must be between -4194304 and 4194303.

 This floor operation is done by "(iround(f + .5) + iround(f - .5)) >> 1",
 but uses some IEEE specific tricks for better speed.
*/
static inline int
IFLOOR_4M(float f)
{
	int ai, bi;
	double af, bf;

	af = (3 << 22) + 0.5 + (double)f;
	bf = (3 << 22) + 0.5 - (double)f;

#if defined(__GNUC__) && defined(__i386__)
	/*
	 GCC generates an extra fstp/fld without this.
	*/
	asm ("fstps %0" : "=m" (ai) : "t" (af) : "st");
	asm ("fstps %0" : "=m" (bi) : "t" (bf) : "st");
#else
	{
		union { int i; float f; } u;
		u.f = af; ai = u.i;
		u.f = bf; bi = u.i;
	}
#endif

	return (ai - bi) >> 1;
}

/*
 Use fast rounding mode and correct result afterward.
*/
static inline int
ICEIL(float f)
{
	int i = IROUND(f);

	return (i < f) ? i + 1 : i;
}

/*
 IEEE ceil for computers that round to nearest or even.

 'f' must be between -4194304 and 4194303.

 This ceil operation is done by "(iround(f + .5) + iround(f - .5) + 1) >> 1",
 but uses some IEEE specific tricks for better speed.
*/
static inline int
ICEIL_4M(float f)
{
	int ai, bi;
	double af, bf;

	af = (3 << 22) + 0.5 + (double)f;
	bf = (3 << 22) + 0.5 - (double)f;

#if defined(__GNUC__) && defined(__i386__)
	/*
	 GCC generates an extra fstp/fld without this.
	*/
	asm ("fstps %0" : "=m" (ai) : "t" (af) : "st");
	asm ("fstps %0" : "=m" (bi) : "t" (bf) : "st");
#else
	{
		union { int i; float f; } u;
		u.f = af; ai = u.i;
		u.f = bf; bi = u.i;
	}
#endif

	return (ai - bi + 1) >> 1;
}

Re: [Mesa3d-dev] problems with current CVS

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

Hi all,

I pick up some old thread of my own since the problem is not yet solved
I got some new debugging info which I do not understand.

br...@va... wrote 3-MAY-2001 17:08:04.24
>"Jacob (=Jouk) Jansen" wrote:
>> 
>> On My OpenVMS system I see the following prblems when testing Mesa3d from
>> the CVS with the xlockmore program (get the latest beta version from:
>> ftp://ftp.tux.org./pub/tux/bagleyd/xlockmore/ )
>> 
>>       -version from 27 April 2001 gives no problems at all
>>       -version from 1 May and 3 May give problems (new tnl routines????):
>>           -glplanet crashes due to access violation
>>              (is everything allocated????)
>
>It seems OK here.  Does it crash immediately or after it's been running
>for a while?

When invoking the debugger I came up with the following (referring to the CVS
version of May 11).

  error occurs in fixup_first_4f
     called from : _tnl_upgrade_current_data
                   _swsetup_RenderStart
		   run_render
		   _tnl_run_pipeline
		   _tnl_run_casette
		   execute_compiled_casette
		   ....etc.
		   
  in fixup_first_4f I get the following parmeters
     start : 3
     i : 17068   which is actually too high such that data[i] gives
                 the access violation
     match : 33554432     (0x2000000 = VERT_END_VB )
     flag[j] = 0  for j=0..255
     flag[j] = 16512 for j>255
     
  Actually the wile loop never stops since the condition flag[i]&match is
   always 0. My guess is that the flags are not correctly initialized, but
   where????
   
   
  If you need more debugging info, I always can try to get them.
   
                   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] Hierachical Display List

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

Your fixed worked great for all of my C test cases. I wish my full C++
code worked as well:-( I guess I'll see what I can do for a simple test
case.

Thanks,
Allen

Keith Whitwell wrote:
> 
> Allen Barnett wrote:
> > So, here is my problem code reduced to a simple GLUT program. Basically,
> > I'm creating two display lists which contain only the geometry of a
> > polygon, one to display the edge and the other for the filled interior.
> > I then create another display list which sets an edge color, calls the
> > display list for the edge, sets an interior color and calls the display
> > list for the filled polygon. The redraw function just calls the combined
> > display list.
> 
> I've committed a fix for this to 3.5.  Let me know how it goes.
> 
> Keith

Re: [Mesa3d-dev] X renderer speedup (write_span_mono_pixmap optimization)

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

Jeff Epler wrote:
> 
> I tried Keith's code this morning.  It appears to be the same speed
> as my original code.
> 
> I wanted to verify that it gives the same results as the old code, but
> chose a rather low-tech way to do it -- grab a screenshot with gimp from
> each version, and use the "difference" mode to find any differences.
> 
> The version I first compared against was actually Mesa 3.2-2 from
> RedHat 6.2, and I noticed something weird -- The background was
> cleared to RGB (0,4,0) rather than (0,0,0) in 3.4.1 + patch.  Is
> this just a bug that was fixed in the meantime?  When I compare
> 3.4.1 vs 3.4.1 + patch, the results are identical in all pixels.
> 
> One question -- if we use a Mesa with this patch in XFree86 4.0 glx,
> will the optimization apply when not using hardware acceleration?
> 

Note that the 'write_all' optimization higher up in the function is now
redundant as well.

Keith

Re: [Mesa3d-dev] X renderer speedup (write_span_mono_pixmap optimization)

[Jeff E. <je...@ds...>]

On Thu, May 10, 2001 at 08:22:04AM -0600, Brian Paul wrote:
> > The version I first compared against was actually Mesa 3.2-2 from
> > RedHat 6.2, and I noticed something weird -- The background was
> > cleared to RGB (0,4,0) rather than (0,0,0) in 3.4.1 + patch.  Is
> > this just a bug that was fixed in the meantime?
> 
> What is your glClearColor() and what depth is your rendering window?
> I seem to recall making a change to clear color months ago but I
> don't remember the details.

16 bit (RGB 565), and glClearColor(0.0, 0.0, 0.0, 0.0)

This isn't important, since it looks fixed, and I never even noticed the
problem visually.  I'm guessing that it happened around the time that a
change to xmesa1.c was committed with the log message
	Pass pixel format to xmesa_color_to_pixel().  Compute clearpixel
	without dither
since this certainly touches that area .. 

Jeff

Re: [Mesa3d-dev] X renderer speedup (write_span_mono_pixmap optimization)

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

Jeff Epler wrote:
> 
> I tried Keith's code this morning.  It appears to be the same speed
> as my original code.
> 
> I wanted to verify that it gives the same results as the old code, but
> chose a rather low-tech way to do it -- grab a screenshot with gimp from
> each version, and use the "difference" mode to find any differences.
> 
> The version I first compared against was actually Mesa 3.2-2 from
> RedHat 6.2, and I noticed something weird -- The background was
> cleared to RGB (0,4,0) rather than (0,0,0) in 3.4.1 + patch.  Is
> this just a bug that was fixed in the meantime?

What is your glClearColor() and what depth is your rendering window?
I seem to recall making a change to clear color months ago but I
don't remember the details.


> When I compare
> 3.4.1 vs 3.4.1 + patch, the results are identical in all pixels.

OK, I'll apply Keith's version of the patch.


> One question -- if we use a Mesa with this patch in XFree86 4.0 glx,
> will the optimization apply when not using hardware acceleration?

Yes.  The indirect GLX renderer will also benefit from this.

-Brian

Re: [Mesa3d-dev] X renderer speedup (write_span_mono_pixmap optimization)

[Jeff E. <je...@ds...>]

I tried Keith's code this morning.  It appears to be the same speed 
as my original code.

I wanted to verify that it gives the same results as the old code, but
chose a rather low-tech way to do it -- grab a screenshot with gimp from
each version, and use the "difference" mode to find any differences.

The version I first compared against was actually Mesa 3.2-2 from
RedHat 6.2, and I noticed something weird -- The background was
cleared to RGB (0,4,0) rather than (0,0,0) in 3.4.1 + patch.  Is
this just a bug that was fixed in the meantime?  When I compare
3.4.1 vs 3.4.1 + patch, the results are identical in all pixels.

One question -- if we use a Mesa with this patch in XFree86 4.0 glx,
will the optimization apply when not using hardware acceleration?

Jeff

Re: [Mesa3d-dev] X renderer speedup (write_span_mono_pixmap optimization)

[Jeff E. <je...@us...>]

> Jeff Epler wrote:
> > Would you like to incorporate the patch as-is, or incorporate modified
> > logic as Keith has suggested?
> 
Brian Paul wrote:
> Keith's looked a little cleaner.  Did you test it?

No, I didn't get a chance today.  I hope to test it tomorrow morning.
If it were my code, I'd have written a fencepost error in just to make
sure I had something to debug.

> > Another modification you might want before inclusion is a way to switch
> > back to the old per-pixel code when it's appropriate, such as when drawing
> > with a 50% stipple.  (The code as submitted draws this ~20% slower than
> > 3.4.1 in my test app, IIRC)
> 
> I might just #ifdef-out the old code but leave it there.  I think
> the Z buffer scenario you're using is more typical than the 50% stipple
> scenario.

I have the same suspicion, but wanted to include this information for
completeness.

Jeff
-- 

Re: [Mesa3d-dev] X renderer speedup (write_span_mono_pixmap optimization)

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

Jeff Epler wrote:
> 
> Jeff Epler wrote:
> > > This patch accumulates consecutive "drawn" pixels into a single
> > > XMesaFillRectangle call.  [...]
> 
> On Wed, May 09, 2001 at 09:00:38AM -0600, Brian Paul wrote:
> > Sending small patches to this list is fine.  Larger patches should
> > be filed on SF.
> >
> > I'll look this over and probably apply it soon.  Thanks!
> 
> Would you like to incorporate the patch as-is, or incorporate modified
> logic as Keith has suggested?

Keith's looked a little cleaner.  Did you test it?


> Another modification you might want before inclusion is a way to switch
> back to the old per-pixel code when it's appropriate, such as when drawing
> with a 50% stipple.  (The code as submitted draws this ~20% slower than
> 3.4.1 in my test app, IIRC)

I might just #ifdef-out the old code but leave it there.  I think
the Z buffer scenario you're using is more typical than the 50% stipple
scenario.

-Brian

Re: [Mesa3d-dev] X renderer speedup (write_span_mono_pixmap optimization)

[Jeff E. <je...@us...>]

Jeff Epler wrote:
> > This patch accumulates consecutive "drawn" pixels into a single
> > XMesaFillRectangle call.  [...]

On Wed, May 09, 2001 at 09:00:38AM -0600, Brian Paul wrote:
> Sending small patches to this list is fine.  Larger patches should
> be filed on SF.
> 
> I'll look this over and probably apply it soon.  Thanks!

Would you like to incorporate the patch as-is, or incorporate modified
logic as Keith has suggested?

Another modification you might want before inclusion is a way to switch
back to the old per-pixel code when it's appropriate, such as when drawing
with a 50% stipple.  (The code as submitted draws this ~20% slower than
3.4.1 in my test app, IIRC)

Jeff

Re: [Mesa3d-dev] X renderer speedup (write_span_mono_pixmap optimization)

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

Jeff Epler wrote:
> 
> I'm currently trying to move an older piece of software from using
> PEX/X11 to Mesa/X11.  (We use(d) a modified version of PEX with zbuffer
> support, and it's becoming too much of a chore to propogate these
> patches to new versions of XFree86)
> 
> Our software draws exclusively flat-shaded, zbuffered polygons.
> 
> Out of the box (Mesa 3.2/RedHat 6.2) or using Mesa 3.4.1, the Mesa
> renderer is rather slower than our PEX-based renderer.  However, a
> simple change to write_span_mono_pixmap brings the two renderers to
> nearly equal speed.
> 
> Basically, we discovered in past iterations of software renderers that
> coalescing as many pixels as possible into single X calls is a very
> important optimization (in fact, another dead renderer actually unifies
> multiple single-color spans into a single XDrawSegments call).
> write_span_mono_pixmap performs this optimization using
> XMesaFillRectangle when no pixels in the span were excluded (due to
> depth check or other factors)
> 
> However, if any pixels were excluded, then it falls back to
> XMesaDrawPoint for all points.
> 
> This patch accumulates consecutive "drawn" pixels into a single
> XMesaFillRectangle call.  This is a big speed boost in our application,
> and a slight pessimization in the case of e.g., a 50% stipple.
> (XFillRectangle is likely to be optimized for the 1x1 case, as well as
> the Nx1 case)  A slightly more intelligent patch would probably
> disable the optimization for very short spans, or spans with large
> numbers of sub-spans.
> 
> I'll include the patch in my message.  Is submitting it to the
> sourceforge patch tracker appropriate?  It doesn't look like that SF
> feature is well-used.

Sending small patches to this list is fine.  Larger patches should
be filed on SF.

I'll look this over and probably apply it soon.  Thanks!

-Brian

Re: [Mesa3d-dev] X renderer speedup (write_span_mono_pixmap optimization)

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

How about this as a cleaner (untested) version of the loop:

      for (i = 0 ; i < n ;) {
	 GLuint start = i;

	 /* Identify and emit contiguous rendered pixels 
	  */
	 for( ; i < n && mask[i]; i++)
	    ;

	 if (start < i) 
	    XMesaFillRectangle( dpy, buffer, gc, 
				(int)(x+start), (int) y, 
				(int)(i-start), 1);

	 /* Eat up non-rendered pixels
	  */
	 for( ; i < n && !mask[i]; i++)
	    ;
      }


Keith

Re: [Mesa3d-dev] Hierachical Display List

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

Allen Barnett wrote:
> 
> Hi (yet again),
> 
> (Thanks Keith and Brian for your earlier responses.)
> 
> So, here is my problem code reduced to a simple GLUT program. Basically,
> I'm creating two display lists which contain only the geometry of a
> polygon, one to display the edge and the other for the filled interior.
> I then create another display list which sets an edge color, calls the
> display list for the edge, sets an interior color and calls the display
> list for the filled polygon. The redraw function just calls the combined
> display list.
> 
> This works OK with XFree86 DRI using the TDFX driver and with XFree86
> with LIBGL_ALWAYS_INDIRECT set; you get a blue triangle with a red edge.
> With the latest CVS version of Mesa, however, when the window is opened
> you only see a white triangle. Causing a refresh in the window yields a
> blue triangle but with no red edge (but I think it's drawing the edge in
> blue). [This is using the KDE window manager, if that matters.]
> 
> I also see a little empty space between the diagonal edge of the filled
> polygon and its edge when using either version of the software rendering
> (indirect DRI or Mesa). I've tweaked PolygonOffset several ways, but
> can't see to make it go away.
> 
> I await to be corrected :-)
> 
> Thanks,
> Allen

I've committed a fix for this to 3.5.  Let me know how it goes.

Keith

[Mesa3d-dev] Libtool trouble -- MesaGGI

[Filip S. <sp...@ge...>]

Hello,

I have recently attempted to compile Mesa 3.4.1 with GGI support and
while the compilation itself went smoothy, there were some issues with
linking.

The resulting library should obviously be linked with libggi. The
libggi package on a debian/woody system comes with the libggi.la
libtool convenience library and thus the libtool in Mesa build system
prefers it over the bare libggi.so. The file libggi.la is then added
as a dependency to the libMesaGGI.la convenience library created in
src/GGI. The problem comes during the final linking of the libGL.so
library. libtool correctly pulls the dependencies from all the
convenience libraries, but it fails to process them again. Thus, it
passes /usr/lib/libggi.la to the linker instead of processing this
file and passing the correct /usr/lib/libggi.so.

From ltmain.sh, I see you are using libtool 1.3c (2000/03/29) for the
distribution. I have tried using the (recently released) libtool 1.4
and the above problem seems to be gone. However the 1.4 version of
libtool introduces a new feature where it actually does sanity checks
on the version of the library, and it does not consider 030401 a valid
version number (it can either be a single digit 0, or at most a 3
digit number not starting by a 0). Therefore simply replacing the
libtool in the distribution is not an option. The correct solution
would probably be to fix libtool's concept of a version number, but
that will probably take a while.

So I don't actually have a solution. New version of libtool definitely
is needed, however the current newest one won't work with the current
version numbering. Maybe there might be some versions in between 1.3c
and the newest release.

I hope somebody here knows what would be the best thing to do.

BTW: for those who are impatient and want Mesa with GGI support,
simply removing /usr/lib/libggi.la does the trick.

-Filip

[Mesa3d-dev] X renderer speedup (write_span_mono_pixmap optimization)

[Jeff E. <je...@ds...>]

I'm currently trying to move an older piece of software from using
PEX/X11 to Mesa/X11.  (We use(d) a modified version of PEX with zbuffer
support, and it's becoming too much of a chore to propogate these
patches to new versions of XFree86)

Our software draws exclusively flat-shaded, zbuffered polygons.

Out of the box (Mesa 3.2/RedHat 6.2) or using Mesa 3.4.1, the Mesa
renderer is rather slower than our PEX-based renderer.  However, a
simple change to write_span_mono_pixmap brings the two renderers to
nearly equal speed.  

Basically, we discovered in past iterations of software renderers that
coalescing as many pixels as possible into single X calls is a very
important optimization (in fact, another dead renderer actually unifies
multiple single-color spans into a single XDrawSegments call).
write_span_mono_pixmap performs this optimization using
XMesaFillRectangle when no pixels in the span were excluded (due to
depth check or other factors)

However, if any pixels were excluded, then it falls back to
XMesaDrawPoint for all points.

This patch accumulates consecutive "drawn" pixels into a single
XMesaFillRectangle call.  This is a big speed boost in our application,
and a slight pessimization in the case of e.g., a 50% stipple.
(XFillRectangle is likely to be optimized for the 1x1 case, as well as
the Nx1 case)  A slightly more intelligent patch would probably
disable the optimization for very short spans, or spans with large
numbers of sub-spans.

I'll include the patch in my message.  Is submitting it to the
sourceforge patch tracker appropriate?  It doesn't look like that SF
feature is well-used.

Jeff

[Mesa3d-dev] Re: problems with current CVS

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

I wrote yesterday:
>On My OpenVMS system I see the following prblems when testing Mesa3d from
>the CVS with the xlockmore program (get the latest beta version from:
>ftp://ftp.tux.org./pub/tux/bagleyd/xlockmore/ )
>
>      -version from 27 April 2001 gives no problems at all
>      -version from 1 May and 3 May give problems (new tnl routines????):
>          -glplanet crashes due to access violation
>	     (is everything allocated????)
 This problem is still there. glplanet crashes immediately after the start
before displaying anything.
 Now tested with xlockmore5.01, which is just released.
 
>           -moebius does not display anything and seems to be in an infinite
>	    loop.
 This problem is solved.
	    
	  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] problems with current CVS

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

br...@va... wrote 3-MAY-2001 17:08:04.24
>"Jacob (=Jouk) Jansen" wrote:
>> 
>> On My OpenVMS system I see the following prblems when testing Mesa3d from
>> the CVS with the xlockmore program (get the latest beta version from:
>> ftp://ftp.tux.org./pub/tux/bagleyd/xlockmore/ )
>> 
>>       -version from 27 April 2001 gives no problems at all
>>       -version from 1 May and 3 May give problems (new tnl routines????):
>>           -glplanet crashes due to access violation
>>              (is everything allocated????)
>
>It seems OK here.  Does it crash immediately or after it's been running
>for a while?
immediately even before displaying anything. I know that VMS is a little more
picky on uninitialized pointers than unix. The error message indicates in
this direction. I'll try today's CVS to see if the problem is still there

                      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

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