From: Felix <fx...@gm...> - 2003-02-09 11:55:03
Attachments:
texturetest.c
|
Hi, I tracked down a problem that caused the rpm and speed meters in Torcs to be invisible if TCL was disabled. I think it boils down to a missing radeonEmitState. It is possible that radeonEmitState is not called after ValidateState has updated the state atoms and before the first primitive with the new state is emitted. Adding a radeonEmitState at the end of radeonValidateState fixes the problem but I'm not sure this is the right place. It also fixes a flashing texture problem reported with Quake3 (on Radeon VE or with TCL disabled) a long time ago. In many cases, especially with TCL enabled there seem to be enough radeonEmitState and RADEON_FIREVERTICES calls scattered throughout the driver to never cause problems. Maybe some of them are no longer necessary if state is emitted in radeonValidataState. I attached a small commented example programme that demonstrates the problem if TCL is disabled. Regards, Felix __\|/__ ___ ___ ___ __Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____ fx...@gm... >o<__/ \___/ \___/ at the same time! |
From: Keith W. <ke...@tu...> - 2003-02-09 14:32:01
|
Felix K=FChling wrote: > Hi, >=20 > I tracked down a problem that caused the rpm and speed meters in Torcs > to be invisible if TCL was disabled. I think it boils down to a missing > radeonEmitState. It is possible that radeonEmitState is not called afte= r > ValidateState has updated the state atoms and before the first primitiv= e > with the new state is emitted. Adding a radeonEmitState at the end of > radeonValidateState fixes the problem but I'm not sure this is the righ= t > place. It also fixes a flashing texture problem reported with Quake3 (o= n > Radeon VE or with TCL disabled) a long time ago. In many cases, > especially with TCL enabled there seem to be enough radeonEmitState and > RADEON_FIREVERTICES calls scattered throughout the driver to never caus= e > problems. Maybe some of them are no longer necessary if state is emitte= d > in radeonValidataState. I'll have a look at the demo in a sec. The idea of radeonEmitState is that it should be called immediately prior= to=20 any rendering command -- eg firing vertices, clearing buffers or maybe ev= en=20 swapping buffers. These correspond to radeonEmitVbufPrim &=20 radeonAllocEltsOpenEnded (which actually starts a render packet),=20 radeonClear(), and radeonCopyBuffers/radeonPageFlip. The only one of these that doesn't call radeonEmitState is the swapbuffer= s=20 code -- radeonCopyBuffers/radeonPageFlip. Anyway, the point of the state system is to gather as many statechanges a= s=20 possible into the dirty list and then emit them all at once at the last=20 possible moment before we send something to the hardware that actually re= lies=20 on that state. It seems that at some point we must be forgetting to do t= his -=20 or perhaps that turning of tcl somehow breaks this process. I'll have a play with the demo & see what I can find. Keith |
From: Felix <fx...@gm...> - 2003-02-09 16:29:31
|
On Sun, 09 Feb 2003 07:32:38 -0700 Keith Whitwell <ke...@tu...> wrote: > Felix Kühling wrote: > > Hi, > > > > I tracked down a problem that caused the rpm and speed meters in Torcs > > to be invisible if TCL was disabled. I think it boils down to a missing > > radeonEmitState. It is possible that radeonEmitState is not called after > > ValidateState has updated the state atoms and before the first primitive > > with the new state is emitted. Adding a radeonEmitState at the end of > > radeonValidateState fixes the problem but I'm not sure this is the right > > place. It also fixes a flashing texture problem reported with Quake3 (on > > Radeon VE or with TCL disabled) a long time ago. In many cases, > > especially with TCL enabled there seem to be enough radeonEmitState and > > RADEON_FIREVERTICES calls scattered throughout the driver to never cause > > problems. Maybe some of them are no longer necessary if state is emitted > > in radeonValidataState. > > > I'll have a look at the demo in a sec. > > The idea of radeonEmitState is that it should be called immediately prior to > any rendering command -- eg firing vertices, clearing buffers or maybe even > swapping buffers. These correspond to radeonEmitVbufPrim & > radeonAllocEltsOpenEnded (which actually starts a render packet), > radeonClear(), and radeonCopyBuffers/radeonPageFlip. > > The only one of these that doesn't call radeonEmitState is the swapbuffers > code -- radeonCopyBuffers/radeonPageFlip. > > Anyway, the point of the state system is to gather as many statechanges as > possible into the dirty list and then emit them all at once at the last > possible moment before we send something to the hardware that actually relies > on that state. It seems that at some point we must be forgetting to do this - > or perhaps that turning of tcl somehow breaks this process. Hmm ... I figured what the state buffering with clean and dirty state lists is good for. I just didn't think it is so aggressive. So state changes can occur after ValidateState? Anyway, I think I found the *real* problem, this time :). Indeed radeonEmitVbufPrim is called to flush the pending vertex buffer and it emits the state. However, at that time (in my demo) texturing is already disabled and therefore the texture state is skipped. Thus the primitive is rendered with the old texture. As a workaround I replaced the texture state check with ALWAYS in radeon_stateinit.c. Maybe there is a better way to this? The problem is that ctx->Texture.Unit[?]._ReallyEnabled is not pipelined. So if you wanted to avoid unnecessary texture state emissions you would have to associate the texture-unit-enabled flag with the pending vertex buffer somehow. > > I'll have a play with the demo & see what I can find. > > Keith > Felix __\|/__ ___ ___ ___ __Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____ fx...@gm... >o<__/ \___/ \___/ at the same time! |
From: Keith W. <ke...@tu...> - 2003-02-09 16:53:17
|
Felix K=FChling wrote: > On Sun, 09 Feb 2003 07:32:38 -0700 > Keith Whitwell <ke...@tu...> wrote: >=20 >=20 >>Felix K=FChling wrote: >> >>>Hi, >>> >>>I tracked down a problem that caused the rpm and speed meters in Torcs >>>to be invisible if TCL was disabled. I think it boils down to a missin= g >>>radeonEmitState. It is possible that radeonEmitState is not called aft= er >>>ValidateState has updated the state atoms and before the first primiti= ve >>>with the new state is emitted. Adding a radeonEmitState at the end of >>>radeonValidateState fixes the problem but I'm not sure this is the rig= ht >>>place. It also fixes a flashing texture problem reported with Quake3 (= on >>>Radeon VE or with TCL disabled) a long time ago. In many cases, >>>especially with TCL enabled there seem to be enough radeonEmitState an= d >>>RADEON_FIREVERTICES calls scattered throughout the driver to never cau= se >>>problems. Maybe some of them are no longer necessary if state is emitt= ed >>>in radeonValidataState. >> >> >>I'll have a look at the demo in a sec. >> >>The idea of radeonEmitState is that it should be called immediately pri= or to=20 >>any rendering command -- eg firing vertices, clearing buffers or maybe = even=20 >>swapping buffers. These correspond to radeonEmitVbufPrim &=20 >>radeonAllocEltsOpenEnded (which actually starts a render packet),=20 >>radeonClear(), and radeonCopyBuffers/radeonPageFlip. >> >>The only one of these that doesn't call radeonEmitState is the swapbuff= ers=20 >>code -- radeonCopyBuffers/radeonPageFlip. >> >>Anyway, the point of the state system is to gather as many statechanges= as=20 >>possible into the dirty list and then emit them all at once at the last= =20 >>possible moment before we send something to the hardware that actually = relies=20 >>on that state. It seems that at some point we must be forgetting to do= this -=20 >>or perhaps that turning of tcl somehow breaks this process. >=20 >=20 > Hmm ... I figured what the state buffering with clean and dirty state > lists is good for. I just didn't think it is so aggressive. So state > changes can occur after ValidateState? >=20 > Anyway, I think I found the *real* problem, this time :). Indeed > radeonEmitVbufPrim is called to flush the pending vertex buffer and it > emits the state. However, at that time (in my demo) texturing is alread= y > disabled and therefore the texture state is skipped. Thus the primitive > is rendered with the old texture. As a workaround I replaced the textur= e > state check with ALWAYS in radeon_stateinit.c. Maybe there is a better > way to this? The problem is that ctx->Texture.Unit[?]._ReallyEnabled is > not pipelined. So if you wanted to avoid unnecessary texture state > emissions you would have to associate the texture-unit-enabled flag wit= h > the pending vertex buffer somehow. How about this diff to fire the vertices at the time the state changes? = I=20 think this is the root cause of the problems: Keith diff -u -r1.1.2.7 radeon_state.c --- radeon_state.c 7 Feb 2003 20:22:16 -0000 1.1.2.7 +++ radeon_state.c 9 Feb 2003 16:52:03 -0000 @@ -990,6 +990,7 @@ case GL_TEXTURE_1D: case GL_TEXTURE_2D: case GL_TEXTURE_3D: + RADEON_FIREVERTICES( rmesa ); break; case GL_ALPHA_TEST: |
From: Felix <fx...@gm...> - 2003-02-09 17:43:28
|
On Sun, 09 Feb 2003 09:53:55 -0700 Keith Whitwell <ke...@tu...> wrote: > Felix Kühling wrote: > > On Sun, 09 Feb 2003 07:32:38 -0700 > > Keith Whitwell <ke...@tu...> wrote: > > > > > >>Felix Kühling wrote: > >> > >>>Hi, > >>> > >>>I tracked down a problem that caused the rpm and speed meters in Torcs > >>>to be invisible if TCL was disabled. I think it boils down to a missing > >>>radeonEmitState. It is possible that radeonEmitState is not called after > >>>ValidateState has updated the state atoms and before the first primitive > >>>with the new state is emitted. Adding a radeonEmitState at the end of > >>>radeonValidateState fixes the problem but I'm not sure this is the right > >>>place. It also fixes a flashing texture problem reported with Quake3 (on > >>>Radeon VE or with TCL disabled) a long time ago. In many cases, > >>>especially with TCL enabled there seem to be enough radeonEmitState and > >>>RADEON_FIREVERTICES calls scattered throughout the driver to never cause > >>>problems. Maybe some of them are no longer necessary if state is emitted > >>>in radeonValidataState. > >> > >> > >>I'll have a look at the demo in a sec. > >> > >>The idea of radeonEmitState is that it should be called immediately prior to > >>any rendering command -- eg firing vertices, clearing buffers or maybe even > >>swapping buffers. These correspond to radeonEmitVbufPrim & > >>radeonAllocEltsOpenEnded (which actually starts a render packet), > >>radeonClear(), and radeonCopyBuffers/radeonPageFlip. > >> > >>The only one of these that doesn't call radeonEmitState is the swapbuffers > >>code -- radeonCopyBuffers/radeonPageFlip. > >> > >>Anyway, the point of the state system is to gather as many statechanges as > >>possible into the dirty list and then emit them all at once at the last > >>possible moment before we send something to the hardware that actually relies > >>on that state. It seems that at some point we must be forgetting to do this - > >>or perhaps that turning of tcl somehow breaks this process. > > > > > > Hmm ... I figured what the state buffering with clean and dirty state > > lists is good for. I just didn't think it is so aggressive. So state > > changes can occur after ValidateState? > > > > Anyway, I think I found the *real* problem, this time :). Indeed > > radeonEmitVbufPrim is called to flush the pending vertex buffer and it > > emits the state. However, at that time (in my demo) texturing is already > > disabled and therefore the texture state is skipped. Thus the primitive > > is rendered with the old texture. As a workaround I replaced the texture > > state check with ALWAYS in radeon_stateinit.c. Maybe there is a better > > way to this? The problem is that ctx->Texture.Unit[?]._ReallyEnabled is > > not pipelined. So if you wanted to avoid unnecessary texture state > > emissions you would have to associate the texture-unit-enabled flag with > > the pending vertex buffer somehow. > > How about this diff to fire the vertices at the time the state changes? I > think this is the root cause of the problems: > > Keith > > > diff -u -r1.1.2.7 radeon_state.c > --- radeon_state.c 7 Feb 2003 20:22:16 -0000 1.1.2.7 > +++ radeon_state.c 9 Feb 2003 16:52:03 -0000 > @@ -990,6 +990,7 @@ > case GL_TEXTURE_1D: > case GL_TEXTURE_2D: > case GL_TEXTURE_3D: > + RADEON_FIREVERTICES( rmesa ); > break; > > case GL_ALPHA_TEST: > > > > The patch fixes the problem, all right. But doesn't it undermine the whole purpose of the state buffering if you fire state and vertices on an individual state change? As far as I can see the only state changes which require this so far are the ones that affect the cliprects and PolygonStipple for which there is no state atom. BTW, it looks like there might be similar problems with the other CHECKs and TCL_CHECKs. They all check non-pipelined data from the GL context for whether to emit pipelined state. I may be wrong, though, as I'm still trying to figure out how this is supposed to work. Felix __\|/__ ___ ___ ___ __Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____ fx...@gm... >o<__/ \___/ \___/ at the same time! |
From: Felix <fx...@gm...> - 2003-02-09 18:53:43
|
On Sun, 9 Feb 2003 18:43:16 +0100 Felix Kühling <fx...@gm...> wrote: > On Sun, 09 Feb 2003 09:53:55 -0700 > Keith Whitwell <ke...@tu...> wrote: > > > Felix Kühling wrote: [snip] > > > Anyway, I think I found the *real* problem, this time :). Indeed > > > radeonEmitVbufPrim is called to flush the pending vertex buffer and it > > > emits the state. However, at that time (in my demo) texturing is already > > > disabled and therefore the texture state is skipped. Thus the primitive > > > is rendered with the old texture. As a workaround I replaced the texture > > > state check with ALWAYS in radeon_stateinit.c. Maybe there is a better > > > way to this? The problem is that ctx->Texture.Unit[?]._ReallyEnabled is > > > not pipelined. So if you wanted to avoid unnecessary texture state > > > emissions you would have to associate the texture-unit-enabled flag with > > > the pending vertex buffer somehow. > > > > How about this diff to fire the vertices at the time the state changes? I > > think this is the root cause of the problems: > > > > Keith > > > > > > diff -u -r1.1.2.7 radeon_state.c > > --- radeon_state.c 7 Feb 2003 20:22:16 -0000 1.1.2.7 > > +++ radeon_state.c 9 Feb 2003 16:52:03 -0000 > > @@ -990,6 +990,7 @@ > > case GL_TEXTURE_1D: > > case GL_TEXTURE_2D: > > case GL_TEXTURE_3D: > > + RADEON_FIREVERTICES( rmesa ); > > break; > > > > case GL_ALPHA_TEST: > > > > > > > > > > The patch fixes the problem, all right. But doesn't it undermine the > whole purpose of the state buffering if you fire state and vertices on > an individual state change? As far as I can see the only state changes > which require this so far are the ones that affect the cliprects and > PolygonStipple for which there is no state atom. > > BTW, it looks like there might be similar problems with the other CHECKs > and TCL_CHECKs. They all check non-pipelined data from the GL context > for whether to emit pipelined state. I may be wrong, though, as I'm > still trying to figure out how this is supposed to work. With TCL there is no problem. EMIT_PRIM in radeon_tcl.c calls radeonEmitVbufPrim which emits the state and at this time the GL context matches the buffered hardware state. At the end of radeon_run_tcl_render there is no pending vertex data left. What about the following patch to ensure the same with SW TCL: --- radeon_swtcl.c 25 Nov 2002 19:58:29 -0000 1.10 +++ radeon_swtcl.c 9 Feb 2003 18:47:41 -0000 @@ -1054,6 +1054,9 @@ static void radeonRenderFinish( GLcontext *ctx ) { + radeonContextPtr rmesa = RADEON_CONTEXT(ctx); + if (rmesa->dma.flush != 0) + rmesa->dma.flush( rmesa ); } static void radeonResetLineStipple( GLcontext *ctx ) Counting the fourth patch to solve the same problem now. I think we're getting closer ... ;-) Felix __\|/__ ___ ___ ___ __Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____ fx...@gm... >o<__/ \___/ \___/ at the same time! |
From: Keith W. <ke...@tu...> - 2003-02-09 22:41:44
|
Felix K=FChling wrote: > On Sun, 9 Feb 2003 18:43:16 +0100 > Felix K=FChling <fx...@gm...> wrote: >=20 >=20 >>On Sun, 09 Feb 2003 09:53:55 -0700 >>Keith Whitwell <ke...@tu...> wrote: >> >> >>>Felix K=FChling wrote: >> > [snip] >=20 >>>>Anyway, I think I found the *real* problem, this time :). Indeed >>>>radeonEmitVbufPrim is called to flush the pending vertex buffer and i= t >>>>emits the state. However, at that time (in my demo) texturing is alre= ady >>>>disabled and therefore the texture state is skipped. Thus the primiti= ve >>>>is rendered with the old texture. As a workaround I replaced the text= ure >>>>state check with ALWAYS in radeon_stateinit.c. Maybe there is a bette= r >>>>way to this? The problem is that ctx->Texture.Unit[?]._ReallyEnabled = is >>>>not pipelined. So if you wanted to avoid unnecessary texture state >>>>emissions you would have to associate the texture-unit-enabled flag w= ith >>>>the pending vertex buffer somehow. >>> >>>How about this diff to fire the vertices at the time the state changes= ? I=20 >>>think this is the root cause of the problems: >>> >>>Keith >>> >>> >>>diff -u -r1.1.2.7 radeon_state.c >>>--- radeon_state.c 7 Feb 2003 20:22:16 -0000 1.1.2.7 >>>+++ radeon_state.c 9 Feb 2003 16:52:03 -0000 >>>@@ -990,6 +990,7 @@ >>> case GL_TEXTURE_1D: >>> case GL_TEXTURE_2D: >>> case GL_TEXTURE_3D: >>>+ RADEON_FIREVERTICES( rmesa ); >>> break; >>> >>> case GL_ALPHA_TEST: >>> >>> >>> >>> >> >>The patch fixes the problem, all right. But doesn't it undermine the >>whole purpose of the state buffering if you fire state and vertices on >>an individual state change? As far as I can see the only state changes >>which require this so far are the ones that affect the cliprects and >>PolygonStipple for which there is no state atom. >> >>BTW, it looks like there might be similar problems with the other CHECK= s >>and TCL_CHECKs. They all check non-pipelined data from the GL context >>for whether to emit pipelined state. I may be wrong, though, as I'm >>still trying to figure out how this is supposed to work. >=20 >=20 > With TCL there is no problem. EMIT_PRIM in radeon_tcl.c calls > radeonEmitVbufPrim which emits the state and at this time the GL contex= t > matches the buffered hardware state. At the end of radeon_run_tcl_rende= r > there is no pending vertex data left. >=20 > What about the following patch to ensure the same with SW TCL: >=20 > --- radeon_swtcl.c 25 Nov 2002 19:58:29 -0000 1.10 > +++ radeon_swtcl.c 9 Feb 2003 18:47:41 -0000 > @@ -1054,6 +1054,9 @@ > =20 > static void radeonRenderFinish( GLcontext *ctx ) > { > + radeonContextPtr rmesa =3D RADEON_CONTEXT(ctx); > + if (rmesa->dma.flush !=3D 0) > + rmesa->dma.flush( rmesa ); > } > =20 > static void radeonResetLineStipple( GLcontext *ctx ) >=20 > Counting the fourth patch to solve the same problem now. I think we're > getting closer ... ;-) Actually I don't like this one so much -- that condition will *always* be= =20 true, I think. I'm confused as to what is actually happening & have to s= it=20 down & look at this more... Keith |
From: Keith W. <ke...@tu...> - 2003-02-09 22:39:22
|
Felix K=FChling wrote: > On Sun, 09 Feb 2003 09:53:55 -0700 > Keith Whitwell <ke...@tu...> wrote: >=20 >=20 >>Felix K=FChling wrote: >> >>>On Sun, 09 Feb 2003 07:32:38 -0700 >>>Keith Whitwell <ke...@tu...> wrote: >>> >>> >>> >>>>Felix K=FChling wrote: >>>> >>>> >>>>>Hi, >>>>> >>>>>I tracked down a problem that caused the rpm and speed meters in Tor= cs >>>>>to be invisible if TCL was disabled. I think it boils down to a miss= ing >>>>>radeonEmitState. It is possible that radeonEmitState is not called a= fter >>>>>ValidateState has updated the state atoms and before the first primi= tive >>>>>with the new state is emitted. Adding a radeonEmitState at the end o= f >>>>>radeonValidateState fixes the problem but I'm not sure this is the r= ight >>>>>place. It also fixes a flashing texture problem reported with Quake3= (on >>>>>Radeon VE or with TCL disabled) a long time ago. In many cases, >>>>>especially with TCL enabled there seem to be enough radeonEmitState = and >>>>>RADEON_FIREVERTICES calls scattered throughout the driver to never c= ause >>>>>problems. Maybe some of them are no longer necessary if state is emi= tted >>>>>in radeonValidataState. >>>> >>>> >>>>I'll have a look at the demo in a sec. >>>> >>>>The idea of radeonEmitState is that it should be called immediately p= rior to=20 >>>>any rendering command -- eg firing vertices, clearing buffers or mayb= e even=20 >>>>swapping buffers. These correspond to radeonEmitVbufPrim &=20 >>>>radeonAllocEltsOpenEnded (which actually starts a render packet),=20 >>>>radeonClear(), and radeonCopyBuffers/radeonPageFlip. >>>> >>>>The only one of these that doesn't call radeonEmitState is the swapbu= ffers=20 >>>>code -- radeonCopyBuffers/radeonPageFlip. >>>> >>>>Anyway, the point of the state system is to gather as many statechang= es as=20 >>>>possible into the dirty list and then emit them all at once at the la= st=20 >>>>possible moment before we send something to the hardware that actuall= y relies=20 >>>>on that state. It seems that at some point we must be forgetting to = do this -=20 >>>>or perhaps that turning of tcl somehow breaks this process. >>> >>> >>>Hmm ... I figured what the state buffering with clean and dirty state >>>lists is good for. I just didn't think it is so aggressive. So state >>>changes can occur after ValidateState? >>> >>>Anyway, I think I found the *real* problem, this time :). Indeed >>>radeonEmitVbufPrim is called to flush the pending vertex buffer and it >>>emits the state. However, at that time (in my demo) texturing is alrea= dy >>>disabled and therefore the texture state is skipped. Thus the primitiv= e >>>is rendered with the old texture. As a workaround I replaced the textu= re >>>state check with ALWAYS in radeon_stateinit.c. Maybe there is a better >>>way to this? The problem is that ctx->Texture.Unit[?]._ReallyEnabled i= s >>>not pipelined. So if you wanted to avoid unnecessary texture state >>>emissions you would have to associate the texture-unit-enabled flag wi= th >>>the pending vertex buffer somehow. >> >>How about this diff to fire the vertices at the time the state changes?= I=20 >>think this is the root cause of the problems: >> >>Keith >> >> >>diff -u -r1.1.2.7 radeon_state.c >>--- radeon_state.c 7 Feb 2003 20:22:16 -0000 1.1.2.7 >>+++ radeon_state.c 9 Feb 2003 16:52:03 -0000 >>@@ -990,6 +990,7 @@ >> case GL_TEXTURE_1D: >> case GL_TEXTURE_2D: >> case GL_TEXTURE_3D: >>+ RADEON_FIREVERTICES( rmesa ); >> break; >> >> case GL_ALPHA_TEST: >> >> >> >> >=20 >=20 > The patch fixes the problem, all right. But doesn't it undermine the > whole purpose of the state buffering if you fire state and vertices on > an individual state change? No, because no more vertices can accumulate with that (old) state -- you=20 *have* to fire them then. > As far as I can see the only state changes > which require this so far are the ones that affect the cliprects and > PolygonStipple for which there is no state atom. > BTW, it looks like there might be similar problems with the other CHECK= s > and TCL_CHECKs. They all check non-pipelined data from the GL context > for whether to emit pipelined state. I may be wrong, though, as I'm > still trying to figure out how this is supposed to work. Yes, there's something fishy going on. I'm on holiday at the moment, so = I'm=20 not able to dive right into this, but it seems like something needs doing= =20 somewhere... Keith |
From: Michel <mi...@da...> - 2003-02-25 03:04:28
|
On Son, 2003-02-09 at 23:40, Keith Whitwell wrote: > Felix Kühling wrote: > > On Sun, 09 Feb 2003 09:53:55 -0700 > > Keith Whitwell <ke...@tu...> wrote: > > > >>diff -u -r1.1.2.7 radeon_state.c > >>--- radeon_state.c 7 Feb 2003 20:22:16 -0000 1.1.2.7 > >>+++ radeon_state.c 9 Feb 2003 16:52:03 -0000 > >>@@ -990,6 +990,7 @@ > >> case GL_TEXTURE_1D: > >> case GL_TEXTURE_2D: > >> case GL_TEXTURE_3D: > >>+ RADEON_FIREVERTICES( rmesa ); > >> break; > >> > >> case GL_ALPHA_TEST: What became of this? It seems to fix the flag in bzflag having the wrong texture with the r200 driver with SW TCL as well. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
From: Keith W. <ke...@tu...> - 2003-02-25 03:22:13
|
Michel D=E4nzer wrote: > On Son, 2003-02-09 at 23:40, Keith Whitwell wrote: >=20 >>Felix K=FChling wrote: >> >>>On Sun, 09 Feb 2003 09:53:55 -0700 >>>Keith Whitwell <ke...@tu...> wrote: >>> >>> >>>>diff -u -r1.1.2.7 radeon_state.c >>>>--- radeon_state.c 7 Feb 2003 20:22:16 -0000 1.1.2.7 >>>>+++ radeon_state.c 9 Feb 2003 16:52:03 -0000 >>>>@@ -990,6 +990,7 @@ >>>> case GL_TEXTURE_1D: >>>> case GL_TEXTURE_2D: >>>> case GL_TEXTURE_3D: >>>>+ RADEON_FIREVERTICES( rmesa ); >>>> break; >>>> >>>> case GL_ALPHA_TEST: >>> >=20 > What became of this? It seems to fix the flag in bzflag having the wron= g > texture with the r200 driver with SW TCL as well. I think I figured out the underlying problem. In core mesa, all statechanges are preceded by a call to=20 ctx->Driver.FlushVertices(), to ensure all buffered vertices are fired be= fore=20 the state is changed. This is currently set to _tnl_FlushVertices(), whi= ch=20 doesn't do anything to notify the driver about this impending statechange. We should probably wrap _tnl_FlushVertices() and install that instead in=20 ctx->Driver.FlushVertices(). I'll code something up & post a patch. Keith |
From: Andreas S. <A.S...@gm...> - 2003-02-09 22:56:03
|
Hello! yes, this patch helps quake3 in sw-tcl mode (no more flickering of=20 textures). It looks even better than hw-tcl, because hw-tcl shows that "other flickering" when looking to the ground and turning around a bit. But unfortunately it doesnt solve the issue with the invisible player-model in the player settings menu. With softwarerendering (LIBGL_ALWAYS_INDIRECT=3D1) the model is visible. (but q3 unplayable) (quake3 1.31 from dec.2001) Could it be a similar effect that something gets lost when switching between an ortho and a perspective view? regards, Andreas Am 2003.02.09 17:53:55 +0100 schrieb(en) Keith Whitwell: > How about this diff to fire the vertices at the time the state=20 > changes? I think this is the root cause of the problems: >=20 > Keith >=20 >=20 > diff -u -r1.1.2.7 radeon_state.c > --- radeon_state.c 7 Feb 2003 20:22:16 -0000 1.1.2.7 > +++ radeon_state.c 9 Feb 2003 16:52:03 -0000 > @@ -990,6 +990,7 @@ > case GL_TEXTURE_1D: > case GL_TEXTURE_2D: > case GL_TEXTURE_3D: > + RADEON_FIREVERTICES( rmesa ); > break; >=20 > case GL_ALPHA_TEST: >=20 |
From: Keith W. <ke...@tu...> - 2003-02-09 23:12:21
|
Andreas Stenglein wrote: > Hello! > > yes, this patch helps quake3 in sw-tcl mode (no more flickering of > textures). > It looks even better than hw-tcl, because hw-tcl > shows that "other flickering" when looking to the > ground and turning around a bit. > > But unfortunately it doesnt solve the issue with > the invisible player-model in the player settings menu. > With softwarerendering (LIBGL_ALWAYS_INDIRECT=1) the > model is visible. (but q3 unplayable) > (quake3 1.31 from dec.2001) > > Could it be a similar effect that something > gets lost when switching between an ortho and > a perspective view? Andreas, Yes -- I think this opens up a whole class of statechanges that aren't being handled correctly. It's entirely plausible that there are a dozen or more places we need to add FIRE_VERTICES commands. Keith |
From: Keith W. <ke...@tu...> - 2003-02-25 04:13:36
Attachments:
radeon-flush.diff
|
Keith Whitwell wrote: > Michel D=E4nzer wrote: >=20 >> On Son, 2003-02-09 at 23:40, Keith Whitwell wrote: >> >>> Felix K=FChling wrote: >>> >>>> On Sun, 09 Feb 2003 09:53:55 -0700 >>>> Keith Whitwell <ke...@tu...> wrote: >>>> >>>> >>>>> diff -u -r1.1.2.7 radeon_state.c >>>>> --- radeon_state.c 7 Feb 2003 20:22:16 -0000 1.1.2.7 >>>>> +++ radeon_state.c 9 Feb 2003 16:52:03 -0000 >>>>> @@ -990,6 +990,7 @@ >>>>> case GL_TEXTURE_1D: >>>>> case GL_TEXTURE_2D: >>>>> case GL_TEXTURE_3D: >>>>> + RADEON_FIREVERTICES( rmesa ); >>>>> break; >>>>> >>>>> case GL_ALPHA_TEST: >>>> >>>> >> >> What became of this? It seems to fix the flag in bzflag having the wro= ng >> texture with the r200 driver with SW TCL as well. >=20 >=20 > I think I figured out the underlying problem. >=20 > In core mesa, all statechanges are preceded by a call to=20 > ctx->Driver.FlushVertices(), to ensure all buffered vertices are fired=20 > before the state is changed. This is currently set to=20 > _tnl_FlushVertices(), which doesn't do anything to notify the driver=20 > about this impending statechange. >=20 > We should probably wrap _tnl_FlushVertices() and install that instead i= n=20 > ctx->Driver.FlushVertices(). >=20 > I'll code something up & post a patch. >=20 > Keith Can you test this change? Keith |
From: Felix <fx...@gm...> - 2003-02-25 08:11:35
|
On Mon, 24 Feb 2003 21:13:09 -0700 Keith Whitwell <ke...@tu...> wrote: > Keith Whitwell wrote: > > Michel Dänzer wrote: > > > >> On Son, 2003-02-09 at 23:40, Keith Whitwell wrote: > >> > >>> Felix Kühling wrote: > >>> > >>>> On Sun, 09 Feb 2003 09:53:55 -0700 > >>>> Keith Whitwell <ke...@tu...> wrote: > >>>> > >>>> > >>>>> diff -u -r1.1.2.7 radeon_state.c > >>>>> --- radeon_state.c 7 Feb 2003 20:22:16 -0000 1.1.2.7 > >>>>> +++ radeon_state.c 9 Feb 2003 16:52:03 -0000 > >>>>> @@ -990,6 +990,7 @@ > >>>>> case GL_TEXTURE_1D: > >>>>> case GL_TEXTURE_2D: > >>>>> case GL_TEXTURE_3D: > >>>>> + RADEON_FIREVERTICES( rmesa ); > >>>>> break; > >>>>> > >>>>> case GL_ALPHA_TEST: > >>>> > >>>> > >> > >> What became of this? It seems to fix the flag in bzflag having the wrong > >> texture with the r200 driver with SW TCL as well. > > > > > > I think I figured out the underlying problem. > > > > In core mesa, all statechanges are preceded by a call to > > ctx->Driver.FlushVertices(), to ensure all buffered vertices are fired > > before the state is changed. This is currently set to > > _tnl_FlushVertices(), which doesn't do anything to notify the driver > > about this impending statechange. > > > > We should probably wrap _tnl_FlushVertices() and install that instead in > > ctx->Driver.FlushVertices(). > > > > I'll code something up & post a patch. > > > > Keith > > Can you test this change? Strange, this fixes the small test programme I made, but I still have the missing instruments in Torcs that were fixed by the patches we exchanged before. Something's still missing :( > > Keith > Felix __\|/__ ___ ___ ___ __Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____ fx...@gm... >o<__/ \___/ \___/ at the same time! |
From: Michel <mi...@da...> - 2003-02-25 23:57:06
Attachments:
r200-flushvertices.diff
|
On Die, 2003-02-25 at 05:13, Keith Whitwell wrote: > > > > I think I figured out the underlying problem. > > > > In core mesa, all statechanges are preceded by a call to > > ctx->Driver.FlushVertices(), to ensure all buffered vertices are fired > > before the state is changed. This is currently set to > > _tnl_FlushVertices(), which doesn't do anything to notify the driver > > about this impending statechange. > > > > We should probably wrap _tnl_FlushVertices() and install that instead in > > ctx->Driver.FlushVertices(). > > > > I'll code something up & post a patch. > > > > Keith > > Can you test this change? It does fix the problems I saw with SW TCL in the r200 driver. For reference, here's my result of applying the patch to the r200 driver. I suspect there's still a similar bug in the r100 vtxfmt code, causing the wrong textures in armagetron (this patch doesn't help that). -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
From: David B. <dbr...@li...> - 2003-02-25 08:46:41
|
On Mon, 24 Feb 2003 21:13:09 -0700 Keith Whitwell <ke...@tu...> wrote: > >> > >> What became of this? It seems to fix the flag in bzflag having the wrong > >> texture with the r200 driver with SW TCL as well. > > > > > > I think I figured out the underlying problem. > > > > In core mesa, all statechanges are preceded by a call to > > ctx->Driver.FlushVertices(), to ensure all buffered vertices are fired > > before the state is changed. This is currently set to > > _tnl_FlushVertices(), which doesn't do anything to notify the driver > > about this impending statechange. > > > > We should probably wrap _tnl_FlushVertices() and install that instead in > > ctx->Driver.FlushVertices(). > > > > I'll code something up & post a patch. > > > > Keith > > Can you test this change? > > Keith I've tested it. Radeon 7000. I get texture flashing in Quake3 with map q3dm1 in particular, when in the room with the plasma gun. It's pretty spectacular -- floor goes purple and yellow. Not quite sure what to make of it. Screenshot: (1280x1024, sorry, my flat panel made me do it! I swear!) http://bronaugh.linuxboxen.org/q3_glitch.jpg I got this with trunk too, without this patch. Hopefully I'm not hitting a hardware flaw or such in my card (ie, bad ram)... It seems to change a lot with motion (whether it's glitched or not) and also seemingly with time (perhaps lighting?). Can someone else confirm this behaviour? David Bronaugh |
From: Felix <fx...@gm...> - 2003-02-25 09:22:31
|
On Tue, 25 Feb 2003 00:46:36 -0800 David Bronaugh <dbr...@li...> wrote: > On Mon, 24 Feb 2003 21:13:09 -0700 > Keith Whitwell <ke...@tu...> wrote: > > >> > > >> What became of this? It seems to fix the flag in bzflag having the wrong > > >> texture with the r200 driver with SW TCL as well. > > > > > > > > > I think I figured out the underlying problem. > > > > > > In core mesa, all statechanges are preceded by a call to > > > ctx->Driver.FlushVertices(), to ensure all buffered vertices are fired > > > before the state is changed. This is currently set to > > > _tnl_FlushVertices(), which doesn't do anything to notify the driver > > > about this impending statechange. > > > > > > We should probably wrap _tnl_FlushVertices() and install that instead in > > > ctx->Driver.FlushVertices(). > > > > > > I'll code something up & post a patch. > > > > > > Keith > > > > Can you test this change? > > > > Keith > > I've tested it. Radeon 7000. > > I get texture flashing in Quake3 with map q3dm1 in particular, when in the room with the plasma gun. It's pretty spectacular -- floor goes purple and yellow. Not quite sure what to make of it. > > Screenshot: (1280x1024, sorry, my flat panel made me do it! I swear!) > > http://bronaugh.linuxboxen.org/q3_glitch.jpg > > I got this with trunk too, without this patch. Hopefully I'm not hitting a hardware flaw or such in my card (ie, bad ram)... > > It seems to change a lot with motion (whether it's glitched or not) and also seemingly with time (perhaps lighting?). > > Can someone else confirm this behaviour? You're right. It looks like a SWTCL vertex corruption problem I fixed recently by moving tnl->Driver.Render.Start( ctx ) before emitting indexed vertices in radeon_run_render. Somehow this patch reintroduces the problem. Though I don't see how :-/ > > David Bronaugh > Felix __\|/__ ___ ___ ___ __Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____ fx...@gm... >o<__/ \___/ \___/ at the same time! |