[Dri-devel] Missing radeonEmitState in radeonValidateState?
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 attached a small commented example programme that demonstrates the
problem if TCL is disabled.
Regards,
Felix
__\|/_____ ___ ___
__Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___
_Felix___\Ä/\ \_\ \_\ \__U___just not everything
[EMAIL PROTECTED]o__/ \___/ \___/at the same time!
#include GL/gl.h
#include GL/glu.h
#include GL/glut.h
#include stdio.h
#include stdlib.h
#define PRIMITIVE GL_TRIANGLES
#define LAST_PRIMITIVE 1
unsigned char texData[2][8*8*3];
GLuint textures[2];
void init () {
int i;
glClearColor (0.0, 0.0, 0.0, 0.0);
glShadeModel (GL_FLAT);
for (i = 0; i 8*8; ++i) {
/* red texture */
texData[0][3*i+0] = rand();
texData[0][3*i+1] = 0;
texData[0][3*i+2] = 0;
/* green texture */
texData[1][3*i+0] = 0;
texData[1][3*i+1] = rand();
texData[1][3*i+2] = 0;
}
glGenTextures (2, textures);
/* textures[0]: red */
glBindTexture (GL_TEXTURE_2D, textures[0]);
glTexImage2D(GL_TEXTURE_2D, 0, 3, 8, 8, 0, GL_RGB, GL_UNSIGNED_BYTE, texData[0]);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
/* texture[1]: green */
glBindTexture (GL_TEXTURE_2D, textures[1]);
glTexImage2D(GL_TEXTURE_2D, 0, 3, 8, 8, 0, GL_RGB, GL_UNSIGNED_BYTE, texData[1]);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glEnable(GL_TEXTURE_2D);
glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_DECAL);
glBindTexture (GL_TEXTURE_2D, 0);
}
void display () {
glClear (GL_COLOR_BUFFER_BIT);
glEnable(GL_TEXTURE_2D);
/* top left corner, texture[0] (red) */
glBindTexture (GL_TEXTURE_2D, textures[0]);
glBegin(GL_QUADS);
glColor3f(1.0, 1.0, 0.0);
glTexCoord2f(0.0, 0.0); glVertex2f(-1.0, 0.0);
glTexCoord2f(1.0, 0.0); glVertex2f(0.0, 0.0);
glTexCoord2f(1.0, 1.0); glVertex2f(0.0, 1.0);
glTexCoord2f(0.0, 1.0); glVertex2f(-1.0, 1.0);
glEnd();
/* top right corner, texture[1] (green) */
glBindTexture (GL_TEXTURE_2D, textures[1]);
glBegin(PRIMITIVE);
glColor3f(1.0, 1.0, 0.0);
#if (PRIMITIVE == GL_TRIANGLES)
glTexCoord2f(0.0, 0.0); glVertex2f(0.0, 0.0);
glTexCoord2f(1.0, 0.0); glVertex2f(1.0, 0.0);
glTexCoord2f(0.0, 1.0); glVertex2f(0.0, 1.0);
glTexCoord2f(1.0, 0.0); glVertex2f(1.0, 0.0);
glTexCoord2f(0.0, 1.0); glVertex2f(0.0, 1.0);
glTexCoord2f(1.0, 1.0); glVertex2f(1.0, 1.0);
#elif (PRIMITIVE == GL_TRIANGLE_STRIP)
glTexCoord2f(0.0, 0.0); glVertex2f(0.0, 0.0);
glTexCoord2f(1.0, 0.0); glVertex2f(1.0, 0.0);
glTexCoord2f(0.0, 1.0); glVertex2f(0.0, 1.0);
glTexCoord2f(1.0, 1.0); glVertex2f(1.0, 1.0);
#elif (PRIMITIVE == GL_TRIANGLE_FAN)
glTexCoord2f(0.0, 0.0); glVertex2f(0.0, 0.0);
glTexCoord2f(1.0, 0.0); glVertex2f(1.0, 0.0);
glTexCoord2f(1.0, 1.0); glVertex2f(1.0, 1.0);
glTexCoord2f(0.0, 1.0); glVertex2f(0.0, 1.0);
#elif (PRIMITIVE == GL_QUADS)
glTexCoord2f(0.0, 0.0); glVertex2f(0.0, 0.0);
glTexCoord2f(1.0, 0.0); glVertex2f(1.0, 0.0);
glTexCoord2f(1.0, 1.0); glVertex2f(1.0, 1.0);
glTexCoord2f(0.0, 1.0); glVertex2f(0.0, 1.0);
#elif (PRIMITIVE == GL_QUAD_STRIP)
glTexCoord2f(0.0, 0.0); glVertex2f(0.0, 0.0);
glTexCoord2f(1.0, 0.0); glVertex2f(1.0, 0.0);
glTexCoord2f(0.0, 1.0); glVertex2f(0.0, 1.0);
glTexCoord2f(1.0, 1.0); glVertex2f(1.0, 1.0);
#elif (PRIMITIVE == GL_POLYGON)
glTexCoord2f(0.0, 0.0); glVertex2f(0.0, 0.0);
glTexCoord2f(1.0, 0.0); glVertex2f(1.0, 0.0);
glTexCoord2f(1.0, 1.0); glVertex2f(1.0, 1.0);
glTexCoord2f(0.0, 1.0); glVertex2f(0.0, 1.0);
#endif
glEnd();
/* bottom left corner, no texture
* Conditions:
* - TCL disabled
* - primitive not QUADS or QUAD_STRIP
*
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] Rough-rough-rough draft of texmem-0-0-2 design document
Ian Romanick wrote:
Hello all!
Attached is the initial rough-draft of the design document for the next
generation memory manager. It is currently plain-text. When I polled
people on #dri-devel the consensus was that plain-text would be the most
useful format. I suspect at some point I may change to HTML or
something else that can link within a document. In any case, I have
left in the marks for Jed's (and Emacs') folding mode. My apologies to
all who do not fold. :)
Please stick to plain text. The marks are annoying but I can live with them.
The document is not 100% complete. A few sections, such as the
replacement policy, need more discussion before they can be completed. I
have also included an issues section in the spirit of issues
sections in OpenGL extension documents. I think the most significan
issue is 3.13, but I don't think any of them are trivial. I fully
expect this section to grow. :)
3.13 - I think the only sane option is '2' -- fallback to software when out of
memory. I'm pretty sure GL doesn't allow you to silently throw away mipmaps
under memory pressure.
I would *really* like to discuss the document and anything else related
in Monday's #dri-devel meeting. Hopefully people can make it will
have a chance to digest the document by then.
I don't know if I'm going to make the next couple of irc meetings, I'm kindof
on holiday at the moment.
At this point I'd like to throw a spanner in the works, maybe. A longstanding
issue with the current memory manager that isn't addressed in your document is
the struggle between 2d and 3d rendering for available offscreen memory space.
I wonder if you can add a note describing how this scheme might cooperate
with the XAA offscreen memory allocator to ensure memory allocation is shared
between the 2d 3d worlds according to demand?
A small nitpick: you talk about wrapping _tnl_run_pipeline(). I think this
isn't a good approach, particularly as not all rendering proceeds through that
function, in fact there is no guarentee that drivers even include that
function. The cutdown embedded radeon driver on the Mesa embedded-1-branch is
an example of such a driver. I would suggest that the points at which we
aquire hardware locks are better suited to ensuring resources are present --
although this may be too late to decide that a fallback is required... Hmm...
Keith
-*- mode: text; mode: fold -*-
DRI Memory Manager texmem-0-0-2 Design
Ian Romanick [EMAIL PROTECTED]
{{{ 1. Introduction
The current texture management system used by the open-source DRI drivers
has reached its limits. The current implementation works, and it does the
functionality that it implements well. However, there is a large class of
functionality that the current system simply cannot easily support.
Additionally, there are a number of cases where the current system is
clearly suboptimal.
The current texture memory manager only supports throw away data. It is
assumed that, with proper synchronization with the rendering hardware, any
data that is in either AGP or on-card memory can be thrown away and
re-loaded at anytime. For texture data loaded from main memory, this
assumption holds true. However, there are several classes of data that need
to be locked for longer than the duration of a single rendering command.
Anytime a texture is a rendering target, be it as the destination of
glCopyTexImage or as the rendering target of a pbuffer, that texture data
cannot be thrown away until after it is copied to some sort of backing
store. This restriction prevents the current memory manager from hardware
accelerating glCopyTexImage. This restriction has also prevented
implementation of pbuffers in open-source drivers and has forced binary-only
driver, such as ATI's FireGL drivers, to use a static, fixed size memory
area for pbuffers.
Significant changes need to be made to the memory management system to
support render-target buffers.
In addition to supporting render-to-texture, pbuffers, and glCopyTexImage,
the DRI should be able to support dynamic allocation of back-buffers and
depth-buffers. While this is a secondary consideration, this will allow
different depth-buffer depths on the same display (i.e., one window can use
a 16-bit depth-buffer while another uses a 24-bit depth-buffer) and
full-screen anti-aliasing (FSAA).
As has recently been discussed on the dri-devel mailing list, texture
uploads in the DRI are not fully pipelined [1]. For applications that need
to use dynamic textures, such as streaming video, this presents a
performance bottleneck. In order to support fully pipelined texture
uploads, a mechanism is needed to determine when rendering using a
particular texture buffer is complete. The current memory manager lacks
such a mechanism.
Each texture image in the DRI can be replicated in memory in as many as
three places. The
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
Re: [Dri-devel] cube maps and r200 sanity
Chris Ison wrote: ok, I have a problem where when I run QuakeForge, mesa kills itself of and invalist command packet (63). this turns out to be associated with cube maps, and the sanity checks have cubic registers missing from the list. Also Quakeforge doesn't do cube maps unles you explicitly tell it so, and I didn't tell it to. A futher hunt found cubic functions initializing in the texture code. so 1st ... why is cubic a command appearing in the command buffer (and killing mesa cause it fails the sanity check), and if they are ment to be where are the sanity checks for the commands. Probably because Brian wasn't aware of the sanity stuff when he added the cubemap packets. You can turn the sanity checks off as a workaround, or add the packets submit a diff to this list. 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] cube maps and r200 sanity
do you know the packet sizes for R200_EMIT_PP_CUBIC_FACES_* and R200_EMIT_PP_CUBIC_OFFSET_* Probably because Brian wasn't aware of the sanity stuff when he added the cubemap packets. You can turn the sanity checks off as a workaround, or add the packets submit a diff to this list. 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
