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. > > 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____ [EMAIL PROTECTED] >o<__/ \___/ \___/ at the same time! ------------------------------------------------------- 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