[Bf-committers] OpenGL optimisation
Sun, 23 May 2004 19:46:24 +0200
Very interesting experiments, always good to have a performance review.
From your tests it is unlear to me what you actually are drawing. To me
it looks the statistics are polluted a lot by interface overhead.
A very reliable builtin method is using the '10 timer' (ALT+CTRL+T),
which can draw without swapping buffers too. Use that for more precise
Below you find mixed in some comments.
> 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).
Displaylists in Blender were meant:
- to have a uniform (and fast) system to display 3d objects in Blender.
- to enable operations on models (like deformation or subdivision
- to be used for conversion to render-faces for the render module.
- but, also (ab)used as intermediate format while importing
The Blender displaylist system is total mess, suffering from new
additions and requirements added over the years. During this process, I
also checked on performance with ogl-displaylists, but it never could
be used to replace our own displaylists, just because we need a good
(temporal) internal format for operations and rendering.
The power of opengl displaylists is in the fact you can use your own
code for a first 'draw' (= define ogl displaylist), and then use the
faster redraw feature of opengl. For Blender it would mean 'yet
another' copy of 3D in memory, where we already have (Mesh case):
- Mesh (compacted data for in files)
- Displaylist (after deform and/or subdivision)
- Render faces (temporal)
I rather look at a redesign for the Blender displaylists first... this
will - even without ogl displaylists - improve performance quite some
> 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:
Is there any way to see what added memory usage is?
> 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).
I always mix up the two... but the glFinish() is in Blender *only* used
because it gives for OSX and some PC cards actually a buffer copy
OSX (and some PC cards) doesn't support draw in frontbuffer... the
glFinish just does as extra a copy-buffer. This behaviour has been
officially confirmed by Apple dev support, but never made it in their
The glFinish() call should only happen for when menus or buttons are
redrawn in frontbuffer. Just exclude that from your testing for now.
> 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
Ton Roosendaal Blender Foundation firstname.lastname@example.org