Re: [Dri-devel] radeonAllocDmaRegion called with bytes dma buffersize
Keith Whitwell wrote: Felix Kühling wrote: On Wed, 05 Feb 2003 16:25:27 -0700 Keith Whitwell [EMAIL PROTECTED] wrote: Felix Kühling wrote: I attached a patch that fixes the problem. It introduces a new TCL_FALLBACK if there are too many vertices to fit into one DMA buffer. Looks kind of hackish to me. Does anyone have a better idea? Comments? Mesa should respect ctx-Const.MaxArrayVertices, which should be being set in radeon_context.c --- it may be that this code is disabled - can you check that try turning it back on. Found it: radeon_context.c around line 375: /* ctx-Const.MaxArrayLockSize = */ /*MIN2( ctx-Const.MaxArrayLockSize, */ /* RADEON_BUFFER_SIZE / RADEON_MAX_TCL_VERTSIZE ); */ And then there is the definition of RADEON_MAX_TCL_VERTSIZE in radeon_tcl.h which is (4*4). However, I saw vertex_size==24! Maybe the real MAX_TCL_VERTSIZE is even bigger? Yes it is, because we went back to using vertexes instead of individual arrays, but forgot to reset this max value. I've committed the fix. That's something I had noticed before, but never asked about. Both the radeon r200 drivers have two different code paths that are selected at compile time. radeon uses maos_verts and r200 uses maos_arrays. I looked at it before, and I didn't really understand what was going on. What's the difference between the two? Why does r100 use one and r200 use the other? --- 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] radeonAllocDmaRegion called with bytes dma buffersize
Ian Romanick wrote: Keith Whitwell wrote: Felix Kühling wrote: On Wed, 05 Feb 2003 16:25:27 -0700 Keith Whitwell [EMAIL PROTECTED] wrote: Felix Kühling wrote: I attached a patch that fixes the problem. It introduces a new TCL_FALLBACK if there are too many vertices to fit into one DMA buffer. Looks kind of hackish to me. Does anyone have a better idea? Comments? Mesa should respect ctx-Const.MaxArrayVertices, which should be being set in radeon_context.c --- it may be that this code is disabled - can you check that try turning it back on. Found it: radeon_context.c around line 375: /* ctx-Const.MaxArrayLockSize = */ /*MIN2( ctx-Const.MaxArrayLockSize, */ /* RADEON_BUFFER_SIZE / RADEON_MAX_TCL_VERTSIZE ); */ And then there is the definition of RADEON_MAX_TCL_VERTSIZE in radeon_tcl.h which is (4*4). However, I saw vertex_size==24! Maybe the real MAX_TCL_VERTSIZE is even bigger? Yes it is, because we went back to using vertexes instead of individual arrays, but forgot to reset this max value. I've committed the fix. That's something I had noticed before, but never asked about. Both the radeon r200 drivers have two different code paths that are selected at compile time. radeon uses maos_verts and r200 uses maos_arrays. I looked at it before, and I didn't really understand what was going on. What's the difference between the two? Why does r100 use one and r200 use the other? I'm not sure if the r200 vertex path has ever worked - the code can probably be removed. The r100 started with vertices, I added arrays but actually the r100 seems to be faster with vertices than arrays... And somebody spotted a problem with the array path (I just remembered this) where a packet can get split between two buffers in a bad way. I should try dig this out as it can probably happen in the r200 driver as well. 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] radeonAllocDmaRegion called with bytes dma buffersize
Felix Kühling wrote: On Wed, 05 Feb 2003 16:25:27 -0700 Keith Whitwell [EMAIL PROTECTED] wrote: Felix Kühling wrote: I attached a patch that fixes the problem. It introduces a new TCL_FALLBACK if there are too many vertices to fit into one DMA buffer. Looks kind of hackish to me. Does anyone have a better idea? Comments? Mesa should respect ctx-Const.MaxArrayVertices, which should be being set in radeon_context.c --- it may be that this code is disabled - can you check that try turning it back on. Found it: radeon_context.c around line 375: /* ctx-Const.MaxArrayLockSize = */ /*MIN2( ctx-Const.MaxArrayLockSize, */ /* RADEON_BUFFER_SIZE / RADEON_MAX_TCL_VERTSIZE ); */ And then there is the definition of RADEON_MAX_TCL_VERTSIZE in radeon_tcl.h which is (4*4). However, I saw vertex_size==24! Maybe the real MAX_TCL_VERTSIZE is even bigger? Yes it is, because we went back to using vertexes instead of individual arrays, but forgot to reset this max value. I've committed the fix. 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] radeonAllocDmaRegion called with bytes dma buffersize
Hurrah! ... this fixes the vertex data corruption in the UT2003 opening screen. There's still vertex problems in game (though not quite as much). The remaining problems may be because of cube mapping (I'm testing on R100). On Wed, 5 Feb 2003, Keith Whitwell wrote: Felix Kühling wrote: On Wed, 05 Feb 2003 16:25:27 -0700 Keith Whitwell [EMAIL PROTECTED] wrote: Felix Kühling wrote: I attached a patch that fixes the problem. It introduces a new TCL_FALLBACK if there are too many vertices to fit into one DMA buffer. Looks kind of hackish to me. Does anyone have a better idea? Comments? Mesa should respect ctx-Const.MaxArrayVertices, which should be being set in radeon_context.c --- it may be that this code is disabled - can you check that try turning it back on. Found it: radeon_context.c around line 375: /* ctx-Const.MaxArrayLockSize = */ /*MIN2( ctx-Const.MaxArrayLockSize, */ /* RADEON_BUFFER_SIZE / RADEON_MAX_TCL_VERTSIZE ); */ And then there is the definition of RADEON_MAX_TCL_VERTSIZE in radeon_tcl.h which is (4*4). However, I saw vertex_size==24! Maybe the real MAX_TCL_VERTSIZE is even bigger? Yes it is, because we went back to using vertexes instead of individual arrays, but forgot to reset this max value. I've committed the fix. Keith --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld ÿomething 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Leif Delgass http://www.retinalburn.net --- 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] radeonAllocDmaRegion called with bytes dma buffersize
On Thu, 6 Feb 2003, Felix Kühling wrote: On Wed, 5 Feb 2003 20:17:57 -0500 (EST) Leif Delgass [EMAIL PROTECTED] wrote: Hurrah! ... this fixes the vertex data corruption in the UT2003 opening screen. There's still vertex problems in game (though not quite as much). The remaining problems may be because of cube mapping (I'm testing on R100). I see lots of vertex data corruption with TCL disabled in torcs and in quakeforge. With TCL enabled there is some strange corruption in quakeforge when the console is active. Actually, disabling TCL does cause some vertex corruption right at the start of the intro. Also I tried disabling texturing (rmode 7) and the vertex corruption in-game is still there, so it doesn't seem to be related to cube mapping. -- Leif Delgass http://www.retinalburn.net --- 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] radeonAllocDmaRegion called with bytes dma buffersize
Leif Delgass wrote: Hurrah! ... this fixes the vertex data corruption in the UT2003 opening screen. There's still vertex problems in game (though not quite as much). The remaining problems may be because of cube mapping (I'm testing on R100). Hmm. Do you have an r200? I wonder whats up there... 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] radeonAllocDmaRegion called with bytes dma buffersize
On Wed, 5 Feb 2003, Keith Whitwell wrote: Leif Delgass wrote: Hurrah! ... this fixes the vertex data corruption in the UT2003 opening screen. There's still vertex problems in game (though not quite as much). The remaining problems may be because of cube mapping (I'm testing on R100). Hmm. Do you have an r200? I wonder whats up there... Nope. See my other reply (to Felix) -- there are still problems with TCL disabled and in game maps even with TCL. I was wondering if it was related to use of more than 2 texcoords, but I still had the problem with texturing disabled in ut2k3. I'm starting to look at what we need to do to handle glTexCoord3/4. The tricky thing is that the templates (e.g. radeon_maos_verts.c) seem to assume either 2 coords, or 4 coords (with r unused). We need to be able to choose either the third or fourth texcoord to put in the card's q slot, depending on whether the target is a 3D/cubemap texture or a 2D texture. -- Leif Delgass http://www.retinalburn.net --- 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
