Re: [Dri-devel] Missing radeonEmitState in radeonValidateState?

[Felix <fx...@gm...>]

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!