[Bf-committers] GSoC 2018 BVH8

[Sergey Sharybin]

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 <stewreo at 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 <brechtvanlommel at 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, Антон Гавриков <
> gavrikovantonkapi at gmail.com <mailto:gavrikovantonkapi at 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 at blender.org <mailto:Bf-committers at blender.org>
> > https://lists.blender.org/mailman/listinfo/bf-committers <
> https://lists.blender.org/mailman/listinfo/bf-committers>
> >
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
With best regards, Sergey Sharybin