On Sun, 09 Feb 2003 09:53:55 -0700
Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Felix Kühling wrote:
> > 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.
>
> 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____
[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
