[Bf-committers] OpenGL optimisation

Richard Berry bf-committers@blender.org
Sun, 23 May 2004 15:33:29 +0100

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 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 yet,
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