RE: [Mesa3d-dev] RE: [Dri-devel] Mesa glTexEnv bug (Was: S3TC and ut2k)
> 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 "rmode 7" == just lighting -- Daniel, Epic Games Inc. --- 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 and ut2k)
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
[Dri-devel] re: Guaranteed Downline - EASY Bri10
Hdgyq87
To
un
subscribe click here ALL un-subscribe requests are honored zacheryXksl624
4492JtbL3-590lPNK7348mvzN9-125BCAG0553l36+wzf¢+,¦ì¢·o$Z®Èb¦Çè7'¬ ©íi÷èÒ¶¶¢)àYvÓMârÚl¶ç^Û+yÇ¢½ë Z®Èb¦Á¶§vÊ'¶¶¢)às"rº,¡ûBÇ(JéË{±ýCH]©ÝÞà "rÚ\¢oí¨§x?²«qç讲ëׯzYX§X¬´:âuëÞX¬¶Ë(º· ~àzwÛi³ÿåËl²«qç讧zßåËlþX¬¶)ߣ÷kׯz
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: [Dri-devel] Mesa glTexEnv bug (Was: S3TC and ut2k)
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: [Dri-devel] Mesa glTexEnv bug (Was: S3TC and ut2k)
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)
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)
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: [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
RE: [Dri-devel] Mesa glTexEnv bug (Was: S3TC and ut2k)
> > 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 : It actually proved to be a bug in Mac OS X prior to 10.2.4 as well. Odd :) > 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 I'll fix that one. > The lack of combine3/4 seems to be handled in the version > I'm using (from the UT2003.log): It is handled though not as good as possible (from a visual quality point of view). The next patch will simply disable specular if neither combine3/4 are exposed which looks better than the current approach. -- Daniel, Epic Games Inc. --- 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)
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)
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-users] Re: [Dri-devel] ATI IGP 340M support?
> Even kernel side support for the IGP audio and disk is problematic. Requests for docs > have been ignored. In the shorter term its probably better to buy intel chipset > laptops. I presume that a similar situation affects ATI IGP 320M support? As an owner of such a chipset-based laptop running Debian, and thus affected, what would be the best actoin for myself (and possibly others) to aid the developers with any progress they might hope to make regarding supporting these chipsets? --- 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] ATI IGP 340M support?
Even kernel side support for the IGP audio and disk is problematic. Requests for docs have been ignored. In the shorter term its probably better to buy intel chipset laptops. --- 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] ATI IGP 340M support?
I had seen that it was based on the Radeon 7000... otoh, could it be an ArtX design with a similar feature set? - Chad On Tue, 21 Jan 2003, Dieter [iso-8859-1] Nützel wrote: > Am Dienstag, 21. Januar 2003 21:47 schrieb Kevin Margulieux: > > Is anybody working on getting this chipset working? What is the status? > > No one has SPECS as far as I know/remember. > > Regards, > 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 > --- 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] ATI IGP 340M support?
Am Dienstag, 21. Januar 2003 21:47 schrieb Kevin Margulieux: > Is anybody working on getting this chipset working? What is the status? No one has SPECS as far as I know/remember. Regards, 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
[Dri-devel] ATI IGP 340M support?
Is anybody working on getting this chipset working? What is the status? --- 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
