[Bf-committers] OpenGL optimisation

[Ton Roosendaal]

Hi,

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  
testing values.

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  
surfaces).
- 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  
already.

> 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?

> http://www.warwick.ac.uk/student/R.J.Berry/without-displists.png
> http://www.warwick.ac.uk/student/R.J.Berry/with-displists.png
>
> 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).

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  
("swap" buffer).
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  
docs...

The glFinish() call should only happen for when menus or buttons are  
redrawn in frontbuffer. Just exclude that from your testing for now.

-Ton-


> 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
> Bf-committers@blender.org
> http://www.blender.org/mailman/listinfo/bf-committers
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton@blender.org  
http://www.blender.org