Re: [osg-users] VBO as default
Hi, On Friday, January 25, 2013 11:29:22 Glenn Waldron wrote: This is a great topic and I am very interested to learn the facts about this. In osgEarth using display lists (on my NVIDIA GTX275) yields a sizable performance boost over VBOs in many scenarios. In some of my tests I've seen a 50%+ reduction in DRAW and GPU times. But there are strange artifacts that seem to be related to the use of display lists with shaders that prevent me from making DL's the default. Driver bugs perhaps? All I can find is speculation and guessing when it comes to using shaders wtih DLs. Same goes for performance comparisons. Some swear you can always get the same or better performance using a VBO, but it's hard to track down the best practices for doing so. Some say NVIDIA drivers have a special code path that speeds up DL's compared to VBOs. Some say it's all about the number of size of your primitive sets. Obviously VBOs are the future since DLs are deprecated. So assembling some best practices for their application is critical! Hmm, depends on the use I think. I have seen everything from massive improovements to massive drops. Well, I think the IMO well known optimizations still apply. Use medium sized draws which do not use extreme sized vbos. Avoid polygons and strips unless you have primitive restart as each polygon or strip ends up being a seperate draw. If you have primitive restart prefere strips for the good old reasons that were already a valid optimization reason on a SGI. Now you can start a long series of arguments what medium means. There are at least two concurrent needs for the buffers size. For the draw setup in the driver the huger the draw is the better it is for the driver. As a rule of thumb, each gl*Draw* call needs some more or less fixed amount of cpu time to push this draw command into the fifo interpreted by the gpu. That means less draw calls means less cpu consumption. But, there is memory management involved which starts to make this way more unpredictable. There you need to distinguish between gpus having virtual memory addresses and older ones that have not. Those without suffer a lof from memory fragmentation. The huger the buffers are the more this happens. But even if you have a newer gpu with virtual memory space, I think all of you is aware that getting memory management right in every use case is hard to impossible. Given that kind of algorithms you are also back with cpu time wasted for puzzeling the memory blobs into limitted gpu accessible memory. So in the end you really help the driver if you do not just max out the buffer size. In the end this really depends on the application in combination with the gpu. So, for sensible models that are there to display things just at the level of detail that you can resolve with the display/eye, I still tend to stick with the less then 65000 vertices limit per draw. That uses less memory with the indices as you can use shorts there. And if you have a model that is just about the border to be displayed fine vs edgy so that it still looks good, you already have very huge geometries to show which end up in a lot of fragments which end up in being more likely being fragment bound that anything at the top of the pipeline like cpu time to setup the draw. But this could be different for CAD like models that you see in engineering applications. There you can easily have millions of vertices for a small part. If you do this with small buffers you can already hit the draw setup bottleneck. There it might make sense to have bigger bunches. So, nothing hard to beat on it, but effects that I believe to observe over time, different drivers and hardware... Regarding vbo's in osg I think that neither using vbo's nor dlists is definitely better. It's more that they are different. Where you hit on one dlist compiler a codepath that ends up with a lot of draws in the driver that you could have anticipated way better by your application code, you will also see a dlist compiler on a different driver/gpu/application combination where you can't see how you need to issue the draws to reach the performance of the dlist. The same goes for the memory management stuff. I assume that most applications are currently optimized for the default. And if this default changes you will see optimizations move over to the new default over time. Greetings Mathias ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO as default
This is a great topic and I am very interested to learn the facts about this. In osgEarth using display lists (on my NVIDIA GTX275) yields a sizable performance boost over VBOs in many scenarios. In some of my tests I've seen a 50%+ reduction in DRAW and GPU times. But there are strange artifacts that seem to be related to the use of display lists with shaders that prevent me from making DL's the default. Driver bugs perhaps? All I can find is speculation and guessing when it comes to using shaders wtih DLs. Same goes for performance comparisons. Some swear you can always get the same or better performance using a VBO, but it's hard to track down the best practices for doing so. Some say NVIDIA drivers have a special code path that speeds up DL's compared to VBOs. Some say it's all about the number of size of your primitive sets. Obviously VBOs are the future since DLs are deprecated. So assembling some best practices for their application is critical! Glenn Waldron / @glennwaldron On Thu, Jan 24, 2013 at 1:57 PM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Terry, On 24 January 2013 18:21, Terry Welsh mogu...@gmail.com wrote: Mathias's point that display lists are deprecated are probably the best reason to try to make the switch. I'm of this view as well, and would go further and say now that modern graphics developers are working across a wider range of platforms - OpenGL ES and OpenGL and targeting shader pipelines with other modern features in the mix for the these developers using the same features across all the platforms is advantageous, VBO's are very much part of this mix of modern feature spread across targets while display lists are very much a hang up old systems. If OSG isn't close to a major release, I suggest trying it and seeing if it causes problems. Once I get some time to experiment I will have a play with different datasets and see how I get on. I think we'll need to beef up the Optimizer to make sure it handles things better. Also plugins also need updating to create more VBO friendly meshes. To do the job properly we have to take this all into account, I don't feel just switching the default is acceptable as it'll lead to some odd performance drops. As for big vs. small geometries, I used to see differences as well. Years ago, my rule of thumb was to make geometries with fewer than 200 vertices use display lists and bigger ones use VBOs. I just tested this again this morning on NVidia and Intel graphics and I see no difference anymore. However, I'm using a practical test scenario that runs through a scene in my game with geometries ranging in size from about 20 to 1000 vertices. I'm not doing a contrived test. My test scene is about 10% faster using all VBOs vs. all display lists. For modern scene graphs it's likely that VBO's will be strongest, but older scene graphs built with triangle strips and small clumps of geometry will prefer display lists - think OpenFlight databases for an example where display lists will be strongest. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO as default
Hi Terry, On 22 January 2013 20:15, Terry Welsh mogu...@gmail.com 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. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO as default
Hi, On Thursday, January 24, 2013 10:27:48 Robert Osfield wrote: On 22 January 2013 20:15, Terry Welsh mogu...@gmail.com 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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO as default
Mathias's point that display lists are deprecated are probably the best reason to try to make the switch. If OSG isn't close to a major release, I suggest trying it and seeing if it causes problems. As for big vs. small geometries, I used to see differences as well. Years ago, my rule of thumb was to make geometries with fewer than 200 vertices use display lists and bigger ones use VBOs. I just tested this again this morning on NVidia and Intel graphics and I see no difference anymore. However, I'm using a practical test scenario that runs through a scene in my game with geometries ranging in size from about 20 to 1000 vertices. I'm not doing a contrived test. My test scene is about 10% faster using all VBOs vs. all display lists. -- Terry Welsh www.reallyslick.com Message: 4 Date: Thu, 24 Jan 2013 11:39:34 +0100 From: Mathias Fr?hlich mathias.froehl...@gmx.net To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Subject: Re: [osg-users] VBO as default Message-ID: 2803708.in7vaaGG2y@notebook Content-Type: text/plain; charset=us-ascii Hi, On Thursday, January 24, 2013 10:27:48 Robert Osfield wrote: On 22 January 2013 20:15, Terry Welsh mogu...@gmail.com 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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO as default
Hi Terry, On 24 January 2013 18:21, Terry Welsh mogu...@gmail.com wrote: Mathias's point that display lists are deprecated are probably the best reason to try to make the switch. I'm of this view as well, and would go further and say now that modern graphics developers are working across a wider range of platforms - OpenGL ES and OpenGL and targeting shader pipelines with other modern features in the mix for the these developers using the same features across all the platforms is advantageous, VBO's are very much part of this mix of modern feature spread across targets while display lists are very much a hang up old systems. If OSG isn't close to a major release, I suggest trying it and seeing if it causes problems. Once I get some time to experiment I will have a play with different datasets and see how I get on. I think we'll need to beef up the Optimizer to make sure it handles things better. Also plugins also need updating to create more VBO friendly meshes. To do the job properly we have to take this all into account, I don't feel just switching the default is acceptable as it'll lead to some odd performance drops. As for big vs. small geometries, I used to see differences as well. Years ago, my rule of thumb was to make geometries with fewer than 200 vertices use display lists and bigger ones use VBOs. I just tested this again this morning on NVidia and Intel graphics and I see no difference anymore. However, I'm using a practical test scenario that runs through a scene in my game with geometries ranging in size from about 20 to 1000 vertices. I'm not doing a contrived test. My test scene is about 10% faster using all VBOs vs. all display lists. For modern scene graphs it's likely that VBO's will be strongest, but older scene graphs built with triangle strips and small clumps of geometry will prefer display lists - think OpenFlight databases for an example where display lists will be strongest. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] VBO as default
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? -- Terry Welsh www.reallyslick.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
