I hope there isn't an issue here because we are using a BVH rather than a
spatial subdivision like the kd-tree.
In a BVH the nodes aren't necessarily ordered in a way where their contents
are in spatial order.
On Mon, Aug 21, 2017 at 7:08 PM, Marco Domingues <marcodomingue...@gmail.com
> wrote:
>
> > On 20 Aug 2017, at 00:18, Vasco Alexandre da Silva Costa <
> vasco.co...@gmail.com> wrote:
> >
> > This patch took me a bit longer to read and evaluate because I haven't
> been so well lately (sick with the flu) but here it is:
> >
> > Congratulations to Marco Domingues for competing this major GSoC
> milestone!
>
> Thank you! I’m really happy to see my work finally on the trunk :) but
> there is still some work to do to make the code more efficient!
>
> >
> > This code has enough performance that it can be used as an alternative
> to the existing ANSI C code. Right now it has roughly the same order of
> performance on scenes with small depth complexity. However the performance
> improvement we expected with OpenCL hasn't materialized yet, the current
> iteration of the OpenCL backend still lacks important optimizations which
> are done in the ANSI C backend, like stopping ray traversal once the
> boolean evaluation detects a solid hit. Currently we are processing all
> hits. This is obviously more compute intensive.
> >
> > So we have talked about how to improve the performance by refactoring
> this code and came up with some ideas. Marco will be working on performance
> improvements over the remaining time we have left for the GSoC.
>
> Yes, I have been working really hard on this optimization, trying to get
> this to work by the end of the GSoC period (one week left). To give some
> context, this optimization is about merging the three OpenCl kernels
> (‘store_segs’, ‘rt_boolweave’ and ‘rt_boolfinal’) into a single kernel, to
> allow the weave of segments and evaluation of partitions to be done as soon
> as the first segments are calculated, which would avoid the unnecessary
> total ray traversal.
>
> After some intensive debugging, I found the bug that was causing the ray
> tracing to crash with this new rendering loop, and although there are still
> some bugs to be fixed, the results look very promising.
>
> The havoc scene now renders in 0.36 sec vs 0.78 sec previously. This when
> using the command ‘rt -z1 -s1024’ for the view: az 35 el 25. For reference,
> the ANSI C code renders this same scene in 0.63 sec, command ‘rt -s1024’,
> same view.
>
> As I mention before, there are still some bugs with this new system, i.e
> some pixels appear to be rendering the wrong object. My guess is that some
> partitions are being evaluated too early but I still need to investigate
> this issue with more detail.
>
> I will keep working on this and hopefully I can get this bug fixed in the
> next few days!
>
> Cheers!
> Marco
>
> >
> > What this patch does allow right now is to render CSG boolean
> operations, like object intersections or subtractions, over either CPU or
> GPU platforms, or even more exotic hardware like FPGAs which support
> OpenCL, which is something that we couldn't do previously. The prior code
> only ran over single-threaded CPUs with ANSI C. Another thing this work has
> allowed was to clean up and understand better the behaviour of the current
> ANSI C bool code which probably hadn't been touched in a really long time.
> >
> > I still hope we'll eventually get like a 3-4x performance improvement
> with this vector OpenCL librt backend over the scalar ANSI C version
> running over a modern CPU.
> > The performance could be even better than that if we further reduce
> thread divergence and modify the data structure but it seems this will take
> more effort.
> >
> > So we have achieved our initial goal with OpenCL boolean evaluation, but
> there is still some more work to be done in this for sure, and hopefully
> also in future GSoCs,
> >
> > Regards,
> >
> > --
> > Vasco Alexandre da Silva Costa
> > PhD in Computer Engineering (Computer Graphics)
> > Instituto Superior Técnico/University of Lisbon, Portugal
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot______
> _________________________________________
> > BRL-CAD Developer mailing list
> > brlcad-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
--
Vasco Alexandre da Silva Costa
PhD in Computer Engineering (Computer Graphics)
Instituto Superior Técnico/University of Lisbon, Portugal
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
