mesa3d-dev

Re: [Mesa3d-dev] teximage.c

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

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 ||
?????
because texImage is fetched after this statement.

                    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] teximage.c

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

From:	SMTP%"br...@va..." 13-NOV-2000 08:41:11.07
To:	"Jacob (=Jouk) Jansen" <jo...@hr...>
CC:	MES...@li...
Subj:	Re: [Mesa3d-dev] teximage.c

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi all,
> 
> 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!

-Brian
_______________________________________________
Mesa3d-dev mailing list
Mes...@li...
http://lists.sourceforge.net/mailman/listinfo/mesa3d-dev
================== RFC 822 Headers ==================
Return-Path: mes...@li...
Received: from ns2.tudelft.nl (130.161.180.65)
	 by dutsm1120.stm.tudelft.nl (V5.0A-1F, OpenVMS V7.2-1 Alpha);
	Mon, 13 Nov 2000 08:35:56 +0100 (MET)
Received: from lists.sourceforge.net (mail1.sourceforge.net [198.186.203.35])
 by mailhost1.tudelft.nl (PMDF V5.2-33 #42432)
 with ESMTP id <0G3...@ma...> for
 jo...@hr...; Fri, 10 Nov 2000 22:16:42 +0100 (MET)
Received: from mail1.sourceforge.net (localhost [127.0.0.1])
	by lists.sourceforge.net (8.11.1/8.11.1) with ESMTP id eAAKhPu07025; Fri,
 10 Nov 2000 12:43:27 -0800
Received: from mail2.valinux.com (panoramix.valinux.com [198.186.202.147])
	by lists.sourceforge.net (8.11.1/8.11.1) with ESMTP id eAAJ9Vu00766	for
 <MES...@li...>; Fri, 10 Nov 2000 11:09:31 -0800
Received: from smtp-fwd.valinux.com ([198.186.202.196] helo=mail.valinux.com)
	by mail2.valinux.com with esmtp (Exim 3.16 #1 (Debian))
	id 13uGAg-0001aL-00	for <MES...@li...>; Fri,
 10 Nov 2000 07:32:54 -0800
Received: from jens2.cmn.net ([207.174.125.34] helo=valinux.com)
	by mail.valinux.com with esmtp (Exim 3.16 #1 (Debian))
	id 13uGAa-0002ND-00; Fri, 10 Nov 2000 07:32:49 -0800
Date: Fri, 10 Nov 2000 08:31:13 -0700
From: Brian Paul <br...@va...>
Subject: Re: [Mesa3d-dev] teximage.c
Sender: mes...@li...
To: "Jacob (=Jouk) Jansen" <jo...@hr...>
Cc: MES...@li...
Errors-to: mes...@li...
Message-id: <3A0...@va...>
Organization: VA Linux Systems, Inc.
MIME-version: 1.0
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Precedence: bulk
X-Accept-Language: en
X-BeenThere: mes...@li...
X-Mailman-Version: 2.0beta5
References: <001...@hr...>
List-Id: <mesa3d-dev.lists.sourceforge.net>


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] Help wanted

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

On Sat, Nov 11, 2000 at 01:19:49PM -0700, Brian Paul wrote:
> > > Here's a few items:
> > >
> > > 1. The files in Mesa/src/X86/ were changed and the configure script
> > > sometimes fails there.
> > >
> > > [...]
> > >
> > > There were more that I can't remember off-hand, and there's a
> > > few other issues in the Mesa bug database.
> > 
> > Can you compile a specific list of stuff you know of? I guess I'll take the
> > job and try to look into the issues next weekend.
> 
> I've updated the Mesa bug database with the latest problems.

Alright, I'll be on it as soon as I can.

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] Help wanted

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

"Sven M. Hallberg" wrote:
> 
> On Sat, Nov 11, 2000 at 11:01:23AM -0700, Brian Paul wrote:
> > "Sven M. Hallberg" wrote:
> > >
> > > On Fri, Nov 10, 2000 at 08:44:42AM -0700, Brian Paul wrote:
> > > >
> > > > I'm looking for volunteers to help out with some parts of the Mesa project:
> > > >
> > > > 1. GNU configure script maintainer:  I've been getting a lot of email
> > > >    from people having trouble with ./configure;make for a variety of
> > > >    reasons.  I don't have time to learn and maintain the configure
> > > >    scripts so I need someone to help out with that.  The original
> > > >    author of the configure scripts doesn't seem to have the time to
> > > >    maintain them.  If I don't get help, I'll have to remove them
> > > >    entirely.
> > >
> > > Can you outline the issues needing resolvement in the build system? I don't
> > > have too much time, but I would take the position of build system maintainer
> > > if nobody else would.
> >
> > Here's a few items:
> >
> > 1. The files in Mesa/src/X86/ were changed and the configure script
> > sometimes fails there.
> >
> > [...]
> >
> > There were more that I can't remember off-hand, and there's a
> > few other issues in the Mesa bug database.
> 
> Can you compile a specific list of stuff you know of? I guess I'll take the
> job and try to look into the issues next weekend.

I've updated the Mesa bug database with the latest problems.

-Brian

Re: [Mesa3d-dev] Help wanted

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

On Sat, Nov 11, 2000 at 11:01:23AM -0700, Brian Paul wrote:
> "Sven M. Hallberg" wrote:
> > 
> > On Fri, Nov 10, 2000 at 08:44:42AM -0700, Brian Paul wrote:
> > >
> > > I'm looking for volunteers to help out with some parts of the Mesa project:
> > >
> > > 1. GNU configure script maintainer:  I've been getting a lot of email
> > >    from people having trouble with ./configure;make for a variety of
> > >    reasons.  I don't have time to learn and maintain the configure
> > >    scripts so I need someone to help out with that.  The original
> > >    author of the configure scripts doesn't seem to have the time to
> > >    maintain them.  If I don't get help, I'll have to remove them
> > >    entirely.
> > 
> > Can you outline the issues needing resolvement in the build system? I don't
> > have too much time, but I would take the position of build system maintainer
> > if nobody else would.
> 
> Here's a few items:
> 
> 1. The files in Mesa/src/X86/ were changed and the configure script
> sometimes fails there.
> 
> [...]
> 
> There were more that I can't remember off-hand, and there's a
> few other issues in the Mesa bug database.

Can you compile a specific list of stuff you know of? I guess I'll take the
job and try to look into the issues next weekend.


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] Help wanted

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

