(L) [2012/05/15] [ost
by jbikker] [Re: Improving Data Locality for Efficient In-Core Path Traci] Wayback!>> TheSFReader wrote:Received the link. Thank you. Can we discuss it publicly, or shoud discussions remain "hidden" ?
Please, by all means, lets discuss it. [SMILEY :)]
(L) [2012/05/15] [ost
by TheSFReader] [Re: Improving Data Locality for Efficient In-Core Path Traci] Wayback!A simple question then : wouldn't it be beneficial to keep a list of the full queues linked to each node in addition to the partial one ? This way, if there is more than one full queue, you can process them sequentially, again gaining some locality ? (The benefit may be of course overridden by the additional management).
I think some kind of linked list could be used without too much problems, no ?
(L) [2012/05/15] [ost
by jbikker] [Re: Improving Data Locality for Efficient In-Core Path Traci] Wayback!Yes, I suppose this makes sense. Currently, full queues are placed in a linked list of full queues, but in random order. For the initial batch of primary rays this is not a problem, since only the node containing the camera will be producing large amounts of full queues, but later on in the process (when locality starts to matter), this is not exploited. I am not sure how much it will matter, should not be too hard to try. It's just a matter of adding the full queue not only to the list of full queues, but also to a list for the node, as you proposed. Perhaps it's even worthwhile to process the partial list for the node as well when the full lists are processed.
(L) [2012/05/15] [ost
by TheSFReader] [Re: Improving Data Locality for Efficient In-Core Path Traci] Wayback!>> jbikker wrote:It's just a matter of adding the full queue not only to the list of full queues, but also to a list for the node, as you proposed. Perhaps it's even worthwhile to process the partial list for the node as well when the full lists are processed.
More or less, but with a small subtlety : When you get a full queue from the "list", you need to go and get the first of queues from that node, which may, or may not be the one you've popped ...
One remark, regarding 3.3, is that in algorithm 1 is quite unclear about what neighbor ← link.getneighbor() . From the description, getneighbor should use the ray as parameter to recurse and find the actual leaf that goes to neighbor.
Which leads to an additional question :
- would also queuing in non-leaf octree nodes be too memory intensive or create too much work ?