Re: VBO patch

Gavriel State wrote:

>
> 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.

I'm not sure it's a bug, although I've found nothing stating either that 
calling glXXXPointer after binding a vertex buffer is mandatory or optional.
But it might be simply undefined, and maybe it just so happen that it 
works in nvidia implementation.

>
>> 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?


I'll do some measurements again and get back to you with some figures. I 
know I did get noticeable improvements (more so than when I enabled VBO) 
on my old motherboard (athlon 1.4ghz, sdram). It might not be such a big 
deal on a more up to date setup though, I'll try again on my athlon-xp 
3000+ with ddr.

In oprofile, I was getting almost as many samples in libx11drv as in 
ao's 3d engine (which does all skinning/animation on the cpu), with 70% 
of those in X11DRV_GLX_VbPrerender. No samples in X11DRV_GLX_Convert, 
though, so it was probably inlined.