"Sven M. Hallberg" wrote:
> 
> On Fri, Nov 10, 2000 at 08:44:42AM -0700, Brian Paul wrote:
> >
> > I'm looking for volunteers to help out with some parts of the Mesa project:
> >
> > 1. GNU configure script maintainer:  I've been getting a lot of email
> >    from people having trouble with ./configure;make for a variety of
> >    reasons.  I don't have time to learn and maintain the configure
> >    scripts so I need someone to help out with that.  The original
> >    author of the configure scripts doesn't seem to have the time to
> >    maintain them.  If I don't get help, I'll have to remove them
> >    entirely.
> 
> Can you outline the issues needing resolvement in the build system? I don't
> have too much time, but I would take the position of build system maintainer
> if nobody else would.

Here's a few items:

1. The files in Mesa/src/X86/ were changed and the configure script
sometimes fails there.

2. If the MesaDemos.tar file isn't unpacked with the MesaLib.tar
file then configure/make dies because of a GLUT problem.

There were more that I can't remember off-hand, and there's a
few other issues in the Mesa bug database.

-Brian

Re: [Mesa3d-dev] Help wanted

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

On Fri, Nov 10, 2000 at 08:44:42AM -0700, Brian Paul wrote:
> 
> I'm looking for volunteers to help out with some parts of the Mesa project:
> 
> 1. GNU configure script maintainer:  I've been getting a lot of email
>    from people having trouble with ./configure;make for a variety of
>    reasons.  I don't have time to learn and maintain the configure
>    scripts so I need someone to help out with that.  The original
>    author of the configure scripts doesn't seem to have the time to
>    maintain them.  If I don't get help, I'll have to remove them
>    entirely.

Can you outline the issues needing resolvement in the build system? I don't
have too much time, but I would take the position of build system maintainer
if nobody else would.


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] teximage.c

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

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi all,
> 
> 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!

-Brian

[Mesa3d-dev] Help wanted

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

I'm looking for volunteers to help out with some parts of the Mesa project:

1. GNU configure script maintainer:  I've been getting a lot of email
   from people having trouble with ./configure;make for a variety of
   reasons.  I don't have time to learn and maintain the configure
   scripts so I need someone to help out with that.  The original
   author of the configure scripts doesn't seem to have the time to
   maintain them.  If I don't get help, I'll have to remove them
   entirely.

