On Fri, Aug 11, 2017 at 12:40 AM, Vasco Alexandre da Silva Costa <
vasco.co...@gmail.com> wrote:
> PS: If you really wanna know what I think is happening i suspect that in
> complex scenes, where the bitvectors are really sparse, we would have been
> better off using lists like the ANSI C code does instead. But the thing is,
> I don't like the fact that the ANSI C code uses bu_pbtl_ins_unique()
> either. I suspect we are better off emitting all the entries in a list and
> removing the duplicates later. The other issue that should be causing
> slowdowns is that the ANSI C code in rt_shootray() intersects one solid at
> a time and calls rt_bootfinal() on the partial results before continuing.
> In scenes with high depth complexity this means it will terminate earlier.
> So if you want an apples to apples comparison you'll have to force the ANSI
> C code to also process all the hits.
>
> To solve the first problem means we'll need more compute kernels which we
> don't have currently (e.g. prefix sum, reduce, radix sort) and to bound the
> memory used. To solve the second problem means we need to rethink how to
> process the primitives and change the rendering loop.
>
PPS: Needless to say this is outside the scope of the current GSoC. However
it would be nice if we could identify the bottlenecks so this can be solved
later on. One way would be to measure the size of the these intermediate
lists, with and without duplicates, the size of the bitvectors and the
sparsity of the same bitvectors.
The current bitvector code is a lot simpler than code that uses lists
because it has much, much simpler and more predictable memory usage and
compute algorithms. If it's a win in performance terms or not though,
depends on a lot of factors related to the type of scenes being processed.
If we used the lists with sorts those could also end up being quite slow.
While something that uses a linear time list insertion function, like the
current code, should not be exactly fast either.
--
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
