[Bf-committers] OpenGL optimisation
Sun, 23 May 2004 13:30:40 -0400
Your optimization works well. Official Time: 00:00.19, Custom Time:
00:00.13 averaged. This is very cool.
On May 23, 2004, at 10:33 AM, Richard Berry wrote:
> Hi, I'm working on optimising Blender's 3D view rendering and have got
> a simple prototype working that shows the sort of performance gains
> that we can get. I've got a binary (Mac OS X only... sorry) and an
> example scene at:
> At the moment it's only a proof of concept which optimises the
> displistmesh_draw_solid function (from drawobject.c) to use OpenGL
> display lists. Also, I commented out the parts that handle smooth
> shading and material settings (the state changes in the middle of
> compiling the display lists were killing performance) but these should
> be back in when I generalise the code and clean it up.
> It seems the quickest (not necessarily best) way to implement OpenGL
> display lists would be to overwrite the drawing routines for Blender's
> "display lists" (i.e. DispList and DispListMesh). I'll try and get a
> version of this done with some code so people can see what I'm talking
> about. This will be good for a prototype but still leave a large
> amount of the rendering unoptimised (i.e. anything that isn't a mesh
> with subdivision turned on).
> The performance with display lists is much better but it looks as
> though the next bottleneck is going to be calls to glFinish that
> happen in various places. These screenshots show some statistics
> gathered with the Apple OpenGL Profiler when running the test scene:
> From the code it seems as though a number of the glFinish calls are
> due to problems with GeForce cards but I can't see why the rest are
> there and can't be replaced by glFlush or removed altogether.
> Both calls effectively flush the rendering pipeline to guarantee that
> drawing will complete at some point. However, glFinish does not return
> until all OpenGL drawing is guaranteed to be complete (effectively
> stalling the CPU / GPU and killing performance), whereas glFlush
> guarantees that all OpenGL drawing will finish in a finite time.
> Surely the only flush that is needed is the implicit flush when
> swapping buffers after drawing a frame?
> There are only two other reasons I can think of where you'd need to
> use glFinish / glFlush:
> 1) some GUI related stuff related to GHOST that I haven't looked at
> 2) reading back the framebuffer (i.e. when doing an OpenGL render and
> then saving the image).
> Any clarifications on this would be great.
> Is anyone else working on this? I couldn't find anything in the
> mailing lists. I do have a broader plan of attack for a more
> generalised rendering framework (which would include improvements to
> the OpenGL 3D view, OpenGL render and probably the game engine) if
> anyone's interested.
> r i c k
> Bf-committers mailing list