2. Windows driver maintainer:  The Mesa Windows driver is out of date,
   as are the project/makefiles.  I don't use Windows but I'd appreciate
   someone spending a little time to get them up to date.

3. Website help:  C. J. Beyer has been a big help in maintaining the
   www.mesa3d.org website but he too is busy with other things now.
   I wouldn't mind an overhaul of the site to give it a new look.

Anyone who's interested in helping with these items should send me
email.

Thanks!

-Brian

[Mesa3d-dev] teximage.c

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

Hi all,

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???

              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] Points size in Mesa re-org

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

Brian Paul wrote:
> 
> I saw that in the GL_NV_vertex_program extension that point size is
> considered a vertex attribute which may be computed by a vertex program.
> 
> Keith, have you considered adding point size as a vertex attribute
> in SWvertex?

I'd been wondering how to handle attenuated points better - this looks like a
good way to do it.

> We could add pipeline/setup stages for computing point size when attenuation
> is enabled.
> 
> For rendering, we can check if point attenuation is enabled before
> rendering a vertex buffer and use grDrawVertexArray if attenuation
> is disabled and GL_POINT_SIZE == 1.
> 
> Otherwise, it should be easy to examine the point size for each
> vertex inside the point rendering functions.
> 
> Point attenutation might get more popular for particle system effects.

It is still a piece of work to implement on existing hardware, I think, but at
least doing this would put the mechanism in place.

Keith

Re: [Mesa3d-dev] Points size in Mesa re-org

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

Brian Paul wrote:
> 
> I saw that in the GL_NV_vertex_program extension that point size is
> considered a vertex attribute which may be computed by a vertex program.
> 
> Keith, have you considered adding point size as a vertex attribute
> in SWvertex?

I'd been wondering how to handle attenuated points better - this looks like a
good way to do it.

> We could add pipeline/setup stages for computing point size when attenuation
> is enabled.
> 
> For rendering, we can check if point attenuation is enabled before
> rendering a vertex buffer and use grDrawVertexArray if attenuation
> is disabled and GL_POINT_SIZE == 1.
> 
> Otherwise, it should be easy to examine the point size for each
> vertex inside the point rendering functions.
> 
> Point attenutation might get more popular for particle system effects.

It is still a piece of work to implement on existing hardware, I think, but at
least doing this would put the mechanism in place.

Keith

[Mesa3d-dev] Points size in Mesa re-org

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

I saw that in the GL_NV_vertex_program extension that point size is
considered a vertex attribute which may be computed by a vertex program.

Keith, have you considered adding point size as a vertex attribute
in SWvertex?

We could add pipeline/setup stages for computing point size when attenuation
is enabled.

For rendering, we can check if point attenuation is enabled before
rendering a vertex buffer and use grDrawVertexArray if attenuation
is disabled and GL_POINT_SIZE == 1.

Otherwise, it should be easy to examine the point size for each 
vertex inside the point rendering functions.

Point attenutation might get more popular for particle system effects.

-Brian

Re: [Mesa3d-dev] Fwd: problem with 'bootstrap' and 'src/Makefile.am'

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

