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