> On 19 Jul 2017, at 02:50, Vasco Alexandre da Silva Costa
> <vasco.co...@gmail.com> wrote:
>
> On Mon, Jul 17, 2017 at 11:23 PM, Marco Domingues <marcodomingue...@gmail.com
> <mailto:marcodomingue...@gmail.com>> wrote:
> Hello,
>
> As combined, I have made some improvements on the code (based on Vasco’s
> feedback) and implemented an overlap handler
>
> This is one of those words where Portuguese does not translate well into
> English.
> Instead of 'combined' it is better to say as 'discussed' or 'agreed' upon.
>
> There are still some bugs in the code as:
> Incorrect shading for some partitions (some normals seem to be off)
> This is quite likely because of the issue with primitive ids being in BVH
> order on the OpenCL side that we talked about on IRC.
> Some more complex scenes have less partitions evaluated than expected. (I
> believe this issue comes from some partitions reporting overlap when they
> shouldn’t, but still have to further investigate what is causing that)
> Apart from that, the results look promising and ok for most scenes I have
> tested (this includes the scenes 'share/db/operators.g' and
> 'share/db/boolean-ops.g'). Some images can be found here:
> https://brlcad.org/wiki/User:Marco-domingues/GSoC17/Log#12_-_14_July
> <https://brlcad.org/wiki/User:Marco-domingues/GSoC17/Log#12_-_14_July>
>
> Right now, I am using a bitarray to represent the regions involved in each
> partition, and this seems to be an inefficient solution, because of the high
> number of regions that some complex scenes have (to evaluate one partition
> and to resolve any overlap that may occur, I have to iterate over all the
> regions and test the bits, which can be very slow for some scenes).
> The ‘share/db/goliath.g’ scene has a total of 1447 regions, and despite that,
> the max number of regions involved in one partition is 15 (from some
> profiling I made over the ansi c code).
>
> If the issue is with the partition bitarrays try making an intermediate step
> where the bitarrays from rt_boolweave are converted into integer lists prior
> to rt_boolfinal or the render phase.
> I think this algorithm should be simpler than modifying rt_boolweave to use
> lists. For one you won't need dynamic lists. You can use popcnt to count the
> number of bits in each bitarray (complexity is amount of bitarray words) then
> sum that to compute the amount of memory to allocate and then allocate an
> array where you store the ids of the region bits set on each partition.
>
> If you want to reduce the amount of bits on the partition segment bitarrays,
> you can also consider that you only need a bitarray for a partition to be the
> size of the amount of segments in that specific ray, not the max amount of
> segments on the largest ray segment list. This complicates the code a bit but
> should significantly reduce the amount of memory required to store the
> bitarray on complex scenes.
>
> As for the regiontable bitarray in rt_boolfinal, I don't see you initialize
> it to zero in the OpenCL code, plus it seems to me like all the ray threads
> are writing to the same memory space so there are bound to be errors in it,
> i.e.:
>
> build_regiontable()'s pp_idx = current_index which is the id of a partition.
> You use:
> set(regiontable, pp_idx + (rt_index - 1), m) i.e.
> regiontable[pp_idx + (rt_index - 1) + bindex(m)] & bmask(m)) i.e.
> regiontable[current_index + (total_regions/32 + 1 - 1) + (m >> 5)] & (1 << m)
>
> this doesn't look correct. this seems more like what you want:
> set(regiontable, current_index * rt_index, m)
>
> 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!
>
> Also your code to iterate the bitarray is still inefficient. You check the
> leading zeros in an uint but then you iterate the bits one by one over that
> to iterate over all set bits. This should be faster:
>
> uint mask; /* initialized with some bits set. */
> uint i, n;
> i = 0;
> while (mask != 0) {
> n = clz(mask);
> i += n;
> /* bit 32-i is set */
> mask <<= (n+1);
> }
>
> or some variation of this.
>
> In the next days I’m planning to work on replacing the bitarray to a solution
> that uses a list to represent the regions involved in each partition
> (regiontable), which despite using more memory, should be considerably faster.
I fixed that section of the code and now it is iterating only over set bits!
Thanks for the help!
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!
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!
P.S: I noticed that the ‘bool.cl’ file is missing in the opencl branch
Cheers,
Marco
>
> --
> 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
------------------------------------------------------------------------------
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
