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. Maciej Cencora ------------------------------------------------------------------------------ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
