Improving Data Locality for Efficient In-Core Path Tracing

Must read and other references.
jbikker
Posts: 169
Joined: Mon Nov 28, 2011 8:18 am
Contact:

Re: Improving Data Locality for Efficient In-Core Path Traci

Postby jbikker » Tue May 15, 2012 2:36 pm

TheSFReader wrote:Received the link. Thank you. Can we discuss it publicly, or shoud discussions remain "hidden" ?


Please, by all means, lets discuss it. :)

TheSFReader
Posts: 12
Joined: Tue Dec 06, 2011 8:18 am

Re: Improving Data Locality for Efficient In-Core Path Traci

Postby TheSFReader » Tue May 15, 2012 3:40 pm

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 ?

jbikker
Posts: 169
Joined: Mon Nov 28, 2011 8:18 am
Contact:

Re: Improving Data Locality for Efficient In-Core Path Traci

Postby jbikker » Tue May 15, 2012 5:20 pm

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.

TheSFReader
Posts: 12
Joined: Tue Dec 06, 2011 8:18 am

Re: Improving Data Locality for Efficient In-Core Path Traci

Postby TheSFReader » Tue May 15, 2012 8:18 pm

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 ?

ziu
Posts: 28
Joined: Sat Aug 17, 2013 8:46 pm

Re: Improving Data Locality for Efficient In-Core Path Traci

Postby ziu » Sun Oct 20, 2013 9:50 pm

Hello,
Please send me a copy of your paper Jacco.


Return to “Links & Papers”

Who is online

Users browsing this forum: No registered users and 1 guest