Re: [Dri-devel] Mesa glTexEnv bug (Was: S3TC and ut2k)

2003-01-21 Thread Ian Romanick 
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?


I had just come across this today also.  I think a better sollution 
would be to fold the GL_OPERAND2_{RGB,ALPHA} cases in with the 
GL_OPERAND[01]_{RGB,ALPHA} cases.  If we care about filtering out the 
cases that are not valid for EXT_texture_env_combine, we should do in 
the inner switch in those cases.

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):

When I've had spare cycles, I've been working on ARB_texture_cube_map 
for the r100.  It's almost working, but I think there something subtle 
the I'm missing. :(

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.

ATI_texture_env_combine3 should be in the Mesa tree soon.  I'm working 
on hardware support for the r100, but it seems to have some problems 
with GL_SUBTRACT and GL_MODULATE_SUBTRACT_ATI.  The card seems to ignore 
the GL_ONE_MINUS_SRC_{COLOR,ALPHA} and treats it like 
GL_SRC_{COLOR,ALPHA}.  That one really has me baffled.

Are subtract problems on r100 an known issue?



---
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: [Dri-devel] Mesa glTexEnv bug (Was: S3TC and ut2k)

2003-01-21 Thread Leif Delgass 
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?

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.

-- 
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: [Dri-devel] Mesa glTexEnv bug (Was: S3TC and ut2k)

2003-01-21 Thread Brian Paul 
Ian Romanick wrote:

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?



I had just come across this today also.  I think a better sollution 
would be to fold the GL_OPERAND2_{RGB,ALPHA} cases in with the 
GL_OPERAND[01]_{RGB,ALPHA} cases.  If we care about filtering out the 
cases that are not valid for EXT_texture_env_combine, we should do in 
the inner switch in those cases.

Feel free to whip up a patch for that. :)

-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: [Dri-devel] Mesa glTexEnv bug (Was: S3TC and ut2k)

2003-01-21 Thread Leif Delgass 
On Tue, 21 Jan 2003, Brian Paul wrote:

 Ian Romanick wrote:
  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?
  
  
  I had just come across this today also.  I think a better sollution 
  would be to fold the GL_OPERAND2_{RGB,ALPHA} cases in with the 
  GL_OPERAND[01]_{RGB,ALPHA} cases.  If we care about filtering out the 
  cases that are not valid for EXT_texture_env_combine, we should do in 
  the inner switch in those cases.
 
 Feel free to whip up a patch for that. :)
 
 -Brian

In the meantime, I've commited the one-line fix to DRI HEAD, texmem-0-0-1
and mesa-4-0-4-branch, since the bug is in 4.x also.  Should I submit it
to [EMAIL PROTECTED] too or is there going to be another merge from
texmem-0-0-1 before 4.3.0?

-- 
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: [Dri-devel] Mesa glTexEnv bug (Was: S3TC and ut2k)

2003-01-21 Thread Leif Delgass 
On Tue, 21 Jan 2003, Leif Delgass wrote:

 On Tue, 21 Jan 2003, Brian Paul wrote:
 
  Ian Romanick wrote:
   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?
   
   
   I had just come across this today also.  I think a better sollution 
   would be to fold the GL_OPERAND2_{RGB,ALPHA} cases in with the 
   GL_OPERAND[01]_{RGB,ALPHA} cases.  If we care about filtering out the 
   cases that are not valid for EXT_texture_env_combine, we should do in 
   the inner switch in those cases.
  
  Feel free to whip up a patch for that. :)
  
  -Brian
 
 In the meantime, I've commited the one-line fix to DRI HEAD, texmem-0-0-1
 and mesa-4-0-4-branch, since the bug is in 4.x also.  Should I submit it
 to [EMAIL PROTECTED] too or is there going to be another merge from
 texmem-0-0-1 before 4.3.0?

Arggh! Merge from mesa-4-0-4-branch that is.  Too many branches. ;)

-- 
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: [Dri-devel] Mesa glTexEnv bug (Was: S3TC and ut2k)

2003-01-21 Thread Michel Dänzer 
On Mit, 2003-01-22 at 01:24, Leif Delgass wrote:
 On Tue, 21 Jan 2003, Leif Delgass wrote:
 
  In the meantime, I've commited the one-line fix to DRI HEAD, texmem-0-0-1
  and mesa-4-0-4-branch, since the bug is in 4.x also.  

Thanks.

  Should I submit it to [EMAIL PROTECTED] too or is there going to be 
  another merge from texmem-0-0-1 before 4.3.0?
 
 Arggh! Merge from mesa-4-0-4-branch that is.  Too many branches. ;)

Hehe, I think David is picking up fixes from mesa-4-0-4-branch.


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast



---
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 and ut2k)

2003-01-21 Thread Dieter Nützel 
Am Mittwoch, 22. Januar 2003 02:14 schrieb Ian Romanick:
 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 can send you both Mesa-5.1 and DRI r200 trunk.

-Dieter



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