Re: VBO patch

Antoine Chavasse wrote:

> I think it's because nvidia uses VAR, while ATI uses plain vertex 
> arrays, as VBO support was removed from CVS.
>
> I tried to re-enable it (by getting the previous versions of 
> x11drv/makefile.in and executebuffer.c from cvs, where th vbo support 
> was enabled), and to fix the massive rendering problems (it was 
> rendering almost only random polygons) it was causing. It turned out 
> that in d3dgl/fixedfunc.c, in GL_load_arrays(), the glXXXPointer 
> functions were only called if the adress/stride to set changed since 
> the last call.
>
> It's bad with VBO. I think the driver internally computes the actual 
> start adress of the buffer at this time, using the current bound 
> vertex buffer and the offset given to the function, so not caling this 
> function after binding a new buffer leave the internal buffer address 
> actually used for rendering unchanged.
> I don't have any glitch whatsoever with my patch, and it almost 
> doubled the framerate in AO in some cases. I only tried it on my pc, 
> though, although with two different motherboards and several different 
> versions of the ATI drivers.
>
> What worries me however, is that I've seen rendering problems 
> mentioned about everywhere concerning VBO and WineX, but only 
> "rendering problems", not "trashed polygons all over the screen" like 
> I was getting before I changed fixedfunc.c.


Hi Antoine,

Cool - thanks for the info.  We've continued to have issues with the VBO 
path on ATI with the internal source tree, though not with NVidia.  With 
at least some of our tests, using VBO can cut framerates on ATI by 90% 
or more.  Your theory above makes some sense, and we'll give it a try 
and report the bug to ATI if it is in fact the case.

> And it also seems that VBO is compiled in the official binaries (as 
> grep finds stuff like the "ARB_VBO" string in the binaries, that are 
> nowhere to be found in the cvs source), so I don't know how outdated 
> the VBO code in CVS is (if it is), and whether this fix could be 
> applicable to the official version. And I've not been able to try the 
> official binaries with AO, since Marius' patches aren't merged yet. 

The VBO code in external CVS is pretty close to what we have internally 
- there is one relevant change internally to fix some of the state 
caching stuff you've removed from d3dgl/fixedfunction.c, but it's only 
for the TexCoordArray rather than for all of the pointers.

> I also did another optimisation in x11drv/executebuffer.c: I added a 
> counter to know how many vertices remain to be converted, so the 
> entire buffer convertion function can be omitted if all the vertices 
> of the buffer are known to have been converted, instead of checking 
> the uptodate flags for all of them. oprofile showed that a lot of time 
> was wasted there.

We've played with some things like this internally, but never had 
sufficient evidence of a real performance improvement.  I have a patch 
around on my personal tree that converts all data once we've had > 30 
renders of the same data, and then skips the conversion path (unless the 
data changes again).  Do you have performance measurements that bear out 
a significant improvement?

Take care,
 -Gav

-- 
Gavriel State, Co-CEO & CTO
TransGaming Technologies Inc.
http://www.transgaming.com

Let the games begin!