Roland Scheidegger wrote: > Keith Whitwell wrote: >> Roland Scheidegger wrote: >>> Roland Scheidegger wrote: >>>> Didn't have time to look into this yet, but just retesting all the apps >>>> I had trouble with vbo_0_1_branch some months ago showed that the quake3 >>>> intro screen is now fixed (with r200). >>> To answer myself, I've fixed a couple of issues, doom3 now seems to run. >>> As for ut2k3/2k4, those just show a bunch of mostly random triangles and >>> eventually (immediately already at intro with sw tnl) segfault. >>> Apparently caused by the index buffer rebasing >>> (vbo_exec_DrawRangeElements), when setting the rebase to 0 and use start >>> as the min_index parameter (i.e. following the suggestion in the >>> comment) it works just fine. In fact, it appears faster than the non-vbo >>> code, despite that the driver still doesn't implement real vbos, though >>> I didn't run any benchmarks. >>> Maybe the buffer rebasing should just be removed (it currently doesn't >>> work with software mesa neither), or would it be worth fixing it? >> Roland, >> >> Thanks for looking at this - are there any further problems you've >> noticed along the way? >> >> Keith >> > No, basically everything seems to be working. I was a bit concerned with > the limits when the split occurs, but that seems to work fine on r200 > (though probably not optimal since it's really a buffer size limit not a > fixed vertex count limit for the driver currently). Not sure though what > happens with large index counts (chances are there will be a split > anyway in that case because of too large arrays), there may be hidden > bugs there with the radeon/r200 drivers.
The split code can be set up to split on either large vertex buffers or large index buffers. There's no static cost associated with changing the split limits, so just figure out the vertex size and divide that into the maximum allowed vertex buffer size, and use that as the split limit. Currently it looks like r200 is just accepting whatever limits the swtnl module is placing on itself, but there's no reason for this. What I anticipate is that r200 will register its own draw_prims function, which can do splitting if necessary. Then you'd ideally upload the results straight into the hardware tnl and never call swtnl or worry about the pipeline/whatever, only using that code when a fallback is required. But for the meantime, just feed the results into swtnl. > I've done some quick measurements, ut2k3 got up from ~40fps to ~75fps > (which is very nice, this probably brings it roughly back to where it > once was in mesa 5 days if not better, even sw tnl got a big increase > from 27fps to 49fps!), ipers (with lod 1) has about a 20% performance > drop whereas trispd (with size 5) gets down from roughly 25M tris/s to > 16M tris/s (obviously due to the removal of the vtxfmt code in the > driver). I'd say that's quite good overall. This is great. At very least it means that we don't have to re-write the vtxfmt stuff before this code can be merged to the trunk. I'm not sure where the speedups come from, but I'm not arguing about it either. > The only thing I noticed looking different was the water reflection in > the antalus map in ut2k3/ut2k4, though it could be due to other changes > in the code rather than vbo (it uses some weirdo texgen and at least in > ut2k3 has never looked right neither with sw tnl nor hw tnl, and was > never correct with fglrx neither). OK, this sounds good. I'll take another look at rebase and start thinking about testing for a merge. Keith ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
