Hi, On Thursday, January 24, 2013 10:27:48 Robert Osfield wrote: > On 22 January 2013 20:15, Terry Welsh <[email protected]> wrote: > > I don't think this has been asked in a while. Is it time to switch > > Drawables to use VBOs instead of Display Lists by default? I *always* > > switch it manually, except for a couple exceptional situations. I > > think VBOs are at least as fast as Display Lists and sometimes much > > faster on modern hardware. Would this cause a lot of trouble? > > I was hoping that more of the community might chime in here... guess > we are all sleeping of the winter holidays :-) > > I haven't done any recent tests with VBO's vs display lists, but in > the last few years I've found that for scenes with large number of > small geometries display lists tend to have an advantage, while scenes > with a smaller number of larger geometries favour VBO's. The results > are driver dependent, as well as how you manage the meshes - so a > geometry with lots of small primitive sets would favour display lists > while using a single triangle mesh optimized for cache coherency would > favour VBO's. > > I think the best way forward would probably be to default to VBO or > perhaps no VBO or display lists, and then use the Optimizer to decide > which geometries to change how they are managed, including remeshing > if one want to VBO's or just standard vertex arrays to cut down on the > GL calling overhead. One might want to add some metrics into the > decision of whether to use VBO vs display lists, perhaps even hardware > dependent sets of metrics so we get the best performance from > different type of hardware.
My observation is quite similar. >From what I know the display lists in the closed source drivers are done by vbos. From what I read in the sources of the open source ones, this is just the same. So, whatever you do you will end up using vbos technically. Well, there is technically no other way to solve this with current hardware since about everything is really communicated with the chip by buffer objects in some sense. That includes uniforms and what not ... Looking at dlist, I believe that the closed source one even optimizes triangle strips and ploygons by using huger batched draws with primitive restart. Since the driver knows about the chip and that it has the restart available in any case for nvidia, it will do this optimization without asking the user. Whereas if you do that as an application you need to ask for an extension here and prepare for not having primitive restart this in the end. On some hardware/drivers vbos with osg are still slower than dlists. OTOH, dlists are deprecated and if we now start to require this, it's probably a good time. This will also move the attention of some osg users to provide faster geometries as long as we are not exactly close to the point where the legacy contexts really vanish. So, it could be a good in the end to move to vbos as default at some point. ... may be now. No particular emphasis on any argument. Just the thoughts ... Mathias _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
