> I did some testing over the trunk code, to compare the performance between
> the bool_eval() function there and the version in the OpenCL branch. I added
> the column with the results to my previous table, which I attach with this
> email. It looks like the version in the trunk is faster, and the difference
> becomes quite noticeable once the model complexity grows.
Rewrites of the goto-happy C version to have fewer jumps has been attempted
many times, all resulting in slower code or different (incorrect) results. Of
course none of them really had coherency in mind.
One interesting one was a rewrite in java, which circumvented the entire
approach with a simpler direct evaluation of the Boolean expression (see
Tree::evaluate() and the Partition class operators):
https://svn.code.sourceforge.net/p/brlcad/code/jbrlcad/trunk/src/main/java/org/brlcad/geometry/Tree.java
<https://svn.code.sourceforge.net/p/brlcad/code/jbrlcad/trunk/src/main/java/org/brlcad/geometry/Tree.java>
https://svn.code.sourceforge.net/p/brlcad/code/jbrlcad/trunk/src/main/java/org/brlcad/geometry/Partition.java
<https://svn.code.sourceforge.net/p/brlcad/code/jbrlcad/trunk/src/main/java/org/brlcad/geometry/Partition.java>
This not only works but fixed a bug in the C boolweave code where wrong normals
might get used because it makes decisions without regard for the CSG operation.
I’ve always thought it would be really interesting to re-transcode the Java
version back to C to see what the performance impact would be. Almost
certainly more incoherent, but probably much easier to optimize (and maintain).
> Figures. It would be too good to be true otherwise. We will have to prototype
> a new tree storage structure and bool_eval() in ANSI C.
> Then port that over to OpenCL. This is a chance to make a contribution to the
> state of the art. We'll precompute all the jumps and store them in the tree.
++1
For that table, it would be informative to see a comparison with rt -l5 -s1024
(i.e., without -z1). What’s the distinction of the first two columns (e.g.,
havoc 1.208s vs 2.198s)? That is, what change resulted in havoc being 1.9x
faster?? That’s unexpected.
Also, what’s the VGR number on your test machine? My laptop (~7K VGR) renders
havoc -s1024 in 0.39s (2.4M rays/s) …
Cheers!
Sean
------------------------------------------------------------------------------
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
