On 29.06.2009 19:55, Maciej Cencora wrote: > Dnia poniedziałek, 29 czerwca 2009 o 19:33:38 Roland Scheidegger napisał(a): >> On 29.06.2009 19:09, Maciej Cencora wrote: >>> Dnia poniedziałek, 29 czerwca 2009 o 17:52:30 Roland Scheidegger > napisał(a): >>>> On 27.06.2009 23:57, Maciej Cencora wrote: >>>>> Hi, >>>>> >>>>> while playing with r300 driver I've stumbled upon a problem with >>>>> splitting vertexes. >>>>> >>>>> Let's say we get rendering operation where number of indexes in index >>>>> buffer is 80000 and max_index is 20000. We are calling vbo_split_prims >>>>> because number of indexes exceeds hw limit. >>>>> In flush_vertex (vbo_split_inplace.c) function the split->ib is not >>>>> null, so the max_index (20000) won't be changed. In the end the >>>>> draw_prims functions will be called with inappropriate max_index >>>>> number. >>>>> >>>>> I'm seeing this behaviour with UT2004 demo on current r300 driver. >>>>> >>>>> I think the solution would be to always calculate min/max_index numbers >>>>> just like in the !split->ib path but I want to be sure before I commit >>>>> the patch. >>>>> >>>>> Any comments? >>>> Apart from this problem, I think the limits in the r300 driver set are >>>> maybe not really hw limits. I'm not sure why max_verts is limited at all >>>> (though maybe limited by buffer size?), and max_indices could be bumped >>>> at least for r500. (I always considered it odd that even r200 could >>>> accept 23 bits worth of indices for the INDX_BUFFER command but only 16 >>>> bit number of amount of vertices in vertex fetch control, and this >>>> finally seems fixed in r500 - 24 bits possible with >>>> VAP_ALT_NUM_VERTICES.) >>> On <= r300 we are limited by VAP_VF_CNLT_.NUM_VERTICES field size (16 >>> bit) for both indices and vertices list. I tried using >>> VAP_ALT_NUM_VERTICES reg on r500 by programming it right before >>> 3D_DRAW_VBUF2 packet, but it always ended in GPU hang. John Bridgman was >>> going to try to dig out some info about it, but no luck so far. >> I don't see why that NUM_VERTICES field limits max_verts. This is only >> the number of vertices the chip fetches after all, and it shouldn't >> matter how many vertices are in the buffer. >> BTW there's also a comment in the code that rebase should be done if >> there's more than 8192 / 16384 indices per primitive. I believe though >> the docs are wrong wrt this as it doesn't really make sense as far as I >> can see (says 8192 / 16384 max as per max buffer size, but max buffer >> size is 23bit number of dwords). >> > > Does attached patch look sane to you? Looks good to me. Note though that the limits are never actually checked in the non-ib case... (And I didn't check if the driver could actually handle that large vertex buffers. I guess the size limit should kick in though.) The bogus comment probably came from the r5xx docs which have very confusing description for the INDX_BUFFER packet.
btw I'm curious about why VAP_ALT_NUM_VERTICES doesn't work? Sounds fairly straight forward - set this reg, in r300FireEB set the USE_ALT_NUM_VERTS for VAP_VF_CNTL and that should be it? Roland ------------------------------------------------------------------------------ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
