Felix K�hling wrote:
No, because no more vertices can accumulate with that (old) state -- you *have* to fire them then.On Sun, 09 Feb 2003 09:53:55 -0700 Keith Whitwell <[EMAIL PROTECTED]> wrote:Felix K�hling wrote:How about this diff to fire the vertices at the time the state changes? I think this is the root cause of the problems:On Sun, 09 Feb 2003 07:32:38 -0700 Keith Whitwell <[EMAIL PROTECTED]> 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.
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.
Yes, there's something fishy going on. I'm on holiday at the moment, so I'm not able to dive right into this, but it seems like something needs doing somewhere...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.
Keith
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
