> On 26 Jul 2017, at 06:54, Vasco Alexandre da Silva Costa
> <vasco.co...@gmail.com> wrote:
>
> On Tue, Jul 25, 2017 at 9:54 PM, Marco Domingues <marcodomingue...@gmail.com
> <mailto:marcodomingue...@gmail.com>> wrote:
>> On 25 Jul 2017, at 20:49, Vasco Alexandre da Silva Costa
>> <vasco.co...@gmail.com <mailto:vasco.co...@gmail.com>> wrote:
>>
>> It is amazing how c) and d) are so much slower than b). It should have only
>> been like 2x slower. I guess this is due to the larger working set in
>> memory. With the list of segments spread over a large amount of memory the
>> 'shade_segs' phase will have poor memory coherency. It is particularly bad
>> in goliath.g which is the scene with most depth complexity.
>
> I take my comment back. It seems this is just because it needs to traverse
> the segments 3x vs 1x.
> So it usually takes around 3x as much time.
>
> Regarding memory consumption and complexity I have more comments to make.
> [[
> I've been thinking about how we can further reduce memory consumption...
>
> sizeof() this:
>
> struct hit {
> double3 hit_point;
> double3 hit_normal;
> double3 hit_vpriv;
> double hit_dist;
> int hit_surfno;
> };
>
> vs this:
>
> struct hit {
> double hit_point[3];
> double hit_normal[3];
> double hit_vpriv[3];
> double hit_dist;
> int hit_surfno;
> };
>
> 8*4*3+8+4 = 108 bytes vs
> 8*3*3+8+4 = 84 bytes
>
> i.e. a compression ratio of 1.29x on struct hit BUT at the expense of lots of
> source code changes on the primitives.
>
> As for struct partition, we could use pointers to hits or indices to hits
> instead of storing the actual hits. like:
> idx = (seg_idx << 1) + (in|out)bit .
>
> This should save a lot more memory on the partitions. Like 238 bytes vs 30
> bytes i.e. a compression ratio of 7.93x.
> However it would increase memory trashing quite a lot. So we should at least
> store cache the 'hit_dist' for the hits.
> This would be 46 bytes per partition i.e. a compression ratio of 5.17x.
> With struct hit pointers it would be 54 bytes per partition i.e. a
> compression ratio of 4.40x (with 64-bit pointers).
> ]]
>
> To put it short: my advice is that you change struct partition from storing
> copies of the struct hits to having pointers to the struct hits. i.e.
> struct partition {
> global struct hit *inhit;
> global struct hit *outhit;
> uint inseg;
> uint outseg;
> ...
> };
> That should save quite a lot of memory at the expense of some memory pointer
> chasing. Which can be mitigated with a 'hit_dist' cache for the inhit and
> outhit.
>
> Also, let me get this straight, the ANSI C code rt_boolfinal gets partitions
> from an input queue, evaluates them, and puts the valid ones in an output
> queue. You also evaluate them, but then you just mark the valid partitions as
> such. While this does save memory, it may make the final shading stage take
> more time than it would otherwise because it needs to skip invalid partitions.
>
Hm I guess one alternative would be to have a buffer for the output queue (a
buffer of cl_uints with the indexes of the partitions evaluated) but unless we
run the rt_boolfinal kernel 2 times (1st to count the number of partitions
evaluated and 2nd to store the partitions evaluated) I don’t see how it would
skip invalid partitions. We would have to test the output queue buffer against
UINT_MAX in the shading process, which would be similar to the ‘pp->evaluated’
test I do. Maybe I am missing something?
Regards,
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
