Hi, On Tue, Jan 30, 2018 at 9:32 AM, Sergey Sharybin <sergey....@gmail.com> wrote:
> 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. The way I see it is that there is still a lot of work, not so much open questions. > 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. > That's fine with me. > 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. > I don't think we have to implement 8-wide BVH traversal for the GPU, or any of the SSE optimizations or CPU specific tuning. I'm not sure what you would expect from such a test. If it's slower than Embree's traversal, then we can attribute that to our implementation not being tuned as much as theirs, which is what I would expect. If it's faster, then that would be interesting but it seems unlikely to happen? For me the big reason to adopt Embree is so we don't have to do all this optimizations for the CPU, we don't have to worry about SSE, AVX, 16-wide, pack triangle intersection, ray packet traversal, etc. > 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. > Yes, but we only need a simpler scalar version of it, with one BVH layout type. > Besides, wouldn't wider BVH solve the memory access bottleneck for CUDA by > doing less memory access? > Maybe, but we can investigate this with or without Embree. > Builder -- yes. Embree structures on GPU -- i'm not sold in this. > > Maybe you mean something else by "Embree BVH on GPU" ? > I mean using BVH built by Embree, stored in whatever way works best for the GPU. I don't think we can use any Embree data types directly on the GPU. Regards, Brecht. > > > > > 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 > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
