Felix Kühling wrote:
Actually I don't like this one so much -- that condition will *always* be true, I think. I'm confused as to what is actually happening & have to sit down & look at this more...On Sun, 9 Feb 2003 18:43:16 +0100 Felix Kühling <[EMAIL PROTECTED]> wrote:On Sun, 09 Feb 2003 09:53:55 -0700 Keith Whitwell <[EMAIL PROTECTED]> wrote:Felix Kühling wrote:[snip]How about this diff to fire the vertices at the time the state changes? I think this is the root cause of the problems: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. 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 ... ;-)
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
