[Bf-committers] GSoC 2018 BVH8

[Brecht Van Lommel]

Hi,

On Mon, Jan 29, 2018 at 9:10 PM, Sergey Sharybin <sergey.vfx at gmail.com>
wrote:
>
> - Is it really defined that we are moving to Embree?
>

Didn't we decide this in the Blender Conference meeting? We can always
change our mind, but that's the working assumption I also mentioned in the
meeting report.


> - Do we just abandon all existing wider BVH patches?
>

I was assuming there would be some further fix or explanation for the
speedup being 2-3% instead of 10-15%, and waiting for how quick the Embree
integration would mature. If someone likes to push those forward that's
fine with me, since I guess there's some time still before we have Embree
ready for master.


> - What are the numbers of using Embree's builder but our current (and BVH8
> patch) traversal?
>

It would take significant time to implement that. Why would we duplicate
this Embree code if we can avoid it?

- What are the plans about wider BVH on GPU?
>

No plans that I know of.


> - Do we accept duplicated intersection code?
>

For the GPU yes, that would be a BVH2 without any SSE code.


> - Do we abandon GPU improvements all together?
>

No?


> 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).
>

Right, it depends what we decide is the minimum requirement for this to be
merged into master. In my opinion, removing our own BVH builder and using
the Embree BVH on the GPU would be a requirement.

Regards,
Brecht.


> 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
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>