Am Dienstag,  7. November 2000 18:02 schrieben Sie:
> Dieter Nützel wrote:
> > ----------  Weitergeleitete Nachricht  ----------
> > Subject: problem with 'bootstrap' and 'src/Makefile.am'
> > Date: Mon, 6 Nov 2000 19:10:17 +0100
> > From: Dieter Nützel <Die...@ha...>
> > To: Mesa-Bugs <mes...@me...>
> >
> > There is still an error in the 'src/Makefile.am' file.
> > The problem occurs when someone use the 'bootstrap' command.
> >
> > SunWave1>./bootstrap
> > src/Makefile.am:239: variable `THREAD_LIBS' not defined
> > src/Makefile.am:239: variable `THREAD_LIBS' not defined
> > src/Makefile.am:239: variable `THREAD_LIBS' not defined
> > src/Makefile.am:239: variable `THREAD_LIBS' not defined
> > src/Makefile.am:239: variable `THREAD_LIBS' not defined
> >
> > Solution:
> >
> > fix 'bootstrap' or 'src/Makefile.am'
> >
> > SunWave1>diff src/Makefile.am.Dieter src/Makefile.am
> > 240c240
> > <       $(DRV_SVGA) $(DRV_X11)
> > ---
> >
> > >       $(DRV_SVGA) $(DRV_X11) $(THREAD_LIBS)
>
> The configure scripts and Makefiles work for me as-is and nobody
> else has reported a problem like this.
>
> What sort of error are you getting?
>
As I descriped above.

SunWave1>./bootstrap
src/Makefile.am:239: variable `THREAD_LIBS' not defined
src/Makefile.am:239: variable `THREAD_LIBS' not defined
[snip]
>
> Maybe I'm missing a configure option?
>
No, not a configure option but during the 'configure' regeneration with 
'bootstrap'. But it could be that you do not see 'bootstrap' 'cause I moved 
it away for testing and it wouldn't be retransmitted from CVS.
Thomas Tanner did all this configure stuff, if I remember right.

-Dieter

Re: [Mesa3d-dev] Fwd: problem with 'bootstrap' and 'src/Makefile.am'

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

Dieter Nützel wrote:
> 
> ----------  Weitergeleitete Nachricht  ----------
> Subject: problem with 'bootstrap' and 'src/Makefile.am'
> Date: Mon, 6 Nov 2000 19:10:17 +0100
> From: Dieter Nützel <Die...@ha...>
> To: Mesa-Bugs <mes...@me...>
> 
> There is still an error in the 'src/Makefile.am' file.
> The problem occurs when someone use the 'bootstrap' command.
> 
> SunWave1>./bootstrap
> src/Makefile.am:239: variable `THREAD_LIBS' not defined
> src/Makefile.am:239: variable `THREAD_LIBS' not defined
> src/Makefile.am:239: variable `THREAD_LIBS' not defined
> src/Makefile.am:239: variable `THREAD_LIBS' not defined
> src/Makefile.am:239: variable `THREAD_LIBS' not defined
> 
> Solution:
> 
> fix 'bootstrap' or 'src/Makefile.am'
> 
> SunWave1>diff src/Makefile.am.Dieter src/Makefile.am
> 240c240
> <       $(DRV_SVGA) $(DRV_X11)
> ---
> 
> >       $(DRV_SVGA) $(DRV_X11) $(THREAD_LIBS)
> 

The configure scripts and Makefiles work for me as-is and nobody
else has reported a problem like this.

What sort of error are you getting?

Maybe I'm missing a configure option?

-Brian

[Mesa3d-dev] Fwd: problem with 'bootstrap' and 'src/Makefile.am'

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

----------  Weitergeleitete Nachricht  ----------
Subject: problem with 'bootstrap' and 'src/Makefile.am'
Date: Mon, 6 Nov 2000 19:10:17 +0100
From: Dieter Nützel <Die...@ha...>
To: Mesa-Bugs <mes...@me...>


There is still an error in the 'src/Makefile.am' file.
The problem occurs when someone use the 'bootstrap' command.

