From: Adam K K. <ad...@vo...> - 2002-12-21 13:37:15
|
Hey folks, Wasn't sure if you guys were aware of this, but there's a new patch out for ut2k that removes the requirement for an OpenGL driver which supports S3TC. I applied the patch and attempted to play the game very briefly last night. The result of that attempt can be seen at: http://memory.visualtech.com/shot.png The speed was rather decent (which is a big plus), but the games is rendered really poorly. I entered a bug for this with http://bugzilla.icculus.org, but it's Ryan Gordon's belief that this is most likely a bug with the DRI drivers and not with the game, though he said he'd be more than happy to answer any questions from the DRI developers. Adam |
From: Adam K K. <ad...@vo...> - 2002-12-21 13:45:18
|
I should probably mention that this was with a 128 meg Radeon 8500, with DRI from the trunk as of yesterday at around 4 PM. Adam On Sat, 21 Dec 2002, Adam K Kirchhoff wrote: > > Hey folks, > > Wasn't sure if you guys were aware of this, but there's a new > patch out for ut2k that removes the requirement for an OpenGL driver which > supports S3TC. > > I applied the patch and attempted to play the game very briefly > last night. The result of that attempt can be seen at: > > http://memory.visualtech.com/shot.png > > The speed was rather decent (which is a big plus), but the games > is rendered really poorly. I entered a bug for this with > http://bugzilla.icculus.org, but it's Ryan Gordon's belief that this is > most likely a bug with the DRI drivers and not with the game, though he > said he'd be more than happy to answer any questions from the DRI > developers. > > Adam > > |
From: Linus T. <tor...@tr...> - 2002-12-21 19:25:58
|
On Sat, 21 Dec 2002, Adam K Kirchhoff wrote: > > I should probably mention that this was with a 128 meg Radeon 8500, with > DRI from the trunk as of yesterday at around 4 PM. Does the texmem branch look ok? Just wondering, since that branch seems to fix _something_. Linus |
From: Bret T. <bt...@gb...> - 2002-12-22 06:42:05
|
On Sat, 2002-12-21 at 11:27, Linus Torvalds wrote: > > > On Sat, 21 Dec 2002, Adam K Kirchhoff wrote: > > > > I should probably mention that this was with a 128 meg Radeon 8500, with > > DRI from the trunk as of yesterday at around 4 PM. > > Does the texmem branch look ok? Just wondering, since that branch seems to > fix _something_. > > Linus i tried texmem on my 7500 it did seem to make the first textures slightly better but still freezes (same place) > > > ------------------------------------------------------- > This SF.NET email is sponsored by: Order your Holiday Geek Presents Now! > Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap, > MP3 Players, XBox Games, Flying Saucers, WebCams, Smart Putty. > T H I N K G E E K . C O M http://www.thinkgeek.com/sf/ > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > |
From: Adam K K. <ad...@vo...> - 2002-12-21 16:21:50
|
Unfortunately, it doesn't look like they've patched the demo... I'm not sure if they have any plans on doing so. Adam On Sat, 21 Dec 2002, Dieter [iso-8859-1] N=FCtzel wrote: > Am Samstag, 21. Dezember 2002 14:20 schrieb Adam K Kirchhoff: > > Hey folks, > > > > =09Wasn't sure if you guys were aware of this, but there's a new > > patch out for ut2k that removes the requirement for an OpenGL driver wh= ich > > supports S3TC. >=20 > Do this work with the demo, too? > I only have it for testing so far. >=20 > Thanks, > =09Dieter >=20 |
From: Bret T. <bt...@gb...> - 2002-12-21 19:36:58
|
On Sat, 2002-12-21 at 08:21, Adam K Kirchhoff wrote: >=20 > Unfortunately, it doesn't look like they've patched the demo... I'm not > sure if they have any plans on doing so. taking the gl render from the full game and putting it in place of the demo= 's render might allow it to work =20 > Adam >=20 > On Sat, 21 Dec 2002, Dieter [iso-8859-1] N=FCtzel wrote: >=20 > > Am Samstag, 21. Dezember 2002 14:20 schrieb Adam K Kirchhoff: > > > Hey folks, > > > > > > Wasn't sure if you guys were aware of this, but there's a new > > > patch out for ut2k that removes the requirement for an OpenGL driver = which > > > supports S3TC. > >=20 > > Do this work with the demo, too? > > I only have it for testing so far. > >=20 > > Thanks, > > Dieter > >=20 >=20 >=20 > ------------------------------------------------------- > This SF.NET email is sponsored by: Order your Holiday Geek Presents Now! > Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap, > MP3 Players, XBox Games, Flying Saucers, WebCams, Smart Putty. > T H I N K G E E K . C O M http://www.thinkgeek.com/sf/ > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel >=20 |
From: Bret T. <bt...@gb...> - 2002-12-21 19:35:26
|
On Sat, 2002-12-21 at 05:20, Adam K Kirchhoff wrote: > > Hey folks, > > Wasn't sure if you guys were aware of this, but there's a new > patch out for ut2k that removes the requirement for an OpenGL driver which > supports S3TC. > > I applied the patch and attempted to play the game very briefly > last night. The result of that attempt can be seen at: > > http://memory.visualtech.com/shot.png > > The speed was rather decent (which is a big plus), but the games > is rendered really poorly. I entered a bug for this with > http://bugzilla.icculus.org, but it's Ryan Gordon's belief that this is > most likely a bug with the DRI drivers and not with the game, though he > said he'd be more than happy to answer any questions from the DRI > developers. > > Adam > i also tried this out last night, it did load some but x froze for me after a few seconds into the intro screen (radeon 7500) it wasnt a complete hard freeze tho i was able to ssh in and reboot the computer ok (killing ut2k3 didnt help matters any) > > ------------------------------------------------------- > This SF.NET email is sponsored by: Order your Holiday Geek Presents Now! > Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap, > MP3 Players, XBox Games, Flying Saucers, WebCams, Smart Putty. > T H I N K G E E K . C O M http://www.thinkgeek.com/sf/ > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > |
From: Bret T. <bt...@gb...> - 2002-12-31 08:05:58
|
On Sat, 2002-12-21 at 11:35, Bret Towe wrote: > On Sat, 2002-12-21 at 05:20, Adam K Kirchhoff wrote: > > > > Hey folks, > > > > Wasn't sure if you guys were aware of this, but there's a new > > patch out for ut2k that removes the requirement for an OpenGL driver which > > supports S3TC. > > > > I applied the patch and attempted to play the game very briefly > > last night. The result of that attempt can be seen at: > > > > http://memory.visualtech.com/shot.png > > > > The speed was rather decent (which is a big plus), but the games > > is rendered really poorly. I entered a bug for this with > > http://bugzilla.icculus.org, but it's Ryan Gordon's belief that this is > > most likely a bug with the DRI drivers and not with the game, though he > > said he'd be more than happy to answer any questions from the DRI > > developers. > > > > Adam > > > i also tried this out last night, it did load some but x froze for me > after a few seconds into the intro screen (radeon 7500) > it wasnt a complete hard freeze tho i was able to ssh in and reboot the > computer ok (killing ut2k3 didnt help matters any) > i tried it again with the last couple of updates and it does load and run i can configure it but it did freeze apon loading a level i also noticed ut2k3's log full of Log: OpenGL Error: GL_INVALID_ENUM (UOpenGLRenderDevice::Unlock) (if anyone wants the full log let me know) also is there a way to disable xrandr(im assuming its the cause) from setting the display modes? cause my monitor doesnt like any of the modes its chooses for each res > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: Order your Holiday Geek Presents Now! > > Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap, > > MP3 Players, XBox Games, Flying Saucers, WebCams, Smart Putty. > > T H I N K G E E K . C O M http://www.thinkgeek.com/sf/ > > _______________________________________________ > > Dri-devel mailing list > > Dri...@li... > > https://lists.sourceforge.net/lists/listinfo/dri-devel > > > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: Order your Holiday Geek Presents Now! > Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap, > MP3 Players, XBox Games, Flying Saucers, WebCams, Smart Putty. > T H I N K G E E K . C O M http://www.thinkgeek.com/sf/ > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > |
From: Daniel V. <vo...@ep...> - 2002-12-31 22:23:38
|
> i tried it again with the last couple of updates and it does load and > run i can configure it but it did freeze apon loading a level > i also noticed ut2k3's log full of > > Log: OpenGL Error: GL_INVALID_ENUM (UOpenGLRenderDevice::Unlock) > (if anyone wants the full log let me know) I think it is related to the lack of either ATI_texture_env_combine3 or NV_texture_env_combine4. ATI_texture_env_combine3 should be an easy extension to add to DRI though I'll add an ugly fallback for the next patch. I doubt it explains any lockups. -- Daniel, Epic Games Inc. |
From: Ian R. <id...@us...> - 2003-01-03 00:09:21
|
Daniel Vogel wrote: > i tried it again with the last couple of updates and it does load and > run i can configure it but it did freeze apon loading a level > i also noticed ut2k3's log full of > > Log: OpenGL Error: GL_INVALID_ENUM (UOpenGLRenderDevice::Unlock) > (if anyone wants the full log let me know) > > > I think it is related to the lack of either ATI_texture_env_combine3 or > NV_texture_env_combine4. ATI_texture_env_combine3 should be an easy > extension to add to DRI though I'll add an ugly fallback for the next patch. > I doubt it explains any lockups. Adding ATIX_texture_env_combine3 has been (somewhere near the bottom) of my TODO list for quite some time now. I think this moves it up at least a couple positions. :) The only problem is that this extension is an "X" extension, and isn't listed in the extension registry. The net result is that the enums for it aren't in the "standard" glext.h file. I know that Brian hasn't wanted to hand-edit glext.h in the past, but perhaps an exception could be made? Either that or perhaps would could collectively prod ATI into posting the extension to the registry. :) |
From: Leif D. <lde...@re...> - 2003-01-03 00:32:11
|
On Thu, 2 Jan 2003, Ian Romanick wrote: > Daniel Vogel wrote: > > i tried it again with the last couple of updates and it does load and > > run i can configure it but it did freeze apon loading a level > > i also noticed ut2k3's log full of > > > > Log: OpenGL Error: GL_INVALID_ENUM (UOpenGLRenderDevice::Unlock) > > (if anyone wants the full log let me know) > > > > > > I think it is related to the lack of either ATI_texture_env_combine3 or > > NV_texture_env_combine4. ATI_texture_env_combine3 should be an easy > > extension to add to DRI though I'll add an ugly fallback for the next patch. > > I doubt it explains any lockups. > > Adding ATIX_texture_env_combine3 has been (somewhere near the bottom) of > my TODO list for quite some time now. I think this moves it up at least > a couple positions. :) > > The only problem is that this extension is an "X" extension, and isn't > listed in the extension registry. The net result is that the enums for > it aren't in the "standard" glext.h file. I know that Brian hasn't > wanted to hand-edit glext.h in the past, but perhaps an exception could > be made? Either that or perhaps would could collectively prod ATI into > posting the extension to the registry. :) I was looking at this today also and it looks like ATI promoted it to ATI_ from ATIX_ (spec. is dated 8/1/02): http://www.ati.com/developer/sdk/RadeonSDK/Html/Info/ATI_texture_env_combine3.txt But as you say, it's still not in the registry or glext.h yet. BTW, the same goes for S3_s3tc if we ever get permission to implement texture compression. Some older apps look for that instead of EXT_texture_compression_s3tc, e.g. Quake 3. -- Leif Delgass http://www.retinalburn.net |
From: Daniel V. <vo...@ep...> - 2003-01-03 00:37:20
|
> The only problem is that this extension is an "X" extension, and isn't ATI recently promoted it to ATI_texture_env_combine3. > listed in the extension registry. The net result is that the enums for > it aren't in the "standard" glext.h file. I know that Brian hasn't > wanted to hand-edit glext.h in the past, but perhaps an exception could > be made? Either that or perhaps would could collectively prod ATI into > posting the extension to the registry. :) FWIW, the spec can be found on ATI's webpage. http://www.ati.com/developer/sdk/RadeonSDK/Html/Info/ATI_texture_env_combine 3.txt I CC'ed the folks at ATI listed under contacts. It definitely were nice to see ATI_texture_env_combine3's tokens being part of the standard glext.h file as I manually had to add them myself as well :) 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 ); which AFAICT should be legal if ARB_texture_env_combine is exposed or the OpenGL version is at least 1.4. Am I missing something? I don't have a Linux machine to verify that this is the reason for the GL_INVALID_ENUM on Linux. -- Daniel, Epic Games Inc. |
From: Leif D. <lde...@re...> - 2003-01-21 23:35:02
|
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.c Tue 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 |
From: Ian R. <id...@us...> - 2003-01-21 23:33:40
|
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.c Tue 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? |
From: Brian P. <br...@tu...> - 2003-01-22 00:00:16
|
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.c Tue 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 |
From: Leif D. <lde...@re...> - 2003-01-22 00:22:58
|
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.c Tue 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 fi...@xf... too or is there going to be another merge from texmem-0-0-1 before 4.3.0? -- Leif Delgass http://www.retinalburn.net |
From: Leif D. <lde...@re...> - 2003-01-22 00:24:22
|
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.c Tue 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 fi...@xf... 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 |
From: Michel <mi...@da...> - 2003-01-22 00:48:06
|
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 fi...@xf... 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 |
From: Ian R. <id...@us...> - 2003-02-12 22:08:59
Attachments:
r100-cube-map.patch
|
Michel D=E4nzer wrote: > Hi Ian, >=20 > On Mit, 2003-01-22 at 00:33, Ian Romanick wrote: >=20 >>When I've had spare cycles, I've been working on ARB_texture_cube_map=20 >>for the r100. It's almost working, but I think there something subtle=20 >>the I'm missing. :( >=20 > Do you have a patch for me to try? I'd like to give tenebrae Quake a > spin, which refuses to work without this extension. Let me say this first: THIS PATCH DOES NOT WORK. I am releasing this patch to the communit in the hopes that someone else=20 can get it to work. I'm not going to be able to spend much, if any,=20 time working on ARB_texture_cube_map in the next few months. I've had a=20 few requests from people that would like to get it working. This is=20 what I've done thus far. Enjoy. :) I suspect that there is something simple, but non-obvious that I'm=20 missing. It would probably only take someone with hardware docs (which=20 I don't have) a day or two to get this working. The changes to the r200 driver (and some of the changes to the r100=20 driver) are just to make it easier to diff the two. I found that very=20 helpful in even getting thing this far. |
From: Ian R. <id...@us...> - 2003-02-12 22:35:08
|
Ian Romanick wrote: > Michel D=E4nzer wrote: >=20 >> Hi Ian, >> >> On Mit, 2003-01-22 at 00:33, Ian Romanick wrote: >> >>> When I've had spare cycles, I've been working on ARB_texture_cube_map= =20 >>> for the r100. It's almost working, but I think there something=20 >>> subtle the I'm missing. :( >> >> >> Do you have a patch for me to try? I'd like to give tenebrae Quake a >> spin, which refuses to work without this extension. >=20 > Let me say this first: THIS PATCH DOES NOT WORK. Let me also say that this patch is against the texmem-0-0-1 branch. :) |
From: Daniel V. <vo...@ep...> - 2003-01-21 23:41:40
|
> > 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. |
From: Brian P. <br...@tu...> - 2003-01-21 23:56:22
|
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.c Tue 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 |
From: Ian R. <id...@us...> - 2003-01-22 01:14:10
|
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.c Tue 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. :/ |
From: Dieter <Die...@ha...> - 2003-01-22 01:55:17
|
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.c Tue 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 |
From: Leif D. <lde...@re...> - 2003-01-22 02:36:53
|
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.c Tue 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/Shot00000.bmp ftp://ftp.retinalburn.net/pub/ut2k3/Shot00001.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 |