| 01:04.26 | *** join/#brlcad polyspin (n=polyspin@pcp0011463358pcs.chrchv01.md.comcast.net) | |
| 01:21.25 | polyspin | Anyone remember the ThinkGeek USB keys that were ultra-small? Can't find who made them. |
| 01:23.55 | Twingy | http://www.bestbuy.com/site/olspage.jsp?skuId=6729132&type=product&productCategoryId=cat01049&id=1083715897929 |
| 01:25.38 | polyspin | thx! |
| 01:48.08 | Twingy | welp, "technically" I have sse in now :) |
| 02:52.18 | *** join/#brlcad Semhirage (n=Semhirag@unaffiliated/semhirage) | |
| 04:19.39 | *** join/#brlcad mahesh (n=mahesh@12-217-225-64.client.mchsi.com) | |
| 04:25.48 | Twingy | hrm |
| 04:26.10 | Twingy | integrating sse is a turn-key headache |
| 04:37.21 | *** join/#brlcad cad728 (n=d31ac884@bz.bzflag.bz) | |
| 04:38.46 | *** join/#brlcad cad728 (n=d31ac884@bz.bzflag.bz) | |
| 05:18.34 | *** join/#brlcad Semhirage (n=Semhirag@unaffiliated/semhirage) | |
| 05:26.09 | *** join/#brlcad mahesh (n=mahesh@12-217-225-64.client.mchsi.com) | |
| 05:26.43 | silvap_ | Twingy, u there? |
| 05:27.07 | *** join/#brlcad Semhirage (n=Semhirag@unaffiliated/semhirage) | |
| 05:28.58 | silvap_ | sean? |
| 05:39.25 | brlcad | hey |
| 05:41.20 | mahesh | hi sean, I had a question regarding librt |
| 05:41.38 | brlcad | heya mahesh, good to finally catch up with you |
| 05:42.03 | mahesh | yeah, I was looking for you for a long time |
| 05:42.33 | brlcad | away at a conference |
| 05:42.51 | mahesh | yeah...also Twingy told me you were sick |
| 05:43.07 | brlcad | heh |
| 05:43.25 | brlcad | I wasn't sick, I was traveling |
| 05:43.37 | mahesh | oh ok |
| 05:44.41 | brlcad | so, what's the question? |
| 05:44.54 | mahesh | I wanted some help on partitioning the data for raytracing |
| 05:44.58 | brlcad | i saw what you wrote about going forward with librt distributed |
| 05:45.07 | mahesh | yes...you are right |
| 05:45.36 | mahesh | I was trying to understand the way it is partitioned to run on multiprocessor |
| 05:46.06 | mahesh | that is rt_prep_parallel -- > rt_cut_it --> bu_parallel. .... |
| 05:46.34 | brlcad | bu_parallel is the core parallelizer |
| 05:46.58 | brlcad | runs routines in parallel |
| 05:47.12 | brlcad | using whatever system facility is required/available |
| 05:47.37 | mahesh | so what do you suggest...how should I be doing the data partition? |
| 05:48.10 | brlcad | rt_prep_parallel initializes the per-cpu resource structures that get read/written to |
| 05:48.56 | brlcad | well, what's you end goal? |
| 05:49.22 | brlcad | to understand what it's currently doing or get it using some grid api, or using MPI or something else? |
| 05:49.53 | mahesh | I want to use grid middleware to speed up the rendering |
| 05:50.02 | mahesh | the way i am thinking is |
| 05:50.13 | mahesh | I have a model and objects in it |
| 05:50.35 | mahesh | If I could split it up and distribute it to different machines with the help of grid middleware |
| 05:50.50 | mahesh | and collect the results and merge |
| 05:51.13 | mahesh | it will speed up the process of rendering as a whole |
| 05:51.19 | brlcad | my initial thought were I doing it would be to rewrite the parallel routines for distributed ones |
| 05:51.37 | brlcad | i.e. create your own rt_prep_distributed() |
| 05:52.14 | mahesh | ok...so what would that do exactly? |
| 05:52.51 | brlcad | same for bu_parallel.. write your own bu_distributed() |
| 05:53.37 | brlcad | prep_distributed would do whatever prep you need.. splitting up the data, any shared resources, etc |
| 05:53.48 | mahesh | yes, i get it. I was only looking at bu_parallel and rt_prep_parallel to understand how the data is split |
| 05:54.16 | mahesh | I am finding it hard to understand how exactly the data is split |
| 05:55.18 | brlcad | what do you mean by splitting the data? |
| 05:55.34 | brlcad | rt doesn't "split the data" |
| 05:55.47 | brlcad | other than regular space partitioning |
| 05:55.57 | mahesh | then how does it speed up the whole process when it is run on multiple processors? |
| 05:56.06 | brlcad | and processing the data in chunks of pixels at a time |
| 05:56.17 | brlcad | ahh |
| 05:56.19 | brlcad | yeah |
| 05:56.54 | brlcad | raytrace generates the picture, which is a 2D array of independant pixels |
| 05:57.13 | brlcad | it spreads out the processing of those pixels in groups to multiple processors |
| 05:57.49 | brlcad | there are lots of means to do that, but simple methods usually involve either scanlines at a time, or postage stamp-sized images, etc |
| 05:58.26 | mahesh | ok..once the processor gets some pixels, what exactly does it do? |
| 05:58.51 | mahesh | i mean which function is called (implementation point of view)? |
| 05:58.53 | brlcad | it performs the ray-traversal on each pixel |
| 05:59.08 | brlcad | ah, the routine passed to bu_parallel |
| 05:59.20 | brlcad | which is basically rt_shootray() |
| 06:00.09 | mahesh | i have that definition right here and should I understand that part of the code? |
| 06:00.24 | mahesh | it looks just too complicated |
| 06:00.37 | brlcad | that's the guts to the ray-tracer |
| 06:00.46 | brlcad | you shouldn't have to need to understand it completely |
| 06:00.52 | brlcad | since that's what you're distributing |
| 06:01.38 | mahesh | ok...i get that...now what is the result of ray-traversal (like what output and what format)? |
| 06:01.39 | brlcad | more specifically, bu_parallel() calls worker() |
| 06:01.59 | brlcad | worker() ends up doing the work.. which is shooting rays (rt_shootray) |
| 06:02.07 | mahesh | alright |
| 06:02.53 | brlcad | so for making it distributed, you'll probably want to either modify bu_parallel() and/or modify worker(), but beyond that the logic of librt should pretty much not need to change |
| 06:04.21 | mahesh | i think I dont have to take care of those synchronization and threads and stuff because it will be run as single thread on different machines? |
| 06:05.12 | brlcad | you could not worry about it for starters |
| 06:05.23 | mahesh | ok |
| 06:05.27 | brlcad | presume each distributed node is single processor |
| 06:05.37 | mahesh | i get it |
| 06:05.39 | brlcad | ultimately, you could do both |
| 06:05.56 | brlcad | use bu_distributed and have it simply invoke a remove bu_parallel |
| 06:06.02 | brlcad | s/remove/remote/ |
| 06:06.37 | mahesh | ok |
| 06:09.06 | mahesh | so, do you say I don't even have to take care of assigning pixels to machines for ray traversal and collect it? |
| 06:09.07 | brlcad | gotta run out for a little while, but hoepfully that's something to get you started at least looking at the code |
| 06:09.33 | mahesh | yeah..sure |
| 06:09.39 | brlcad | that's what worker() does.. you probably will have to do something there |
| 06:09.47 | mahesh | fine |
| 06:09.49 | brlcad | not sure |
| 06:10.02 | mahesh | thats a lot of information for me...thank you very much |
| 06:10.18 | brlcad | no problem, talk more later |
| 06:10.27 | mahesh | sure |
| 10:17.26 | *** join/#brlcad archivist_ (n=djc@host217-35-76-52.in-addr.btopenworld.com) | |
| 19:16.25 | *** join/#brlcad archivist_ (n=archivis@host217-35-76-52.in-addr.btopenworld.com) | |