Blender 2.5 – r25127 – SSE optimisation for Renderer

I have uploaded 32bit and 64bit builds to graphicall.org that have SSE optimisation for the renderer enabled. This is not a default setting, but I thought it’d be good to get some testing results out of it – whether it causes render artifacts or not, and such.

To use any of the optimisations, check the Performance panel in render settings. The Auto setting tries to select the best optimisation strategy, but you can choose any of the other ones too. Octree is what we know from the previous Blender series, all the new names are from the GSoC work done by André Susano Pinto (jaguarandi).

6 Responses to “Blender 2.5 – r25127 – SSE optimisation for Renderer”

  1. Claudiney Ribeiro said:

    Dec 04, 09 at 11:22

    How did you set the Optmizations?
    Could I see the userconfig file?

  2. jesterKing said:

    Dec 04, 09 at 13:25

    The modifications where set with a modification to the SConscript for the renderer: http://www.pasteall.org/9603/diff

    Note that this way is not the final way. I’ll be working on setting the optimisations only for those files that actually need them. That will require some extra work on this SConscript, though.

  3. Atom said:

    Dec 04, 09 at 15:04

    I am experiencing some strange failures when I use the acceleration structures in version 25127 even with Instances not checked. I have a scene with lot of objects in it. 90% of the objects (around 100) are empties that are dupligrouping meshes that reside in other scenes. What happens is after I render a couple of frames using F12 the empties in my scene quit relaying the mesh information effectively becoming empty axis in space, only showing their axis arrows in the 3D view. I have checked the empties properties and they still say they are dupligrouping. If I save the file in this state and reload it, all my meshes are gone. It looks like the acceleration routines are mangling the mesh connection to the 3D viewport after a render (sometimes). That is the wierd thing, it only happens some times and sometimes it happens quicker if I try different accelerators between renders. Currently SIMD SVBVH is locked up trying to render a scene that take the other accelerators only 11 seconds to process.

    I see this same problem occur on a WindowsXP64 system with 3GB and 8GB so I do believe there is enough memory to render the scene. Blender reports the scene memory weight as 350 megs. As I ESC out of the locked up SMID SVBVH I notice the scene weight drops to 49 megs and now all my asteroids are gone. Scrubbing does not bring them back.

  4. jesterKing said:

    Dec 04, 09 at 16:34

    If you can reproduce this with only one dupligroup, that’d be great, the scene as simple as possible.

  5. jesterKing said:

    Dec 04, 09 at 16:38

    Actually, I noticed that my patch is not enough. I’ll be uploading some new patch and builds in a few moments, where the SIMD optimisations *really* are in use. It required a bit of a header, but that shouldn’t be too intrusive.

  6. jesterKing said:

    Dec 04, 09 at 18:28

    Improved builds here: http://www.letworyinteractive.com/b/2009/12/blender-2-5-%e2%80%93-r25133-%e2%80%93-sse-optimisation-for-renderer-part-ii/

    If you get the latest SVN (r25135 as of this writing), you can enable the raytracer optimisations by specifying WITH_BF_RAYOPTIMIZATION=True in your user-config.py


Leave a Reply