> On Jul 21, 2017, at 1:41 PM, Marco Domingues <marcodomingue...@gmail.com> > wrote: > > I fixed the problem with the overlap handler and uploaded the patch in the > svn (https://sourceforge.net/p/brlcad/patches/472/). I’ve also uploaded some > more new images in my dev log with renders of scenes from the ‘share/db’ > directory, which can be found here: > https://brlcad.org/wiki/User:Marco-domingues/GSoC17/Log#20-21_July
This is really good looking progress. A note for debugging that might come in handy are features related to reshooting specific rays. If you render a view via rt and right-click (maybe middle-mouse click, depending on your settings) in the framebuffer window, it should report pixel values like this per click: At image (216, 219), real RGB=(141 141 141) At image (213, 201), real RGB=(157 156 157) At image (257, 224), real RGB=( 33 33 33) At image (268, 171), real RGB=( 82 82 82) You can then reissue the exact same rt command (e.g., rt -z1 -l5 …) with the -b "X Y" option (e.g., rt -b "257 224” …) to reshoot just that ONE single ray. That can be much easier to debug. Note there are also a slew of flags you can set for diagnostic debug printing as well including one specific to the boolean evaluation (-x2000). This can be used by itself or with the -Q X,Y option (note the comma) to reshoot all rays, but turn on debugging for just one specific pixel. Of course, debugging from the OpenCL side presents a challenge, but seeing the C code diagnostics might help with understanding or give you a place to break on in a debugger for the OpenCL code. > But I will gather some statistics for these scenes like execution times, > total memory allocated, max segments per partition, max regions involved per > partition and maybe we will have some other clues of possible optimisations > to make on the code! For what it’s worth, a holy grail will be getting the BRL-CAD benchmark to complete successfully (and faster!). You can try it by invoking “benchmark run” on the command line to get your baseline performance on the C version. Testing the OpenCL path would simply be: benchmark run -z1 It renders a set of baseline models, keeps track of timings, compares their rendered image with baseline references, and reports if they match. It’s both a performance test and a validation and verification framework. That’s obviously not going to pass now, but they are concrete examples with automated image comparisons, timings, well-known behaviors, etc. 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
