On 5/5/2011 11:26 AM, Glenn Waldron wrote:
On Thu, May 5, 2011 at 12:59 PM, Paul Martz <[email protected] <mailto:[email protected]>> wrote:On 5/5/2011 9:51 AM, Glenn Waldron wrote: AFAIK, OSG doesn't maintain VBO/EBO bindings as part of its sortable state. So I believe they will be bound and unbound for each Geometry, even if they are shared. Somebody correct me if I'm wrong. (See Geometry::drawImplementation.) This is my experience as well. OSG binds and unbinds the buffer object per Geometry during draw, and doesn't attempt to minimize this state change. OSG relies on the underlying OpenGL implementation to do lazy buffer bindings, so that binding a buffer, followed by unbinding a buffer, followed by binding the same buffer again, is handled optimally. However, to my knowledge, OSG doesn't group Geometry objects based on the buffer objects they use, so even if the underlying OpenGL implementation does perform lazy buffer bindings, it's unlikely that OSG is taking maximum advantage of it. Paul, you know more about OSG internals than I. Would you think that isolating all the Geomety objects that share a VBO into a single render bin might increase the effectiveness of the driver's lazy binding?
Assuming the driver does lazy buffer bindings, yes. I know that OSG gets a big win from sorting some OpenGL state, so it stands to reason that including more OpenGL state in this feature (such as buffer bindings) would produce a performance increment. (Of course it goes without saying that the performance delta depends on the model's organization.)
This is something that could be benchmarked in an OpenGL app first, to see if there's any real performance delta between the three strategies that I can think of:
1) Render using random buffer objects, always bind and unbind around each Geometry analogue (what OSG does currently).
2) Group Geometry analogues by their buffer objects, but still bind and unbind around each Geometry analogue (what you're proposing).
3) Like 2, but only bind once for each group of Geometry analogues that share the same buffer object (the optimal approach).
-Paul _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
