On Thu, Aug 10, 2017 at 5:15 PM, Christopher Sean Morrison <brl...@mac.com>

> ...
> Related to these specific changes, these numbers pass a sanity check.  If
> you ran a profile (e.g., perf), you’d see that only a fraction of time is
> spent in boolean code (10-30% of time, depending on the model).  The other
> 2/3rds are roughly in traversal and intersection code.  It would be
> interesting to have isolated timings of just the boolean evaluation, but
> we’d still want to run the benchmark to see what the big picture impact is
> (and verify we’re still getting valid results).

Yes, this is something we need to do. First we made a relatively simple
prototype that demonstrated the functionality in OpenCL. Then we started
changing it to not to have worse worst case complexity than the code in
trunk/. But we must do proper code profiling eventually. The time spent on
each stage is important, as is the processor utilization rate, and memory

We need to have the profile data to guide future work on optimizing the
code. I wouldn't be surprised if when Marco is done with these changes the
OpenCL backend will be 2-3x faster than the existing code. But I'm not sure
how much faster we can go without major algorithmic changes. Does the
current code use one thread per physical processor or does it use one
thread per virtual processor (i.e. Hyperthreading)? If it does use SMT
perhaps the 8x I thought were possible are actually impossible to achieve
and a ~4x performance increase is the best we can hope for with the current

I have some ideas on how to reduce thread divergence in the OpenCL pipeline
to further improve performance but those go beyond the scope and time frame
of this GSoC. If the 2-3x gains in performance over the same CPU hardware
do materialize though that is certainly nothing to sneeze at.

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

Reply via email to