Page MenuHome

Cycles: Embree improvements
Confirmed, HighPublicTO DO



  • Verify performance and memory usage is close to existing CPU render
  • Disable compact BVH or make option (worse performance, only little memory usage reduction)
  • Investigate reducing memory usage by deduplicating Cycles and Embree geometry
  • Fix Warning: pthread_setaffinity_np failed to set affinity to thread -1 printed in console on Linux (rBc7329da14b22)


  • Fix Leaking of exports into the blender binary on windows though dllexports when building it as a static lib ( rB4155f8dc21a9 / rBL62441 )

Differences in Render Tests

  • D6575: Cycles: Enable quaterion motion blur in Embree.
  • multi_step_motion_blur.blend not showing motion blur
  • ambient_occlusion_only_local.blend crash
  • Shadow catcher test failures
  • Hair motion blur tests broken after change to catmull-rom
  • Line segments are rendered as ribbons, which breaks principled hair and other tests
CYCLESTEST_ARGS="--python-expr \"import bpy; bpy.context.scene.cycles.use_bvh_embree = True\"" ctest -R cycles

Revisions and Commits

rC Cycles
rB Blender

Event Timeline

Brecht Van Lommel (brecht) changed the subtype of this task from "Report" to "To Do".Feb 14 2020, 9:10 AM

It seems Embree does not have an equivalent of our Thick Line Segments. In the current patch they are rendered as Flat/Ribbons, which gives entirely different results for e.g. the principled hair BSDF.

We can either add our own line segment primitive, or hope the Embree curve rendering is fast enough and port it to the GPU.

From testing I think all the bad differences are due to the lack of support for thick line segments.

I ran the basic benchmark scenes with Embree, performance is improved in all cases. Mainly the hair is faster. These scenes don't test motion blur, where the biggest speedups will be.

AMD Ryzen 2990WX, Ubuntu Linux


Peak memory is cut in half in the hair scenes (did not investigate why, but not hard to imagine Embree BVH is better at this), and a couple % lower for other scenes. So in terms of performance and memory usage, everything seems to be fine.

Thick line segments could be emulated through spline primitives at the expense of wasted memory.

The main purpose of line segments is to have better performance. I'm not sure how expensive spline primitive intersections is compared to curves?

I'm hoping we can just remove line segments if the curve performance is good enough.

I've ported the Embree code for rendering catmull-rom curves and ribbons to Cycles for GPU rendering.

Fr thick curves it's significantly slower than our previous code with default number of subdivisions. I haven't worked on optimizing the GPU code (there's a few things to check but not sure there is anything to close the gap). Also on the CPU I'm finding some slower performance now.

It makes sense in that the Embree code subdivides to float error precision, while we only use a fixed number of subdivisions. And it shows in close ups. But if the hair is small, there's not really any need for that kind of precision.

I'll need to check if there are some cheaper things we can do, either reducing the precision for thick curves somehow, or computing normals for ribbons that make them look like thick curves.

So I'm really struggling to get the Embree intersection code for thick curves to perform well on the GPU. It's still around 1.7x slower than our existing curve rendering.

Reducing the number of subdivisions/iterations leads to artifacts and fireflies. I was hoping we could skip backfaces more efficiently by doing it in the intersection code. But I don't see a way to do it with the iterative refinement that the algorithm is using, the far intersection seems to start with a back-facing hit but then can become front-facing as it iterates closer to the solution.

Maybe there are ways to reduce register pressure or other code reorganization that can help, but I'm not seeing obvious ways to do it.

It's also higher quality than our existing code, and just involves a lot more float ops. Probably more than you need in practice unless you're looking at hairs really up close. The next thing I want to try is to use ribbons and compute rounded normals for them. If that works ok it could be a good default, with thick curves as a fallback for when you need to render hair really up close.

For a hair shader like Principled Hair we don't even need a normal.

Thick line segments are now supported in Embree 3.9.0.

Brecht Van Lommel (brecht) triaged this task as High priority.Jun 18 2020, 5:43 PM
Brecht Van Lommel (brecht) renamed this task from Cycles: default to Embree for CPU ray tracing to Cycles: Embree improvements.Jul 22 2020, 10:56 AM