From: Dieter <Die...@ha...> - 2001-06-24 21:21:43
|
Hello Brian, hello Alan, now after that the mesa-3-5-branch is updated with the trunk we "only" need Alan's fixes for the 4.1.0 tdfx driver plus the fixing of the remaining tdfx (Voodoo5) UT texture bugs (picture is available). * context switching fix (the Khoros Pro 2001 thing) * (texture) memory calculation/reservation fix (the KDE KPager texture corruption problem) * Xv bilinear filtering doesn't work above 1024x768x24 UT crash with the latest mesa-3-5-branch after some seconds. It starts OK but you can look through all walls and objects. After some seconds the whole X server hang and I have to reset or reboot. Most of the time the magic keys do not work. Luckily I have ReiserFS running fine...:-) Regards, Dieter BTW Excuse me if you get this twice. I had my mail configuration wrong. |
From: Keith W. <ke...@va...> - 2001-03-20 18:30:43
|
Brian Paul wrote: > > CVSROOT: /cvsroot/dri > Module name: xc > Repository: xc/xc/lib/GL/mesa/src/drv/tdfx/ > Changes by: brianp@usw-pr-cvs1. 01/03/20 10:05:48 > > Log message: > Remove last of the dependencies on Mesa from dri_mesa.[ch]. This glue > code could now be used by non-Mesa drivers. > Replace CreateWindowBuffer() and CreatePixmapBuffer() with CreateBuffer(). > Added DestroyBuffer(). > We should rename the files to reflect this. Keith |
From: Brian P. <br...@va...> - 2001-03-20 19:36:06
|
Keith Whitwell wrote: > > Brian Paul wrote: > > > > CVSROOT: /cvsroot/dri > > Module name: xc > > Repository: xc/xc/lib/GL/mesa/src/drv/tdfx/ > > Changes by: brianp@usw-pr-cvs1. 01/03/20 10:05:48 > > > > Log message: > > Remove last of the dependencies on Mesa from dri_mesa.[ch]. This glue > > code could now be used by non-Mesa drivers. > > Replace CreateWindowBuffer() and CreatePixmapBuffer() with CreateBuffer(). > > Added DestroyBuffer(). > > > > We should rename the files to reflect this. Right. The last bit of work in this clean-up effort is to rename the __driMesa*() functions to something more neutral, like _driDriver*() and move/rename dri_mesa.[ch] to a more appropriate place. I've been discussing this with Kevin. We're thinking that lib/GL/dri/dri_util.[ch] would be a good place. Leaving it below lib/GL/mesa/ falsely implies a dependency on Mesa. -Brian |
From: Gareth H. <ga...@va...> - 2001-03-22 01:06:18
|
Brian Paul wrote: > > CVSROOT: /cvsroot/dri > Module name: xc > Repository: xc/xc/lib/GL/mesa/src/drv/tdfx/ > Changes by: brianp@usw-pr-cvs1. 01/03/21 12:50:45 > > Log message: > new teximage code. driver compiles but not working yet Please don't worry about this. I'm going to merge the trunk into the branch today or tomorrow and will take care of the tdfx driver then (I'm going to investigate the current problems post-XFree86 merge first). -- Gareth |
From: Keith W. <ke...@va...> - 2001-03-22 17:09:44
|
Gareth Hughes wrote: > > CVSROOT: /cvsroot/dri > Module name: xc > Repository: xc/xc/lib/GL/mesa/src/drv/radeon/ > Changes by: gareth@usw-pr-cvs1. 01/03/22 09:00:23 > > Log message: > Do we need to pass on the line stipple counter reset to swrast? > > Modified files: > xc/xc/lib/GL/mesa/src/drv/radeon/: Tag: mesa-3-5-branch > radeon_tris.c > > Revision Changes Path > 1.2.4.21 +8 -1 xc/xc/lib/GL/mesa/src/drv/radeon/radeon_tris.c Gareth, You only need to pass the reset onto swrast if you are going to draw software lines. The current driver only does this when rmesa->Fallback is non-zero. Thus I'd suggest: - Swap between radeonResetLineStipple and _swrast_ResetLineStipple in radeonFallback() - Call _swrast_ResetLineStipple() once from radeonFallback(), when it is being installed. This may not be necessary as fallbacks should occur outside begin/end objects on the radeon, so stipple should always be reset. I'd just do it anyway. Keith |
From: Gareth H. <ga...@va...> - 2001-03-22 17:23:18
|
Keith Whitwell wrote: > > Gareth, > > You only need to pass the reset onto swrast if you are going to draw software > lines. The current driver only does this when rmesa->Fallback is non-zero. > Thus I'd suggest: > > - Swap between radeonResetLineStipple and _swrast_ResetLineStipple in > radeonFallback() > - Call _swrast_ResetLineStipple() once from radeonFallback(), when it is being > installed. This may not be necessary as fallbacks should occur outside > begin/end objects on the radeon, so stipple should always be reset. I'd just > do it anyway. Thanks, Keith. I hadn't put much thought into it, I just left that as a reminder to come back to it later. And when I do, I'll do what you describe... -- Gareth |
From: Keith W. <ke...@va...> - 2001-03-22 17:32:29
|
Gareth Hughes wrote: > > Keith Whitwell wrote: > > > > Gareth, > > > > You only need to pass the reset onto swrast if you are going to draw software > > lines. The current driver only does this when rmesa->Fallback is non-zero. > > Thus I'd suggest: > > > > - Swap between radeonResetLineStipple and _swrast_ResetLineStipple in > > radeonFallback() > > - Call _swrast_ResetLineStipple() once from radeonFallback(), when it is being > > installed. This may not be necessary as fallbacks should occur outside > > begin/end objects on the radeon, so stipple should always be reset. I'd just > > do it anyway. > > Thanks, Keith. I hadn't put much thought into it, I just left that as a > reminder to come back to it later. And when I do, I'll do what you > describe... How certain are you that we won't need any of the POINT_FALLBACK, LINE_FALLBACK, etc code again? I've just cut out a bunch of dead stuff in the latest driver & can add those little changes & commit, if you like. Keith |
From: Gareth H. <ga...@va...> - 2001-03-22 17:39:38
|
Keith Whitwell wrote: > > How certain are you that we won't need any of the POINT_FALLBACK, > LINE_FALLBACK, etc code again? I've just cut out a bunch of dead stuff in the > latest driver & can add those little changes & commit, if you like. I had just left it in there for now, and was going to do this at some point as well. I'm still as certain as I can be that we don't have any rasterization fallbacks, with the caveat that we need to test the conformance of line and tri AA and so on. I'd be very, very surprised if the hardware itself was not OpenGL conformant, and so any failures are likely our fault. If you want, rip it out. I like deleting code almost as much as writing it, and we have it in CVS anyway... -- Gareth |
From: Keith W. <ke...@va...> - 2001-03-22 17:55:23
|
Gareth Hughes wrote: > > Keith Whitwell wrote: > > > > How certain are you that we won't need any of the POINT_FALLBACK, > > LINE_FALLBACK, etc code again? I've just cut out a bunch of dead stuff in the > > latest driver & can add those little changes & commit, if you like. > > I had just left it in there for now, and was going to do this at some > point as well. I'm still as certain as I can be that we don't have any > rasterization fallbacks, with the caveat that we need to test the > conformance of line and tri AA and so on. I'd be very, very surprised > if the hardware itself was not OpenGL conformant, and so any failures > are likely our fault. > > If you want, rip it out. I like deleting code almost as much as writing > it, and we have it in CVS anyway... Gareth, Have you got some uncommitted code: radeon_ioctl.c: In function `radeonClear': radeon_ioctl.c:636: structure has no member named `hardware' make: *** [radeon_ioctl.o] Error 1 The line is: if ( (mask & DD_STENCIL_BIT) && rmesa->state.stencil.hardware ) { Keith |
From: Gareth H. <ga...@va...> - 2001-03-23 04:16:53
|
Keith Whitwell wrote: > > Gareth, > > Have you got some uncommitted code: > > radeon_ioctl.c: In function `radeonClear': > radeon_ioctl.c:636: structure has no member named `hardware' > make: *** [radeon_ioctl.o] Error 1 > > The line is: > > if ( (mask & DD_STENCIL_BIT) && rmesa->state.stencil.hardware ) { Sorry, I changed the variable name and forgot to fix it in this #if 0'd out part. Thanks! -- Gareth |
From: Keith W. <ke...@va...> - 2001-03-23 04:20:02
|
Gareth Hughes wrote: > > Keith Whitwell wrote: > > > > Gareth, > > > > Have you got some uncommitted code: > > > > radeon_ioctl.c: In function `radeonClear': > > radeon_ioctl.c:636: structure has no member named `hardware' > > make: *** [radeon_ioctl.o] Error 1 > > > > The line is: > > > > if ( (mask & DD_STENCIL_BIT) && rmesa->state.stencil.hardware ) { > > Sorry, I changed the variable name and forgot to fix it in this #if 0'd > out part. Thanks! I #if 0'd it so it would compile. You proabably want to remove the #if directive. Keith |
From: Gareth H. <ga...@va...> - 2001-03-23 04:23:40
|
Keith Whitwell wrote: > > Gareth Hughes wrote: > > > > Sorry, I changed the variable name and forgot to fix it in this #if 0'd > > out part. Thanks! > > I #if 0'd it so it would compile. You proabably want to remove the #if > directive. Hmmm, that is odd. Sorry, must have messed up the commit somehow... -- Gareth |
From: Gareth H. <ga...@va...> - 2001-04-02 14:38:52
|
Alan Hourihane wrote: > > CVSROOT: /cvsroot/dri > Module name: xc > Repository: xc/xc/lib/GL/mesa/src/X86/ > Changes by: alanh@usw-pr-cvs1. 01/04/02 07:26:55 > > Log message: > allow matypes.h to be autogenerated Alan, you're a legend :-) -- Gareth |
From: Brian P. <br...@va...> - 2001-04-30 14:21:47
|
Alan Hourihane wrote: > > CVSROOT: /cvsroot/dri > Module name: xc > Repository: xc/xc/lib/GL/mesa/dri/ > Changes by: alanh@usw-pr-cvs1. 01/04/30 02:21:57 > > Log message: > include glheader.h instead of glcore.h to pickup define of CAPI. > > Modified files: > xc/xc/lib/GL/mesa/dri/: Tag: mesa-3-5-branch > dri_mesa.h > > Revision Changes Path > 1.6.40.6 +1 -1 xc/xc/lib/GL/mesa/dri/dri_mesa.h I'm going to undo this, Alan. dri_mesa.[ch] shouldn't include or depend upon any Mesa files. -Brian |
From: Alan H. <aho...@va...> - 2001-04-30 14:49:35
|
On Mon, Apr 30, 2001 at 08:25:59AM -0600, Brian Paul wrote: > Alan Hourihane wrote: > > > > CVSROOT: /cvsroot/dri > > Module name: xc > > Repository: xc/xc/lib/GL/mesa/dri/ > > Changes by: alanh@usw-pr-cvs1. 01/04/30 02:21:57 > > > > Log message: > > include glheader.h instead of glcore.h to pickup define of CAPI. > > > > Modified files: > > xc/xc/lib/GL/mesa/dri/: Tag: mesa-3-5-branch > > dri_mesa.h > > > > Revision Changes Path > > 1.6.40.6 +1 -1 xc/xc/lib/GL/mesa/dri/dri_mesa.h > > I'm going to undo this, Alan. dri_mesa.[ch] shouldn't include > or depend upon any Mesa files. > O.k. Are we going to move them out of mesa/dri then ? and rename the files ? Alan. |
From: Brian P. <br...@va...> - 2001-04-30 14:51:16
|
Alan Hourihane wrote: > > On Mon, Apr 30, 2001 at 08:25:59AM -0600, Brian Paul wrote: > > Alan Hourihane wrote: > > > > > > CVSROOT: /cvsroot/dri > > > Module name: xc > > > Repository: xc/xc/lib/GL/mesa/dri/ > > > Changes by: alanh@usw-pr-cvs1. 01/04/30 02:21:57 > > > > > > Log message: > > > include glheader.h instead of glcore.h to pickup define of CAPI. > > > > > > Modified files: > > > xc/xc/lib/GL/mesa/dri/: Tag: mesa-3-5-branch > > > dri_mesa.h > > > > > > Revision Changes Path > > > 1.6.40.6 +1 -1 xc/xc/lib/GL/mesa/dri/dri_mesa.h > > > > I'm going to undo this, Alan. dri_mesa.[ch] shouldn't include > > or depend upon any Mesa files. > > > O.k. Are we going to move them out of mesa/dri then ? and rename the files ? > > Alan. I was planning to do that after we do a merge from the trunk in order to get David's lib/GL build changes. Though I suppose I could do that by hand sooner. -Brian |
From: Brian P. <br...@va...> - 2001-04-30 19:50:14
|
Brian Paul wrote: > > Alan Hourihane wrote: > > > > On Mon, Apr 30, 2001 at 08:25:59AM -0600, Brian Paul wrote: > > > Alan Hourihane wrote: > > > > > > > > CVSROOT: /cvsroot/dri > > > > Module name: xc > > > > Repository: xc/xc/lib/GL/mesa/dri/ > > > > Changes by: alanh@usw-pr-cvs1. 01/04/30 02:21:57 > > > > > > > > Log message: > > > > include glheader.h instead of glcore.h to pickup define of CAPI. > > > > > > > > Modified files: > > > > xc/xc/lib/GL/mesa/dri/: Tag: mesa-3-5-branch > > > > dri_mesa.h > > > > > > > > Revision Changes Path > > > > 1.6.40.6 +1 -1 xc/xc/lib/GL/mesa/dri/dri_mesa.h > > > > > > I'm going to undo this, Alan. dri_mesa.[ch] shouldn't include > > > or depend upon any Mesa files. > > > > > O.k. Are we going to move them out of mesa/dri then ? and rename the files ? > > > > Alan. > > I was planning to do that after we do a merge from the trunk in > order to get David's lib/GL build changes. Though I suppose I could > do that by hand sooner. I'm working on this now. -Brian |
From: Alan H. <aho...@va...> - 2001-04-30 19:55:47
|
On Mon, Apr 30, 2001 at 01:54:22PM -0600, Brian Paul wrote: > Brian Paul wrote: > > > > Alan Hourihane wrote: > > > > > > On Mon, Apr 30, 2001 at 08:25:59AM -0600, Brian Paul wrote: > > > > Alan Hourihane wrote: > > > > > > > > > > CVSROOT: /cvsroot/dri > > > > > Module name: xc > > > > > Repository: xc/xc/lib/GL/mesa/dri/ > > > > > Changes by: alanh@usw-pr-cvs1. 01/04/30 02:21:57 > > > > > > > > > > Log message: > > > > > include glheader.h instead of glcore.h to pickup define of CAPI. > > > > > > > > > > Modified files: > > > > > xc/xc/lib/GL/mesa/dri/: Tag: mesa-3-5-branch > > > > > dri_mesa.h > > > > > > > > > > Revision Changes Path > > > > > 1.6.40.6 +1 -1 xc/xc/lib/GL/mesa/dri/dri_mesa.h > > > > > > > > I'm going to undo this, Alan. dri_mesa.[ch] shouldn't include > > > > or depend upon any Mesa files. > > > > > > > O.k. Are we going to move them out of mesa/dri then ? and rename the files ? > > > > > > Alan. > > > > I was planning to do that after we do a merge from the trunk in > > order to get David's lib/GL build changes. Though I suppose I could > > do that by hand sooner. > > I'm working on this now. Thanks Brian. That'll reduce some confusion. Alan. |
From: Keith W. <ke...@va...> - 2001-06-01 16:30:42
|
Brian Paul wrote: > > CVSROOT: /cvsroot/dri > Module name: xc > Repository: xc/xc/lib/GL/mesa/src/drv/tdfx/ > Changes by: brianp@usw-pr-cvs1. 01/06/01 09:21:32 > > Log message: > removed multipass loop from render tab functions, fixes gloss, spectex, etc The loop should stay -- it may be broken, but it should be fixable -- it's required for iterating over cliprects in the driver. Keith |
From: Brian P. <br...@va...> - 2001-06-01 16:48:26
|
Keith Whitwell wrote: > > Brian Paul wrote: > > > > CVSROOT: /cvsroot/dri > > Module name: xc > > Repository: xc/xc/lib/GL/mesa/src/drv/tdfx/ > > Changes by: brianp@usw-pr-cvs1. 01/06/01 09:21:32 > > > > Log message: > > removed multipass loop from render tab functions, fixes gloss, spectex, etc > > The loop should stay -- it may be broken, but it should be fixable -- it's > required for iterating over cliprects in the driver. It's redundant. The multipass clip loop is already done at a higher level via the tnl run_render() function. As it was, primitives were being rendered 2X times. Apps which did blending, like gloss, were showing the problem. It appears to me that the tdfx_render_vb_*() functions can only be called via the tnl->Driver.RenderTabVerts pointer and that pointer is only used inside the multipass loop in run_render(). If there's another way for the tdfx_render_vb_*() functions to be called then we've got a problem to fix. -Brian |
From: Keith W. <ke...@va...> - 2001-06-01 16:51:38
|
Brian Paul wrote: > > Keith Whitwell wrote: > > > > Brian Paul wrote: > > > > > > CVSROOT: /cvsroot/dri > > > Module name: xc > > > Repository: xc/xc/lib/GL/mesa/src/drv/tdfx/ > > > Changes by: brianp@usw-pr-cvs1. 01/06/01 09:21:32 > > > > > > Log message: > > > removed multipass loop from render tab functions, fixes gloss, spectex, etc > > > > The loop should stay -- it may be broken, but it should be fixable -- it's > > required for iterating over cliprects in the driver. > > It's redundant. The multipass clip loop is already done at a higher > level via the tnl run_render() function. As it was, primitives were > being rendered 2X times. Apps which did blending, like gloss, were > showing the problem. > > It appears to me that the tdfx_render_vb_*() functions can only be > called via the tnl->Driver.RenderTabVerts pointer and that pointer > is only used inside the multipass loop in run_render(). If there's > another way for the tdfx_render_vb_*() functions to be called then > we've got a problem to fix. No, that sounds correct... I just had a braino... Thanks, Keith |
From: Keith W. <ke...@va...> - 2001-06-07 16:56:12
|
Brian Paul wrote: > > CVSROOT: /cvsroot/dri > Module name: xc > Repository: xc/xc/lib/GL/mesa/src/drv/tdfx/ > Changes by: brianp@usw-pr-cvs1. 01/06/07 09:46:17 > > Log message: > add divide by zero checks to fix occasional clipping bugs in Q3 > > Modified files: > xc/xc/lib/GL/mesa/src/drv/tdfx/: Tag: mesa-3-5-branch > tdfx_vbtmp.h > Have you traced the source of these zero oow values? Any vertex with clip w == 0 should have clipmask != 0, therefore in tdfx_vbtmp.h if (mask[i] == 0) { /* unclipped */ v->v.x = s[0] * proj[0][0] + s[12]; v->v.y = s[5] * proj[0][1] + s[13]; v->v.z = s[10] * proj[0][2] + s[14]; v->v.rhw = proj[0][3]; } else { /* clipped */ v->v.rhw = 1.0; } the vertex oow value will be assigned 1.0. Any ideas what's going wrong? Keith |
From: Brian P. <br...@va...> - 2001-06-07 17:07:18
|
Keith Whitwell wrote: > > Brian Paul wrote: > > > > CVSROOT: /cvsroot/dri > > Module name: xc > > Repository: xc/xc/lib/GL/mesa/src/drv/tdfx/ > > Changes by: brianp@usw-pr-cvs1. 01/06/07 09:46:17 > > > > Log message: > > add divide by zero checks to fix occasional clipping bugs in Q3 > > > > Modified files: > > xc/xc/lib/GL/mesa/src/drv/tdfx/: Tag: mesa-3-5-branch > > tdfx_vbtmp.h > > > > Have you traced the source of these zero oow values? Any vertex with clip w > == 0 should have clipmask != 0, therefore in tdfx_vbtmp.h > > if (mask[i] == 0) { > /* unclipped */ > v->v.x = s[0] * proj[0][0] + s[12]; > v->v.y = s[5] * proj[0][1] + s[13]; > v->v.z = s[10] * proj[0][2] + s[14]; > v->v.rhw = proj[0][3]; > } else { > /* clipped */ > v->v.rhw = 1.0; > } > > the vertex oow value will be assigned 1.0. Any ideas what's going wrong? I found that dstclip[3] in the tdfx interp function was sometimes zero. This value is interpolated from the 'in' and 'out' coordinates by the INTERP_4F macro. The divide by zero resulted in 'inf' values and later 'nan' texture coordinates. I also found that the 'out' vertex rhw was also zero sometimes so I applied the same divide by zero check to the wout computation. It does seem strange that out->v.rhw would be zero, as you said. I've already spent too much time on this but I might take a second look. -Brian |
From: Zephaniah E\. H. <wa...@ba...> - 2001-06-25 00:51:55
|
I can verify the unreal engine issues, though I have not had the time to test mesa-3-5-branch, if needed I can also try to help pin down what unreal is doing which nothing else does. (I'm seeing it in both the Rune and DeusEx ports, other problems with the ports have kept me busy debugging things so I have not poked at it too much from that side.) Zephaniah E. Hull. On Sun, Jun 24, 2001 at 11:45:32PM +0200, Dieter N?tzel wrote: > Hello Brian, hello Alan, >=20 > now after that the mesa-3-5-branch is updated with the trunk we "only" ne= ed > Alan's fixes for the 4.1.0 tdfx driver plus the fixing of the remaining t= dfx > (Voodoo5) UT texture bugs (picture is available). >=20 > * context switching fix (the Khoros Pro 2001 thing) >=20 > * (texture) memory calculation/reservation fix (the KDE KPager texture > corruption problem) >=20 > * Xv bilinear filtering doesn't work above 1024x768x24 >=20 > UT crash with the latest mesa-3-5-branch after some seconds. > It starts OK but you can look through all walls and objects. After some > seconds the whole X server hang and I have to reset or reboot. Most of the > time the magic keys do not work. Luckily I have ReiserFS running fine...:= -) >=20 > Regards, > Dieter >=20 > BTW Excuse me if you get this twice. I had my mail configuration wrong. >=20 > _______________________________________________ > Dri-devel mailing list > Dri...@li... > http://lists.sourceforge.net/lists/listinfo/dri-devel >=20 --=20 1024D/E65A7801 Zephaniah E. Hull <wa...@ba...> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. Why blow away at a partition when you can chip away at it? I now present a script I just wrote that writes random bits of, well random bits, into random places in your favorite partition or file. For best (meaning most spectacular) results, use while the database or filesystem is in active use. Disclaimer: This code is untested, and it may or may not trash your filesystem and/or database. While at least a half-assed effort has been made to ensure that it works as designed, there is no guarantee that its use will result in a loss of important data. I am not liable for the lack of either direct or incidental damages. -- Logan Shaw on ASR. |
From: Derrik P. <dp...@ds...> - 2001-06-25 20:40:33
|
On Sun, 24 Jun 2001, Dieter N=FCtzel wrote: > now after that the mesa-3-5-branch is updated with the trunk we "only" ne= ed > Alan's fixes for the 4.1.0 tdfx driver plus the fixing of the remaining t= dfx > (Voodoo5) UT texture bugs (picture is available). Thought I'd also mention some texture corruption (albeit more minor) with a Voodoo5 running Quake3 on XF 4.1.0 - the textures on the faces of the steps in several places are corrupted. In one level, I could see the (reversed) image of the "Skirmish" button from the stage selection menu. So, it's not just in the UT engine (although the UT engine seems to make it far more prominent than other 3D game engines). Derrik Pates | Sysadmin, Douglas School | #linuxOS on EFnet dp...@ds... | District (dsdk12.net) | #linuxOS on OPN |