Hi Brecht, Anton, to get Embree to be a full replacement of Cycles’ own BVH, there are still a number of tasks to be done. From the top of my head, here’s what’s missing from my current branch:
1. Update to Embree 3.0.0, of which a first beta was just released. This should allow us to build with an unpatched Embree. 2. If we decide that it’s needed, implement a solid line segment/cylinder primitive for Embree. Embree has flat (ribbon) line segments, flat curves and solid curves but not solid cylinders. 3. Reduce the amount of duplicated data. Ideally, Cycles keeps all the geometry data in its own buffers and Embree accesses it directly through pointers. That may require resolving race conditions in interactive rendering. 4. Extract BVH data from Embree and write GPU traversal code. 5. Find out if it’s possible in the latest Embree to do quaternion interpolation of motion transforms - the 2.x versions are still limited to linear straight interpolation. If this isn’t there, motion blur quality will degrade. Once parity is reached, there are several features in Embree that could improve Cycles. Some of these may not work with the GPU: 6. Using Embree’s ray stream API for the CPU split kernel. 7. Embree’s built-in displacement. 8. Embree’s quad primitive. 9. Compare Embree’s subdivision implementation to Cycles’ and use it if it’s better. The on-demand cache could help reduce memory usage at the expense of performance. Feel free to take over any of these tasks. I would be happy to work on them myself, but as it stands I can’t make any promises regarding a time line. The embree integration in its current state is sufficient for our current production needs. I don’t expect to have a lot of spare time for extra polish in the next few months. The current state of my Embree integration is here: https://git.blender.org/gitweb/gitweb.cgi/blender.git/shortlog/refs/heads/cycles_embree <https://git.blender.org/gitweb/gitweb.cgi/blender.git/shortlog/refs/heads/cycles_embree> It does rely on a patched version of Embree which you can find in this branch: https://github.com/skwerner/embree/tree/cycles_compatible Don’t hesitate to ask if you have any questions about this. -Stefan > On 29. Jan 2018, at 18:58, Brecht Van Lommel <[email protected]> > wrote: > > Hi Anton, > > We're planning to move to Embree, so improving our existing BVH builder and > traversal is not the best use of time. > https://lists.blender.org/pipermail/bf-committers/2017-November/048936.html > <https://lists.blender.org/pipermail/bf-committers/2017-November/048936.html> > > However a lot of work is still needed to get the Embree integration stable, > and I imagine whatever the state will be this summer, there will be a lot > room for improvement. Finding optimizations in the integration, memory usage > reductions, etc. Some of the bigger topics would be: > * Use Embree for building the GPU BVH, so we can remove our own builder. > * For subdivision surfaces, implement more memory efficient grid primitive to > intersect directly. > * Optimizations for tracing short rays on a single object for subsurface > scattering, bevel, curvature. > > Stefan, do you have an idea about which tasks will be open still this summer? > > Regards, > Brecht. > > On Sun, Jan 28, 2018 at 11:07 PM, Антон Гавриков <[email protected] > <mailto:[email protected]>> wrote: > Hello, I worked on this (https://developer.blender.org/D2875 > <https://developer.blender.org/D2875>) project as a > summer intern in Intel. I would like to know if there is any interest in > working on this project in GSoC 2018. Or maybe there are any similar tasks > to optimize Cycles for new architectures. > > Regards, > > Anton. > _______________________________________________ > Bf-committers mailing list > [email protected] <mailto:[email protected]> > https://lists.blender.org/mailman/listinfo/bf-committers > <https://lists.blender.org/mailman/listinfo/bf-committers> > _______________________________________________ Bf-committers mailing list [email protected] https://lists.blender.org/mailman/listinfo/bf-committers