SunWave1>./bootstrap
src/Makefile.am:239: variable `THREAD_LIBS' not defined
src/Makefile.am:239: variable `THREAD_LIBS' not defined
src/Makefile.am:239: variable `THREAD_LIBS' not defined
src/Makefile.am:239: variable `THREAD_LIBS' not defined
src/Makefile.am:239: variable `THREAD_LIBS' not defined

Solution:

fix 'bootstrap' or 'src/Makefile.am'

SunWave1>diff src/Makefile.am.Dieter src/Makefile.am
240c240
<       $(DRV_SVGA) $(DRV_X11)
---

>       $(DRV_SVGA) $(DRV_X11) $(THREAD_LIBS)

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

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

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

-------------------------------------------------------

-- 
Dieter Nützel
Graduate Student, Computer Science

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

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

Re: [Mesa3d-dev] Latest changes

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

Keith Whitwell wrote:

> There are some old comments in vbrender.c about this.  I'm not entirely happy
> with the way I'm doing edgeflags yet -- the SI makes it look really simple by
> comparison.

Selection when polygonmode = point or line isn't working because
the edge flags are always zero.  Perhaps you can look into that.

-Brian

Re: [Mesa3d-dev] Latest changes

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

Keith Whitwell wrote:
> 
> Brian Paul wrote:
> >
> 
> >
> > How or where should we check for feedback and selection mode in
> > the point/line/triangle selection functions?  Should we test for
> > that down in the driver's code, or higher up in the _swrast_validate_point()
> > function?
> 
> Ahh..  I originally left the feedback/select point/line/tri functions up in
> the main directory.  In the last batch of changes I moved them down into
> swrast, but I forgot to update the _swrast_choose_line(), etc. functions. 
> The tests should be made there...
> 
> It'll be necessary to check the two drivers that extend swrast (x11, osmesa)
> to make sure that they respect rendermode in their chooser functions, too.


OK, I'm testing for feedback/selection in the XMesa driver now.
I had to tweak _swsetup_choose_rastersetup_func() as well.  As it
was, it was using a multi-texture setup function for selection/
feedback but the MULTITEX test in the setup function examines
the Texture._ReallyEnabled word.  In feedback mode, even if texture
is disabled you still have to return texture coords.
I'll check in my fix soon.

Selection mode with glPolygonMode(GL_POINT) isn't working yet.

-Brian

Re: [Mesa3d-dev] Latest changes

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

Brian Paul wrote:
> 

> How or where should we check for feedback and selection mode in
> the point/line/triangle selection functions?  Should we test for
> that down in the driver's code, or higher up in the _swrast_validate_point()
> function?

My first guess wasn't quite right, so I'm not sure what the problem is.  It
looks like we check & install select functions correctly, and the
samples/select demo appears roughly to work.  Can you give more details of
what you're seeing?

If I was to randomly guess again, I'd say something like

	if (ctx->RenderMode != GL_RENDER) return NULL;

was required at the top of get_line_func, get_point_func and get_triangle_func
in xm_line.c and xm_tri.c

Keith

Re: [Mesa3d-dev] Latest changes

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

Brian Paul wrote:
> 

> 
> How or where should we check for feedback and selection mode in
> the point/line/triangle selection functions?  Should we test for
> that down in the driver's code, or higher up in the _swrast_validate_point()
> function?

Ahh..  I originally left the feedback/select point/line/tri functions up in
the main directory.  In the last batch of changes I moved them down into
swrast, but I forgot to update the _swrast_choose_line(), etc. functions.  The
tests should be made there...

It'll be necessary to check the two drivers that extend swrast (x11, osmesa)
to make sure that they respect rendermode in their chooser functions, too.

Keith

Re: [Mesa3d-dev] Latest changes

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

Keith Whitwell wrote:
> 
> Brian Paul wrote:
> >
> > I'm looking at the swrast line functions.  There's no longer a third
> > provoking vertex parameter like there used to be.  For flat-shaded
> > lines it looks like your temporarily changing the 0th vertex's color,
> > calling the line function, then restoring the 0th vertex color.
> >
> > Why not declare a temporary vertex in the line template function,
> > set its color/specular/index fields to the provoking vertex's color
> > and pass it as a third vertex?
> 
> I chose this technique because it is a good match for hardware rasterizers we
> already understand.  The copy/restore has proven to be a fast operation on
> hardware drivers so I opted for uniformity.
> 
> The software setup code has more copying than the hardware code for 2 reasons:
> 
>         - most hardware code doesn't copy specular.  It should do if the hardware
> supports it & therefore we have some bugs in the hardware code (mga, i810,
> r128).
> 
>         - no hardware drivers support color-index rendering.
> 
> > I see you do something similar for triangles and for two-sided lighting.
> >
> > Here's an idea:
> >
> > Suppose in the SWvertex struct we declare color, specular, and index
> > to be 2-D arrays where the first dimension is the front/back-side
> > index:
> >
> >    GLchan color[2][4];  /* color[0] = front, color[1] = back */
> 
> I guess it's just a question of where the complexity goes.  I'm pretty happy
> with the current breakdown, of a simple triangle rasterizer that just knows
> about rasterizing triangles and is a good match for existing hardware
> rasterizers.  Above that, a layer which understands the parts of GL state that
> go beyond straightforward rasterization.
> 
> I don't think hardware rasterizers are going to change significantly, or at
> least not so that we can see - this is probably the last generation of cards
> where we'll have to talk to the rasterizer directly.
> 
> > Then we could pass a front/back flag to the triangle function to
> > tell it which color to use.
> >
> > Passing a front/back flag might also be useful for culling.
> 
> If you are going to pass anything it should be area, so that doesn't need
> recalculation.
> 
>         _swrast_Triangle( GLcontext *ctx,
>                           SWvertex *v0, SWvertex *v1, SWvertex *v2,
>                           SWvertex *pv,
>                           GLfloat area )
> 
>         _swrast_Line( GLcontext *ctx,
>                       SWvertex *v0, SWvertex *v1,
>                       SWvertex *pv,
>                       GLfloat area  or GLuint side )
> 
>         _swrast_Point( GLcontext *ctx,
>                        SWvertex *v0,
>                        SWvertex *pv,   /* need this for unfilled, flat-shaded tris */
>                        GLfloat area or GLuint side )
> 
> This helps to cut out the copying of data, but it's less obvious whats going
> on.  Hardware drivers should still be able to use this for fallbacks as long
> as the rasterizer is no smarter than the ones we've already seen.  In
> 'fx_fallback_line', you don't have access to the information to calculate
> area, but you can just pretend that the line is frontfacing, and fill in the
> color[0] values from the hardware vertices.

Your initial perf numbers seem to confirm that the hit isn't too big.
We can probably optimize things later to make up for any loss, if needed.

 
> Coincidentally, how does current mesa handle GL_POINT mode unfilled,
> flatshaded triangles?  How is the provoking vertex passed to the point
> routines?

It's not.  It's broken.  I guess no one's ever noticed.


> In any case I don't get as good a feeling when I look at these routines as I
> do when I look at the current ones.  As a stopgap, it is possible to split the
> color-copying code to copy either just rgba or (rgba, spec, index) depending
> on rendermode, etc.
> 
> As a general summary of my feelings, I guess I'd like to wait & see & find out
> more about this code before changing it in new directions...
> 
> > Could you put some comments in the swsetup triangle template about
> > the edge flag code?  I'm wondering what the 0x1 and 0x2 bits are
> > for and why they're being modified during rendering.  It seems to
> > me that the vertex buffer should not be modified during rasterization.
> 
> There are some old comments in vbrender.c about this.  I'm not entirely happy
> with the way I'm doing edgeflags yet -- the SI makes it look really simple by
> comparison.

OK.


How or where should we check for feedback and selection mode in
the point/line/triangle selection functions?  Should we test for
that down in the driver's code, or higher up in the _swrast_validate_point()
function?

-Brian

[Mesa3d-dev] quick perf check with new swrast module

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

The most obvious perf checks ever:

	gears	iso-sm	iso-flat m3d-sm m3d-flt

3.4	64.2	14.9	19.0	21.7	23.9
cvs	63.3	14.9	18.2	21.3	23.8

so, as it stands there is a slowdown with flatshading but it's not huge, the
worst example being isosurf at 4.5%.  

I'd still prefer to put a little effort into optimizing that case rather than
change the interfaces at this point.

Keith

Re: [Mesa3d-dev] Latest changes

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

Brian Paul wrote:
> 
> I'm looking at the swrast line functions.  There's no longer a third
> provoking vertex parameter like there used to be.  For flat-shaded
> lines it looks like your temporarily changing the 0th vertex's color,
> calling the line function, then restoring the 0th vertex color.
>
> Why not declare a temporary vertex in the line template function,
> set its color/specular/index fields to the provoking vertex's color
> and pass it as a third vertex?

I chose this technique because it is a good match for hardware rasterizers we
already understand.  The copy/restore has proven to be a fast operation on
hardware drivers so I opted for uniformity.  

The software setup code has more copying than the hardware code for 2 reasons:

	- most hardware code doesn't copy specular.  It should do if the hardware
supports it & therefore we have some bugs in the hardware code (mga, i810,
r128).

	- no hardware drivers support color-index rendering.



> I see you do something similar for triangles and for two-sided lighting.
> 
> Here's an idea:
> 
> Suppose in the SWvertex struct we declare color, specular, and index
> to be 2-D arrays where the first dimension is the front/back-side
> index:
> 
>    GLchan color[2][4];  /* color[0] = front, color[1] = back */

I guess it's just a question of where the complexity goes.  I'm pretty happy
with the current breakdown, of a simple triangle rasterizer that just knows
about rasterizing triangles and is a good match for existing hardware
rasterizers.  Above that, a layer which understands the parts of GL state that
go beyond straightforward rasterization.  

I don't think hardware rasterizers are going to change significantly, or at
least not so that we can see - this is probably the last generation of cards
where we'll have to talk to the rasterizer directly.  



> Then we could pass a front/back flag to the triangle function to
> tell it which color to use.
> 
> Passing a front/back flag might also be useful for culling.

If you are going to pass anything it should be area, so that doesn't need
recalculation.  

	_swrast_Triangle( GLcontext *ctx, 
			  SWvertex *v0, SWvertex *v1, SWvertex *v2,
			  SWvertex *pv,
			  GLfloat area )

	_swrast_Line( GLcontext *ctx, 
		      SWvertex *v0, SWvertex *v1,
		      SWvertex *pv,
		      GLfloat area  or GLuint side )

	_swrast_Point( GLcontext *ctx,
		       SWvertex *v0,
		       SWvertex *pv,   /* need this for unfilled, flat-shaded tris */
		       GLfloat area or GLuint side )


This helps to cut out the copying of data, but it's less obvious whats going
on.  Hardware drivers should still be able to use this for fallbacks as long
as the rasterizer is no smarter than the ones we've already seen.  In
'fx_fallback_line', you don't have access to the information to calculate
area, but you can just pretend that the line is frontfacing, and fill in the
color[0] values from the hardware vertices.

Coincidentally, how does current mesa handle GL_POINT mode unfilled,
flatshaded triangles?  How is the provoking vertex passed to the point
routines?
 
In any case I don't get as good a feeling when I look at these routines as I
do when I look at the current ones.  As a stopgap, it is possible to split the
color-copying code to copy either just rgba or (rgba, spec, index) depending
on rendermode, etc. 

As a general summary of my feelings, I guess I'd like to wait & see & find out
more about this code before changing it in new directions...
			  
> Could you put some comments in the swsetup triangle template about
> the edge flag code?  I'm wondering what the 0x1 and 0x2 bits are
> for and why they're being modified during rendering.  It seems to
> me that the vertex buffer should not be modified during rasterization.

There are some old comments in vbrender.c about this.  I'm not entirely happy
with the way I'm doing edgeflags yet -- the SI makes it look really simple by
comparison.

Keith

Re: [Mesa3d-dev] Latest changes

[Daryll S. <da...@va...>]

On Sun, Nov 05, 2000 at 02:46:29PM -0700, Keith Whitwell wrote:
> Brian Paul wrote:
> > 1. _swsetup_RegisterVB() returns a boolean, but in dd.h, the RegisterVB
> >    function pointer returns void.  Which should it be?
> 
> Hmm.  If it does fail (it alloc's memory, typically), I'm not sure we can go
> on.  It might as well exit on failure and return void.

Gack no. Libraries should never exit the application. You have to
propigate the failure back to the client application so it has an
opportunity to influence the behavior. 

					- |Daryll

Re: [Mesa3d-dev] Latest changes

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

Keith Whitwell wrote:
> 
> Brian Paul wrote:
> >
> 
> >
> > Good work, Keith.  This is looking really good.
> >
> > After compiling and taking a quick look over the code I just have a
> > couple comments:
> >
> > 1. _swsetup_RegisterVB() returns a boolean, but in dd.h, the RegisterVB
> >    function pointer returns void.  Which should it be?
> 
> Hmm.  If it does fail (it alloc's memory, typically), I'm not sure we can go
> on.  It might as well exit on failure and return void.
> 
> > 2. I think the SWvertex pointers passed to the point, line and triangle
> >    functions could/should be const-qualified.  Right?
> 
> Probably, yes.


I'm looking at the swrast line functions.  There's no longer a third
provoking vertex parameter like there used to be.  For flat-shaded
lines it looks like your temporarily changing the 0th vertex's color,
calling the line function, then restoring the 0th vertex color.

Why not declare a temporary vertex in the line template function,
set its color/specular/index fields to the provoking vertex's color
and pass it as a third vertex?

I see you do something similar for triangles and for two-sided lighting.

Here's an idea:

Suppose in the SWvertex struct we declare color, specular, and index
to be 2-D arrays where the first dimension is the front/back-side
index:

   GLchan color[2][4];  /* color[0] = front, color[1] = back */

Then we could pass a front/back flag to the triangle function to
tell it which color to use.

Passing a front/back flag might also be useful for culling.

Could you put some comments in the swsetup triangle template about
the edge flag code?  I'm wondering what the 0x1 and 0x2 bits are
for and why they're being modified during rendering.  It seems to
me that the vertex buffer should not be modified during rasterization.

-Brian