Ian Romanick wrote:
I'm not sure if the r200 vertex path has ever worked - the code can probably be removed.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?
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
