Thanks for the running updates, they are indeed appreciated! On Jun 16, 2015, at 12:38 PM, Vasco Alexandre da Silva Costa <vasco.co...@gmail.com> wrote:
> Use OpenMP to spawn rendering threads. Eeep, I like OpenMP and it’s fine for early testing, but it is desirable to avoid it in our production pipeline (where we definitely want parallelism). It precludes/complicates moving that code into libraries. Calling bu_parallel() is a working alternative to simple omp parallel for pragmas by simply extracting the code into a function. > The code has some bugs in it. I think its improper initialization of the > resource pools which leads to a spurious double free. But I haven't been able > to find out exactly where the bugs are. Valgrind ftw. ;) > - Added the main boolean weaving code. Eliminated gotos in boolfinal. Not a trivial feat, kudso. How did you make sure it still works correctly? > The main obstacle to an OpenCL port is, as I expected, the boolean code which > is branch and goto heavy and uses dynamic linked lists. The linked lists aren’t really necessary and are easily replaced by per ray segment arrays, but making it work with arbitrary segment counts will be tricky book-keeping. > What I did not expect was that the total LOC count in that boolean weaving > code dwarfs everything else put together (traversal, ray generation, shade, > writing to the frame buffer). There’s several reasons why I originally suggested it as the sole project objective. ;-) > The current code already supports threaded execution with some heavy app > context data structures. These probably have too large of a memory footprint > per thread for the kind of fine grained parallelism with thousands of threads > in flight that we desire (see 'struct resource’). s/probably/definitely/ > As discussed with Sean a couple of days ago I am going to stop working on > this angle and start working on the grid spatial partitioning in OpenCL next. Cool. Cheers! Sean
------------------------------------------------------------------------------
_______________________________________________ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
