Differential D818
(WIP) Initial Implementation of Embree Authored by Thomas Dinges (dingto) on Oct 7 2014, 11:51 AM.
Details
Just posting this here for reference.. Initial implementation of Embree API. Issues: Too many, but it renders a cube. ;) Also lib path is hardcoded for Mac OS. Idea: We probably cannot use Embree API for all the features we have in Cycles, but as a reference or even beneficial for simpler scenes (with mostly geometry), like BMW, this might be great. Embree releases new versions every 2-3 months atm, by using the API we can simply upgrade a lib and benefit from the latest improvements.
Diff Detail Event TimelineComment Actions Hey Sergey, There is something wrong with this still, for the default cube a face is missing, and scenes like bmw have severe artefacts. I suspect the prim_index to be wrong / different between our BVH and this. Anyway, it does not need to be pretty imho, but it would be nice to have a hacky integration working, so we can measure performance in simple scenes like BMW, and compare to our own implementation. Would be interesting to see how big the performance gap is between Embrees QBVH and D819. Comment Actions We're calculating barycentric coordinates different from Embree, so at least you need to change triangle winding to (2, 0, 1) afair.
Comment Actions @Sergey Sharybin (sergey): Sorry, not sure what you mean exactly, where does this need to be changed? Also CC'ing @Brecht Van Lommel (brecht), as he hacked in Embree a while back, maybe he has an idea too. :) Comment Actions
This is still not fully working, but I could render a Sky + Suzanne with subsurf 5. Comment Actions In this simple test though (with current patch), I get a nice speedup with Embree.  Embree off: 21.33 seconds That is a speedup of ~28%. Image looks 100% the same. I need to fix the index issue though, because once I add more objects I get visible errors. Comment Actions We talked about this in email actually. The speedup is nice but it really worth studying where the speedup is coming from. For example, if it's because of QBVH (which is already in master), or is it because of more extense intrinsics usage (single ray to multiple triangles intersection), or is it because of smarter approach to shadow rays? or because of using SPMD? It all worth checking on it's own. I don't really see what we can achieve by using external library and what we can not do with just doing a proper sources port into kernel. But there's a pile of issues you would never solve by doing such a port. For example, 2x memory usage, much fatter blender and so. Would really rather see people doing sources port, not the library usage. P.S. This could be a nice experiment, but would not expect it to be accepted to blender's master. | ||||||||