[Bf-committers] OpenGL optimisation

[Jasper Mine]

Your optimization works well.  Official Time: 00:00.19, Custom Time: 
00:00.13 averaged.  This is very cool.

jsplifer


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:
>
> http://www.warwick.ac.uk/student/R.J.Berry/customblender.zip
> http://www.warwick.ac.uk/student/R.J.Berry/benchmark.blend
>
> 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:
>
> 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).
>
> 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
>