Re: [Dri-devel] Missing radeonEmitState in radeonValidateState?
On Mon, 24 Feb 2003 21:13:09 -0700 Keith Whitwell [EMAIL PROTECTED] wrote: Keith Whitwell wrote: Michel Dänzer wrote: On Son, 2003-02-09 at 23:40, Keith Whitwell wrote: Felix Kühling wrote: On Sun, 09 Feb 2003 09:53:55 -0700 Keith Whitwell [EMAIL PROTECTED] wrote: diff -u -r1.1.2.7 radeon_state.c --- radeon_state.c7 Feb 2003 20:22:16 -1.1.2.7 +++ radeon_state.c9 Feb 2003 16:52:03 - @@ -990,6 +990,7 @@ case GL_TEXTURE_1D: case GL_TEXTURE_2D: case GL_TEXTURE_3D: + RADEON_FIREVERTICES( rmesa ); break; case GL_ALPHA_TEST: What became of this? It seems to fix the flag in bzflag having the wrong texture with the r200 driver with SW TCL as well. I think I figured out the underlying problem. In core mesa, all statechanges are preceded by a call to ctx-Driver.FlushVertices(), to ensure all buffered vertices are fired before the state is changed. This is currently set to _tnl_FlushVertices(), which doesn't do anything to notify the driver about this impending statechange. We should probably wrap _tnl_FlushVertices() and install that instead in ctx-Driver.FlushVertices(). I'll code something up post a patch. Keith Can you test this change? Strange, this fixes the small test programme I made, but I still have the missing instruments in Torcs that were fixed by the patches we exchanged before. Something's still missing :( 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Missing radeonEmitState in radeonValidateState?
On Mon, 24 Feb 2003 21:13:09 -0700 Keith Whitwell [EMAIL PROTECTED] wrote: What became of this? It seems to fix the flag in bzflag having the wrong texture with the r200 driver with SW TCL as well. I think I figured out the underlying problem. In core mesa, all statechanges are preceded by a call to ctx-Driver.FlushVertices(), to ensure all buffered vertices are fired before the state is changed. This is currently set to _tnl_FlushVertices(), which doesn't do anything to notify the driver about this impending statechange. We should probably wrap _tnl_FlushVertices() and install that instead in ctx-Driver.FlushVertices(). I'll code something up post a patch. Keith Can you test this change? Keith I've tested it. Radeon 7000. I get texture flashing in Quake3 with map q3dm1 in particular, when in the room with the plasma gun. It's pretty spectacular -- floor goes purple and yellow. Not quite sure what to make of it. Screenshot: (1280x1024, sorry, my flat panel made me do it! I swear!) http://bronaugh.linuxboxen.org/q3_glitch.jpg I got this with trunk too, without this patch. Hopefully I'm not hitting a hardware flaw or such in my card (ie, bad ram)... It seems to change a lot with motion (whether it's glitched or not) and also seemingly with time (perhaps lighting?). Can someone else confirm this behaviour? David Bronaugh pgp0.pgp Description: PGP signature
Re: [Dri-devel] Missing radeonEmitState in radeonValidateState?
On Tue, 25 Feb 2003 00:46:36 -0800 David Bronaugh [EMAIL PROTECTED] wrote: On Mon, 24 Feb 2003 21:13:09 -0700 Keith Whitwell [EMAIL PROTECTED] wrote: What became of this? It seems to fix the flag in bzflag having the wrong texture with the r200 driver with SW TCL as well. I think I figured out the underlying problem. In core mesa, all statechanges are preceded by a call to ctx-Driver.FlushVertices(), to ensure all buffered vertices are fired before the state is changed. This is currently set to _tnl_FlushVertices(), which doesn't do anything to notify the driver about this impending statechange. We should probably wrap _tnl_FlushVertices() and install that instead in ctx-Driver.FlushVertices(). I'll code something up post a patch. Keith Can you test this change? Keith I've tested it. Radeon 7000. I get texture flashing in Quake3 with map q3dm1 in particular, when in the room with the plasma gun. It's pretty spectacular -- floor goes purple and yellow. Not quite sure what to make of it. Screenshot: (1280x1024, sorry, my flat panel made me do it! I swear!) http://bronaugh.linuxboxen.org/q3_glitch.jpg I got this with trunk too, without this patch. Hopefully I'm not hitting a hardware flaw or such in my card (ie, bad ram)... It seems to change a lot with motion (whether it's glitched or not) and also seemingly with time (perhaps lighting?). Can someone else confirm this behaviour? You're right. It looks like a SWTCL vertex corruption problem I fixed recently by moving tnl-Driver.Render.Start( ctx ) before emitting indexed vertices in radeon_run_render. Somehow this patch reintroduces the problem. Though I don't see how :-/ David Bronaugh 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Missing radeonEmitState in radeonValidateState?
On Die, 2003-02-25 at 05:13, Keith Whitwell wrote:
I think I figured out the underlying problem.
In core mesa, all statechanges are preceded by a call to
ctx-Driver.FlushVertices(), to ensure all buffered vertices are fired
before the state is changed. This is currently set to
_tnl_FlushVertices(), which doesn't do anything to notify the driver
about this impending statechange.
We should probably wrap _tnl_FlushVertices() and install that instead in
ctx-Driver.FlushVertices().
I'll code something up post a patch.
Keith
Can you test this change?
It does fix the problems I saw with SW TCL in the r200 driver. For
reference, here's my result of applying the patch to the r200 driver.
I suspect there's still a similar bug in the r100 vtxfmt code, causing
the wrong textures in armagetron (this patch doesn't help that).
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
Index: lib/GL/mesa/src/drv/r200/r200_context.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/r200/r200_context.c,v
retrieving revision 1.19
diff -p -u -r1.19 r200_context.c
--- lib/GL/mesa/src/drv/r200/r200_context.c 6 Feb 2003 20:41:40 - 1.19
+++ lib/GL/mesa/src/drv/r200/r200_context.c 25 Feb 2003 21:27:44 -
@@ -433,6 +433,7 @@ GLboolean r200CreateContext( const __GLc
*/
_tnl_destroy_pipeline( ctx );
_tnl_install_pipeline( ctx, r200_pipeline );
+ ctx-Driver.FlushVertices = r200FlushVertices;
/* Try and keep materials and vertices separate:
*/
Index: lib/GL/mesa/src/drv/r200/r200_swtcl.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/r200/r200_swtcl.c,v
retrieving revision 1.7
diff -p -u -r1.7 r200_swtcl.c
--- lib/GL/mesa/src/drv/r200/r200_swtcl.c 1 Dec 2002 21:51:49 - 1.7
+++ lib/GL/mesa/src/drv/r200/r200_swtcl.c 25 Feb 2003 21:27:49 -
@@ -46,6 +46,7 @@ WITH THE SOFTWARE OR THE USE OR OTHER DE
#include math/m_translate.h
#include tnl/tnl.h
#include tnl/t_context.h
+#include tnl/t_imm_exec.h
#include tnl/t_pipeline.h
#include r200_context.h
@@ -1222,6 +1223,14 @@ r200PointsBitmap( GLcontext *ctx, GLint
r200ChooseVertexState( ctx );
}
+
+void r200FlushVertices( GLcontext *ctx, GLuint flags )
+{
+ _tnl_flush_vertices( ctx, flags );
+
+ if (flags FLUSH_STORED_VERTICES)
+ R200_FIREVERTICES( R200_CONTEXT( ctx ) );
+}
/**/
/*Initialization. */
Index: lib/GL/mesa/src/drv/r200/r200_swtcl.h
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/r200/r200_swtcl.h,v
retrieving revision 1.3
diff -p -u -r1.3 r200_swtcl.h
--- lib/GL/mesa/src/drv/r200/r200_swtcl.h 25 Nov 2002 15:46:09 - 1.3
+++ lib/GL/mesa/src/drv/r200/r200_swtcl.h 25 Feb 2003 21:27:49 -
@@ -42,6 +42,7 @@ WITH THE SOFTWARE OR THE USE OR OTHER DE
extern void r200InitSwtcl( GLcontext *ctx );
extern void r200DestroySwtcl( GLcontext *ctx );
+extern void r200FlushVertices( GLcontext *ctx, GLuint flags );
extern void r200ChooseRenderState( GLcontext *ctx );
extern void r200ChooseVertexState( GLcontext *ctx );
Index: lib/GL/mesa/src/drv/r200/r200_vtxfmt.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/r200/r200_vtxfmt.c,v
retrieving revision 1.9
diff -p -u -r1.9 r200_vtxfmt.c
--- lib/GL/mesa/src/drv/r200/r200_vtxfmt.c 16 Dec 2002 21:22:27 - 1.9
+++ lib/GL/mesa/src/drv/r200/r200_vtxfmt.c 25 Feb 2003 21:27:49 -
@@ -39,6 +39,7 @@ WITH THE SOFTWARE OR THE USE OR OTHER DE
#include r200_ioctl.h
#include r200_tex.h
#include r200_tcl.h
+#include r200_swtcl.h
#include r200_vtxfmt.h
#include api_noop.h
@@ -59,7 +60,7 @@ WITH THE SOFTWARE OR THE USE OR OTHER DE
struct r200_vb vb;
-static void r200FlushVertices( GLcontext *, GLuint );
+static void r200VtxFmtFlushVertices( GLcontext *, GLuint );
static void count_func( const char *name, struct dynfn *l )
{
@@ -357,12 +358,13 @@ static void VFMT_FALLBACK_OUTSIDE_BEGIN_
fprintf(stderr, %s from %s\n, __FUNCTION__, caller);
if (ctx-Driver.NeedFlush)
- r200FlushVertices( ctx, ctx-Driver.NeedFlush );
+ r200VtxFmtFlushVertices( ctx, ctx-Driver.NeedFlush );
if (ctx-NewState)
_mesa_update_state( ctx ); /* clear state so fell_back sticks */
_tnl_wakeup_exec( ctx );
+ ctx-Driver.FlushVertices = r200FlushVertices;
assert( rmesa-dma.flush == 0 );
rmesa-vb.fell_back = GL_TRUE;
@@ -404,6 +406,7 @@ static void VFMT_FALLBACK( const char *c
prim = rmesa-vb.prim[0];
ctx-Driver.CurrentExecPrimitive = GL_POLYGON+1;
_tnl_wakeup_exec( ctx );
+ ctx-Driver.FlushVertices =
Re: [Dri-devel] Missing radeonEmitState in radeonValidateState?
On Son, 2003-02-09 at 23:40, Keith Whitwell wrote: Felix Kühling wrote: On Sun, 09 Feb 2003 09:53:55 -0700 Keith Whitwell [EMAIL PROTECTED] wrote: diff -u -r1.1.2.7 radeon_state.c --- radeon_state.c 7 Feb 2003 20:22:16 - 1.1.2.7 +++ radeon_state.c 9 Feb 2003 16:52:03 - @@ -990,6 +990,7 @@ case GL_TEXTURE_1D: case GL_TEXTURE_2D: case GL_TEXTURE_3D: + RADEON_FIREVERTICES( rmesa ); break; case GL_ALPHA_TEST: What became of this? It seems to fix the flag in bzflag having the wrong texture with the r200 driver with SW TCL as well. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Missing radeonEmitState in radeonValidateState?
Michel Dänzer wrote: On Son, 2003-02-09 at 23:40, Keith Whitwell wrote: Felix Kühling wrote: On Sun, 09 Feb 2003 09:53:55 -0700 Keith Whitwell [EMAIL PROTECTED] wrote: diff -u -r1.1.2.7 radeon_state.c --- radeon_state.c 7 Feb 2003 20:22:16 - 1.1.2.7 +++ radeon_state.c 9 Feb 2003 16:52:03 - @@ -990,6 +990,7 @@ case GL_TEXTURE_1D: case GL_TEXTURE_2D: case GL_TEXTURE_3D: + RADEON_FIREVERTICES( rmesa ); break; case GL_ALPHA_TEST: What became of this? It seems to fix the flag in bzflag having the wrong texture with the r200 driver with SW TCL as well. I think I figured out the underlying problem. In core mesa, all statechanges are preceded by a call to ctx-Driver.FlushVertices(), to ensure all buffered vertices are fired before the state is changed. This is currently set to _tnl_FlushVertices(), which doesn't do anything to notify the driver about this impending statechange. We should probably wrap _tnl_FlushVertices() and install that instead in ctx-Driver.FlushVertices(). I'll code something up post a patch. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Missing radeonEmitState in radeonValidateState?
Keith Whitwell wrote:
Michel Dänzer wrote:
On Son, 2003-02-09 at 23:40, Keith Whitwell wrote:
Felix Kühling wrote:
On Sun, 09 Feb 2003 09:53:55 -0700
Keith Whitwell [EMAIL PROTECTED] wrote:
diff -u -r1.1.2.7 radeon_state.c
--- radeon_state.c7 Feb 2003 20:22:16 -1.1.2.7
+++ radeon_state.c9 Feb 2003 16:52:03 -
@@ -990,6 +990,7 @@
case GL_TEXTURE_1D:
case GL_TEXTURE_2D:
case GL_TEXTURE_3D:
+ RADEON_FIREVERTICES( rmesa );
break;
case GL_ALPHA_TEST:
What became of this? It seems to fix the flag in bzflag having the wrong
texture with the r200 driver with SW TCL as well.
I think I figured out the underlying problem.
In core mesa, all statechanges are preceded by a call to
ctx-Driver.FlushVertices(), to ensure all buffered vertices are fired
before the state is changed. This is currently set to
_tnl_FlushVertices(), which doesn't do anything to notify the driver
about this impending statechange.
We should probably wrap _tnl_FlushVertices() and install that instead in
ctx-Driver.FlushVertices().
I'll code something up post a patch.
Keith
Can you test this change?
Keith
? diff
Index: radeon_context.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.c,v
retrieving revision 1.30
diff -u -r1.30 radeon_context.c
--- radeon_context.c6 Feb 2003 20:41:39 - 1.30
+++ radeon_context.c25 Feb 2003 03:59:14 -
@@ -382,6 +380,7 @@
*/
_tnl_destroy_pipeline( ctx );
_tnl_install_pipeline( ctx, radeon_pipeline );
+ ctx-Driver.FlushVertices = radeonFlushVertices;
/* Try and keep materials and vertices separate:
*/
Index: radeon_swtcl.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_swtcl.c,v
retrieving revision 1.11
diff -u -r1.11 radeon_swtcl.c
--- radeon_swtcl.c 13 Feb 2003 10:21:09 - 1.11
+++ radeon_swtcl.c 25 Feb 2003 03:59:21 -
@@ -45,6 +45,7 @@
#include math/m_translate.h
#include tnl/tnl.h
#include tnl/t_context.h
+#include tnl/t_imm_exec.h
#include tnl/t_pipeline.h
#include radeon_context.h
@@ -1135,6 +1136,14 @@
}
}
+
+void radeonFlushVertices( GLcontext *ctx, GLuint flags )
+{
+ _tnl_flush_vertices( ctx, flags );
+
+ if (flags FLUSH_STORED_VERTICES)
+ RADEON_FIREVERTICES( RADEON_CONTEXT( ctx ) );
+}
/**/
/*Initialization. */
Index: radeon_swtcl.h
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_swtcl.h,v
retrieving revision 1.2
diff -u -r1.2 radeon_swtcl.h
--- radeon_swtcl.h 12 Jun 2002 15:50:26 - 1.2
+++ radeon_swtcl.h 25 Feb 2003 03:59:21 -
@@ -43,6 +43,7 @@
extern void radeonInitSwtcl( GLcontext *ctx );
extern void radeonDestroySwtcl( GLcontext *ctx );
+extern void radeonFlushVertices( GLcontext *ctx, GLuint flags );
extern void radeonChooseRenderState( GLcontext *ctx );
extern void radeonChooseVertexState( GLcontext *ctx );
Index: radeon_vtxfmt.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_vtxfmt.c,v
retrieving revision 1.9
diff -u -r1.9 radeon_vtxfmt.c
--- radeon_vtxfmt.c 17 Dec 2002 01:19:38 - 1.9
+++ radeon_vtxfmt.c 25 Feb 2003 03:59:22 -
@@ -55,11 +55,12 @@
#include radeon_ioctl.h
#include radeon_tex.h
#include radeon_tcl.h
+#include radeon_swtcl.h
#include radeon_vtxfmt.h
struct radeon_vb vb;
-static void radeonFlushVertices( GLcontext *, GLuint );
+static void radeonVtxfmtFlushVertices( GLcontext *, GLuint );
static void count_func( const char *name, struct dynfn *l )
{
@@ -336,12 +337,13 @@
fprintf(stderr, %s from %s\n, __FUNCTION__, caller);
if (ctx-Driver.NeedFlush)
- radeonFlushVertices( ctx, ctx-Driver.NeedFlush );
+ radeonVtxfmtFlushVertices( ctx, ctx-Driver.NeedFlush );
if (ctx-NewState)
_mesa_update_state( ctx ); /* clear state so fell_back sticks */
_tnl_wakeup_exec( ctx );
+ ctx-Driver.FlushVertices = radeonFlushVertices;
assert( rmesa-dma.flush == 0 );
rmesa-vb.fell_back = GL_TRUE;
@@ -382,6 +384,7 @@
prim = rmesa-vb.prim[0];
ctx-Driver.CurrentExecPrimitive = GL_POLYGON+1;
_tnl_wakeup_exec( ctx );
+ ctx-Driver.FlushVertices = radeonFlushVertices;
assert(rmesa-dma.flush == 0);
rmesa-vb.fell_back = GL_TRUE;
@@ -734,7 +737,7 @@
fprintf(stderr, reinstall (new install)\n);
_mesa_install_exec_vtxfmt( ctx, rmesa-vb.vtxfmt );
-ctx-Driver.FlushVertices = radeonFlushVertices;
+ctx-Driver.FlushVertices = radeonVtxfmtFlushVertices;
ctx-Driver.NewList = radeonNewList;
rmesa-vb.installed = GL_TRUE;
Re: [Dri-devel] Missing radeonEmitState in radeonValidateState?
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. I'll have a play with the demo see what I can find. 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
Re: [Dri-devel] Missing radeonEmitState in radeonValidateState?
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
Re: [Dri-devel] Missing radeonEmitState in radeonValidateState?
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 - 1.1.2.7 +++ radeon_state.c 9 Feb 2003 16:52:03 - @@ -990,6 +990,7 @@ case GL_TEXTURE_1D: case GL_TEXTURE_2D: case GL_TEXTURE_3D: + RADEON_FIREVERTICES( rmesa ); break; case GL_ALPHA_TEST: --- 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
Re: [Dri-devel] Missing radeonEmitState in radeonValidateState?
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.c7 Feb 2003 20:22:16 - 1.1.2.7 +++ radeon_state.c9 Feb 2003 16:52:03 - @@ -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
Re: [Dri-devel] Missing radeonEmitState in radeonValidateState?
Felix Kühling wrote: 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 - 1.1.2.7 +++ radeon_state.c 9 Feb 2003 16:52:03 - @@ -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? No, because no more vertices can accumulate with that (old) state -- you *have* to fire them then. 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. 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... 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
Re: [Dri-devel] Missing radeonEmitState in radeonValidateState?
Felix Kühling wrote:
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]
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 - 1.1.2.7
+++ radeon_state.c 9 Feb 2003 16:52:03 -
@@ -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 - 1.10
+++ radeon_swtcl.c 9 Feb 2003 18:47:41 -
@@ -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 ... ;-)
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...
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
Re: [Dri-devel] Missing radeonEmitState in radeonValidateState?
Hello! yes, this patch helps quake3 in sw-tcl mode (no more flickering of textures). It looks even better than hw-tcl, because hw-tcl shows that other flickering when looking to the ground and turning around a bit. But unfortunately it doesnt solve the issue with the invisible player-model in the player settings menu. With softwarerendering (LIBGL_ALWAYS_INDIRECT=1) the model is visible. (but q3 unplayable) (quake3 1.31 from dec.2001) Could it be a similar effect that something gets lost when switching between an ortho and a perspective view? regards, Andreas Am 2003.02.09 17:53:55 +0100 schrieb(en) Keith Whitwell: 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 - 1.1.2.7 +++ radeon_state.c 9 Feb 2003 16:52:03 - @@ -990,6 +990,7 @@ case GL_TEXTURE_1D: case GL_TEXTURE_2D: case GL_TEXTURE_3D: + RADEON_FIREVERTICES( rmesa ); break; case GL_ALPHA_TEST: --- 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
Re: [Dri-devel] Missing radeonEmitState in radeonValidateState?
Andreas Stenglein wrote: Hello! yes, this patch helps quake3 in sw-tcl mode (no more flickering of textures). It looks even better than hw-tcl, because hw-tcl shows that other flickering when looking to the ground and turning around a bit. But unfortunately it doesnt solve the issue with the invisible player-model in the player settings menu. With softwarerendering (LIBGL_ALWAYS_INDIRECT=1) the model is visible. (but q3 unplayable) (quake3 1.31 from dec.2001) Could it be a similar effect that something gets lost when switching between an ortho and a perspective view? Andreas, Yes -- I think this opens up a whole class of statechanges that aren't being handled correctly. It's entirely plausible that there are a dozen or more places we need to add FIRE_VERTICES commands. 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
