On Wed, Jul 19, 2017 at 7:05 PM, Marco Domingues <marcodomingue...@gmail.com
> wrote:
> On 19 Jul 2017, at 02:50, Vasco Alexandre da Silva Costa <
> vasco.co...@gmail.com> wrote:
> Think about it. Two adjacent partitions will write in overlapping memory
> areas of the regiontable bitarray. You don't want that.
> Also I think this same error is in other bitarrays you have.
>
> You are right, that was wrong and it was causing scenes with more than 32
> regions to have missing evaluated partitions! Thanks for pointing that out!
>
That's what I'm here for. :-) Eventually you'll get used to it. Sometimes,
when I have a hard time understanding memory issues, I find it helps to
draw a little schematic on a piece of paper and then trace a couple of
iterations on it to help me visualize the problem.
I fixed that section of the code and now it is iterating only over set
> bits! Thanks for the help!
>
This one was not a bug in your code. But it should boost performance on
very sparse bitarrays and it's a simple change to make.
Imagine you have a 32-bit uint where the only bits set are the first and
last bits for example. It should be like 3 loop iterations instead of like
32 loop iterations.
> I also found the reason for the weird results when drawing geometry with
> the command “e *”. It is a bug in the overlap handler that also causes some
> partitions to be missing in scenes with occurrence of overlaps. I’m working
> on a fix!
>
Great! Hopefully we'll squash all of these bugs.
> Thanks for the feedback on the code! As soon as I fix the problem with the
> overlap handler I will update the patch in the svn, and hopefully we can
> start looking into optimizations!
>
Yes, once the code stabilizes we should profile it on a set of test scenes
(e.g. operators.g, goliath.g), then figure out where those bottlenecks are
located.
> P.S: I noticed that the ‘bool.cl’ file is missing in the opencl branch
>
Duh. Nice catch! My mistake. :-P I'll get on to it.
Regards,
--
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
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
