Hi, Some questions:
- Is it really defined that we are moving to Embree? - Do we just abandon all existing wider BVH patches? - What are the numbers of using Embree's builder but our current (and BVH8 patch) traversal? - What are the plans about wider BVH on GPU? - Do we accept duplicated intersection code? - Do we abandon GPU improvements all together? Surely, if we were CPU-only what Stefan says makes total sense, but before jumping full-speed into Embree everything, i want to know what is the actual roadmap, in both user-measurable features and how it's achieved from technological point of view. I do not want same story as with split kernel to be repeated, when it took lots of full-time months to get feature level on acceptable level, and have acceptable-ish amount of duplicated code (which is still a lot actually, and rather fully annoying). > 4. Extract BVH data from Embree and write GPU traversal code. To my knowledge you can provide Embree a custom node/primitive builder functions, so not sure what exactly "extract" mean here? On Mon, Jan 29, 2018 at 8:34 PM, Stefan Werner <stew...@gmail.com> wrote: > 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 <brechtvanlom...@pandora.be> > 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, Антон Гавриков < > gavrikovantonk...@gmail.com <mailto:gavrikovantonk...@gmail.com>> 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 > > Bf-committers@blender.org <mailto:Bf-committers@blender.org> > > https://lists.blender.org/mailman/listinfo/bf-committers < > https://lists.blender.org/mailman/listinfo/bf-committers> > > > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin _______________________________________________ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers