> On 25 Jul 2017, at 05:13, Christopher Sean Morrison <brl...@mac.com> wrote: > > >> 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.
This is very useful! In the past I’ve always found success in resolving bugs by tracking the behaviour for a specific ray. I would do this manually, by filtering a specific id in the kernels, or by redirecting the output to a ‘txt’ file and then analysing it. This tip will make things easier in the future! Thank you! > >> 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. I did run the benchmark on the C version. As expecting, the benchmark for the OpenCL path failed, so I guess some things have to be fixed before getting this to work. I will keep this in mind. Cheers! Marco > > > 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 ------------------------------------------------------------------------------ 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
