[Bf-committers] GSoC 2018 BVH8

Tue Jan 30 09:32:57 CET 2018

Hi,

Answers are inlined.

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

Was more like discussed, and agreed that it's still lots of open ends in
there?

With the current state it is not really convincing that it's THE way to
go.It will become THE way to go when we will know answers to those open
ends, which will not increase already tedious burden of GPU support.

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

Yesterday we've been discussing with Maxym putting BVH8 and packeted
triangle intersection to master, under BVH8 option (similar to what we had
for BVH4 back in the days).

>From what i see that patch matured faster than all the open ends of Embree
integration project.

> > - 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?
>

I didn't get it, yet again.

Well, sure, as Stefan mentioned above, there is no way for a custom node
builder function to know orientation for hair BVH, but i don't see why
would AABB BVH take long time to do such a test.

Further, (as Stefan mentioned already), you would HAVE to implement that in
one way or another in order to use BVH built by Embree on GPU.

And last but not least here, you would HAVE to duplicate Embree code in one
way or another: primitives intersection on GPU is something you would HAVE
to re-implement.

> - What are the plans about wider BVH on GPU?
>
> No plans that I know of.
>

ProRender had some wider BVH, afair. And Nirved was working on the patch,
but i'm not sure what exact reasoning of lack of speed improvement.

Besides, wouldn't wider BVH solve the memory access bottleneck for CUDA by
doing less memory access?

> - Do we accept duplicated intersection code?
> >
>
> For the GPU yes, that would be a BVH2 without any SSE code.
>

It's not juct BVH, but also primitives intersection, which would need to
match what's happening in Embree.

> > - Do we abandon GPU improvements all together?
> >
>
> No?
>

Good.

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

Builder -- yes. Embree structures on GPU -- i'm not sold in this.

Maybe you mean something else by "Embree BVH on GPU" ?

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

-- 
With best regards, Sergey Sharybin