Re: [Mesa3d-dev] RE: [Dri-devel] Mesa glTexEnv bug (Was: S3TC andut2k)
Ian Romanick wrote:
Brian Paul wrote:
Leif Delgass wrote:
On Thu, 2 Jan 2003, Daniel Vogel wrote:
>>
glTexEnvi( GL_TEXTURE_ENV, GL_OPERAND2_RGB, GL_SRC_COLOR );
This is indeed one of the sources of the GL_INVALID_ENUMs; however, it
appears to be a bug in Mesa. There seems to be a missing break after
texstate.c:423 :
--- texstate.c Tue Jan 21 17:10:15 2003
+++ texstate.fixed.cTue Jan 21 17:11:19 2003
@@ -421,6 +421,7 @@
return;
FLUSH_VERTICES(ctx, _NEW_TEXTURE);
texUnit->CombineOperandRGB[2] = operand;
+ break;
default:
TE_ERROR(GL_INVALID_ENUM, "glTexEnv(param=%s)",
operand);
return;
Brian, does that look right to you?
Yes. There should be a break there. I'm surprised this wasn't found
when running the texcombine conformance test or Glean test. Hmmm.
Glean didn't catch it because it only ever sets GL_OPERAND2_{RGB,ALPHA}
to the default state. This ends up taking the early-out path in
texstate.c. Just dumb luck.
[snip]
However, I still see the same corruption reported before. This could
be in part because of the missing cube map support, but it looks to
me like something is causing vertex data corruption. Just a guess.
Cube mapping works in the R200 driver with one caveat: glTexCoord3*()
commands don't work. Normally, a texgen mode like GL_REFLECT is used
with cube maps so the texcoords are generated in hardware. The h/w
vertex setup code needs to be updated to handle 3-component texture
coords.
Not sure if this is the problem you're seeing though. The
Mesa/demos/cubemap program shows the problem.
How exactly does this problem look? This might be exactly the problem
that I'm geting on r100. Could you put a screenshot up somewhere?
If you modify the cubemap.c program to pass 0 as the R coordinate to all the
glTexCoord3f() calls in draw_skybox() you'd probably get the idea.
If
it is the same thing on r100, I'll go ahead and commit my cube map
changes, and we'll have to hope someone figures out how to setup the
hardware for the R coord. :/
-Brian
---
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] RE: [Dri-devel] Mesa glTexEnv bug (Was: S3TC andut2k)
Leif Delgass wrote: On Wed, 22 Jan 2003, Daniel Vogel wrote: ftp://ftp.retinalburn.net/pub/ut2k3/Shot0.bmp ftp://ftp.retinalburn.net/pub/ut2k3/Shot1.bmp How does "rmode 7" (untextured, lighting only) look like? "rmode 5" == regular "rmode 6" == just textures ftp://ftp.retinalburn.net/pub/ut2k3/rmode6_1.bmp ftp://ftp.retinalburn.net/pub/ut2k3/rmode6_2.bmp "rmode 7" == just lighting ftp://ftp.retinalburn.net/pub/ut2k3/rmode7_1.bmp ftp://ftp.retinalburn.net/pub/ut2k3/rmode6_2.bmp As you can see, both modes still seem to have vertex problems. Could it be related to the lack of NV_vertex_array_range or ATI_vertex_array_object? I assume there's a fallback path since I don't see any GL errors related to those extensions. It looks like a bug on our vertex/vertex array paths. Keith --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Mesa3d-dev] RE: [Dri-devel] Mesa glTexEnv bug (Was: S3TC andut2k)
On Wed, 22 Jan 2003, Daniel Vogel wrote: > > ftp://ftp.retinalburn.net/pub/ut2k3/Shot0.bmp > > ftp://ftp.retinalburn.net/pub/ut2k3/Shot1.bmp > > How does "rmode 7" (untextured, lighting only) look like? > > "rmode 5" == regular > "rmode 6" == just textures ftp://ftp.retinalburn.net/pub/ut2k3/rmode6_1.bmp ftp://ftp.retinalburn.net/pub/ut2k3/rmode6_2.bmp > "rmode 7" == just lighting ftp://ftp.retinalburn.net/pub/ut2k3/rmode7_1.bmp ftp://ftp.retinalburn.net/pub/ut2k3/rmode6_2.bmp As you can see, both modes still seem to have vertex problems. Could it be related to the lack of NV_vertex_array_range or ATI_vertex_array_object? I assume there's a fallback path since I don't see any GL errors related to those extensions. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] RE: [Dri-devel] Mesa glTexEnv bug (Was: S3TC andut2k)
On Tue, 21 Jan 2003, Ian Romanick wrote:
> Brian Paul wrote:
> > Leif Delgass wrote:
> >
> >> On Thu, 2 Jan 2003, Daniel Vogel wrote:
> >>
> >>> glTexEnvi( GL_TEXTURE_ENV, GL_OPERAND2_RGB, GL_SRC_COLOR );
> >>
> >>
> >>
> >> This is indeed one of the sources of the GL_INVALID_ENUMs; however, it
> >> appears to be a bug in Mesa. There seems to be a missing break after
> >> texstate.c:423 :
> >>
> >> --- texstate.c Tue Jan 21 17:10:15 2003
> >> +++ texstate.fixed.cTue Jan 21 17:11:19 2003
> >> @@ -421,6 +421,7 @@
> >> return;
> >>FLUSH_VERTICES(ctx, _NEW_TEXTURE);
> >>texUnit->CombineOperandRGB[2] = operand;
> >> + break;
> >> default:
> >> TE_ERROR(GL_INVALID_ENUM, "glTexEnv(param=%s)", operand);
> >>return;
> >>
> >> Brian, does that look right to you?
> >
> >
> > Yes. There should be a break there. I'm surprised this wasn't found
> > when running the texcombine conformance test or Glean test. Hmmm.
>
> Glean didn't catch it because it only ever sets GL_OPERAND2_{RGB,ALPHA}
> to the default state. This ends up taking the early-out path in
> texstate.c. Just dumb luck.
>
> [snip]
>
> >> However, I still see the same corruption reported before. This could
> >> be in part because of the missing cube map support, but it looks to me
> >> like something is causing vertex data corruption. Just a guess.
> >
> > Cube mapping works in the R200 driver with one caveat: glTexCoord3*()
> > commands don't work. Normally, a texgen mode like GL_REFLECT is used
> > with cube maps so the texcoords are generated in hardware. The h/w
> > vertex setup code needs to be updated to handle 3-component texture coords.
> >
> > Not sure if this is the problem you're seeing though. The
> > Mesa/demos/cubemap program shows the problem.
>
> How exactly does this problem look? This might be exactly the problem
> that I'm geting on r100. Could you put a screenshot up somewhere? If
> it is the same thing on r100, I'll go ahead and commit my cube map
> changes, and we'll have to hope someone figures out how to setup the
> hardware for the R coord. :/
I put up examples from UT2003. This is with the texmem branch on R100
with the texture combine one-liner, but without cube map exported
(althought the texmem branch seems to have at least the beginning of cube
map support, right?):
ftp://ftp.retinalburn.net/pub/ut2k3/Shot0.bmp
ftp://ftp.retinalburn.net/pub/ut2k3/Shot1.bmp
I don't think this is "The way it's meant to be played(TM)" :) At any
rate, I think you can see from the second shot what I mean about the
vertices looking wrong.
--
Leif Delgass
http://www.retinalburn.net
---
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] RE: [Dri-devel] Mesa glTexEnv bug (Was: S3TC andut2k)
Brian Paul wrote:
Leif Delgass wrote:
On Thu, 2 Jan 2003, Daniel Vogel wrote:
>>
glTexEnvi( GL_TEXTURE_ENV, GL_OPERAND2_RGB, GL_SRC_COLOR );
This is indeed one of the sources of the GL_INVALID_ENUMs; however, it
appears to be a bug in Mesa. There seems to be a missing break after
texstate.c:423 :
--- texstate.c Tue Jan 21 17:10:15 2003
+++ texstate.fixed.cTue Jan 21 17:11:19 2003
@@ -421,6 +421,7 @@
return;
FLUSH_VERTICES(ctx, _NEW_TEXTURE);
texUnit->CombineOperandRGB[2] = operand;
+ break;
default:
TE_ERROR(GL_INVALID_ENUM, "glTexEnv(param=%s)", operand);
return;
Brian, does that look right to you?
Yes. There should be a break there. I'm surprised this wasn't found
when running the texcombine conformance test or Glean test. Hmmm.
Glean didn't catch it because it only ever sets GL_OPERAND2_{RGB,ALPHA}
to the default state. This ends up taking the early-out path in
texstate.c. Just dumb luck.
[snip]
However, I still see the same corruption reported before. This could
be in part because of the missing cube map support, but it looks to me
like something is causing vertex data corruption. Just a guess.
Cube mapping works in the R200 driver with one caveat: glTexCoord3*()
commands don't work. Normally, a texgen mode like GL_REFLECT is used
with cube maps so the texcoords are generated in hardware. The h/w
vertex setup code needs to be updated to handle 3-component texture coords.
Not sure if this is the problem you're seeing though. The
Mesa/demos/cubemap program shows the problem.
How exactly does this problem look? This might be exactly the problem
that I'm geting on r100. Could you put a screenshot up somewhere? If
it is the same thing on r100, I'll go ahead and commit my cube map
changes, and we'll have to hope someone figures out how to setup the
hardware for the R coord. :/
---
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] RE: [Dri-devel] Mesa glTexEnv bug (Was: S3TC andut2k)
Leif Delgass wrote: On Thu, 2 Jan 2003, Daniel Vogel wrote: A bit unrelated: Log: OpenGL Error: GL_INVALID_ENUM (UOpenGLRenderDevice::Unlock) (if anyone wants the full log let me know) On OS X 10.2.3 this is caused by glTexEnvi( GL_TEXTURE_ENV, GL_OPERAND2_RGB, GL_SRC_COLOR ); This is indeed one of the sources of the GL_INVALID_ENUMs; however, it appears to be a bug in Mesa. There seems to be a missing break after texstate.c:423 : --- texstate.c Tue Jan 21 17:10:15 2003 +++ texstate.fixed.cTue Jan 21 17:11:19 2003 @@ -421,6 +421,7 @@ return; FLUSH_VERTICES(ctx, _NEW_TEXTURE); texUnit->CombineOperandRGB[2] = operand; + break; default: TE_ERROR(GL_INVALID_ENUM, "glTexEnv(param=%s)", operand); return; Brian, does that look right to you? Yes. There should be a break there. I'm surprised this wasn't found when running the texcombine conformance test or Glean test. Hmmm. I'll check in this change to the Mesa CVS branches. Can you do it for the DRI CVS branches? The other INVALID_ENUMS appear to be caused by an assumption that GL_ARB_texture_cube_map is supported, which it isn't in the current DRI Radeon driver. There appear to be calls to glDisable and glTexParameter using GL_TEXTURE_CUBE_MAP_ARB even thought the extension isn't supported. At least that's what I found with MESA_DEBUG=1 just from the intro/menu screens. I tried exporting GL_ARB_texture_cube_map from the Radeon driver and along with the above patch, it makes all the OpenGL errors go away. The lack of combine3/4 seems to be handled in the version I'm using (from the UT2003.log): Init: OpenGL: WARNING: no support for combine3/4 extensions -> not all blend modes supported However, I still see the same corruption reported before. This could be in part because of the missing cube map support, but it looks to me like something is causing vertex data corruption. Just a guess. Cube mapping works in the R200 driver with one caveat: glTexCoord3*() commands don't work. Normally, a texgen mode like GL_REFLECT is used with cube maps so the texcoords are generated in hardware. The h/w vertex setup code needs to be updated to handle 3-component texture coords. Not sure if this is the problem you're seeing though. The Mesa/demos/cubemap program shows the problem. -Brian --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
