IRC log for #brlcad on 20170711

00:05.25*** join/#brlcad brbjnpflanjvadkv (~armin@dslb-088-066-157-191.088.066.pools.vodafone-ip.de)
00:26.14*** join/#brlcad infobot (~infobot@rikers.org)
00:26.14*** topic/#brlcad is GSoC students: if you have a question, ask and wait for an answer ... responses may take minutes or hours. Ask and WAIT. ;)
01:07.27*** join/#brlcad kintel (~kintel@unaffiliated/kintel)
02:13.09*** join/#brlcad gabbar1947 (uid205515@gateway/web/irccloud.com/x-tyvtxashbcdzccie)
06:32.53*** join/#brlcad teepee (~teepee@unaffiliated/teepee)
06:46.24*** join/#brlcad teepee (~teepee@unaffiliated/teepee)
07:06.55*** join/#brlcad teepee (~teepee@unaffiliated/teepee)
07:51.58*** join/#brlcad teepee (~teepee@unaffiliated/teepee)
08:10.29*** join/#brlcad teepee (~teepee@unaffiliated/teepee)
08:41.01*** join/#brlcad teepee (~teepee@unaffiliated/teepee)
09:40.45*** join/#brlcad Caterpillar (~caterpill@unaffiliated/caterpillar)
09:47.37*** join/#brlcad teepee (~teepee@unaffiliated/teepee)
09:53.44*** join/#brlcad KimK (~Kim__@2600:8803:7a81:7400:dc96:dfbf:629e:2e65)
10:00.07*** join/#brlcad teepee (~teepee@unaffiliated/teepee)
10:34.10*** join/#brlcad teepee (~teepee@unaffiliated/teepee)
10:54.44*** join/#brlcad merzo (~merzo@220-58-133-95.pool.ukrtel.net)
11:03.12*** join/#brlcad teepee (~teepee@unaffiliated/teepee)
11:47.46*** join/#brlcad teepee (~teepee@unaffiliated/teepee)
12:08.47*** join/#brlcad teepee (~teepee@unaffiliated/teepee)
12:11.34*** join/#brlcad vasc (~vasc@bl4-145-226.dsl.telepac.pt)
12:11.44vaschey mdtwenty[m]
12:12.19mdtwenty[m]Hey!
12:15.36mdtwenty[m]About my last post on the dev log, i think that maybe there is an issue with the 'seg_sti' values of segments
12:22.08vascso why do you think those differ?
12:23.18vascsomething about the primitive intersector?
12:28.24mdtwenty[m]it would be my guess, since the partitions seemed to have the right segments, because the segments have the same inhit.hit_dist and outhit.hit_dist
12:30.30vascone thing you could do is, like, find some pixels in a scene where that happens
12:30.50vascand then compare the output segments after store_hits, with the ones in the ANSI C version
12:31.01vascin those pixels
12:31.53vaschm
12:32.24vascare all the primitives in the file which fails, like supported?
12:34.20vascotherwise i wouldn't be surprised if there was a mismatch between primitive offsets in the OpenCL primitives array, and indices in the ANSI C code.
12:35.08vascwe probably need to pass an extra array with the ANSI C primitive indices to OpenCL...
12:35.44mdtwenty[m]i think the primitives are all supported, because it works if I render only one region at a time
12:36.21mdtwenty[m]when i run the same scene 2 times
12:37.17mdtwenty[m]the order of the regions changes, and the seg_sti of segments in the ansi c code follow those changes, but the seg_sti of segments in opencl seems to be fixed
12:39.37mdtwenty[m]just confirmed and all the primitives in the scene are supported (the scene only contains sphere and the ehy primitive)
12:42.24vascthe seg_sti is supposed to be the primitive index in the primitive table
12:42.32vasci think
12:42.47vascso the primitives get reordered?
12:44.09vascoh... right... how about the memory consumption?
12:44.20vascwe need to have some stats on this.
12:45.11vasci don't know if there is a standard way to do this using the BRL-CAD API or if we need to roll our own mem stats code
12:45.23vascbbl
12:51.08*** join/#brlcad kintel (~kintel@unaffiliated/kintel)
12:52.47*** join/#brlcad kintel (~kintel@unaffiliated/kintel)
13:22.10vasc.
13:25.07Notify03BRL-CAD Wiki:Mariomeissner * 0 /wiki/User:Mariomeissner:
13:27.08vascmdtwenty[m], got a patch for your latest version so i can take a look?
13:29.54mdtwenty[m]posted a file: rt_bool_final.patch (63KB) <https://matrix.org/_matrix/media/v1/download/matrix.org/PksajodYGkOgXMBdvFcoehbD>
13:29.57mdtwenty[m]here it is
13:31.25Notify03BRL-CAD Wiki:Mariomeissner * 10091 /wiki/User:Mariomeissner/logs: Created page with "Mario Meissner SOCIS 2017 Logs 20-6 Build successfull on Arch Linux (Antergos) x64 Working my way through the Introduction_to_MGED.pdf 21-6 Successfully calculated mass of a..."
13:32.44mdtwenty[m]I was wondering if the reorder of primitives in the clt_prep function could cause the differences in the seg_stis
13:42.11vascorder is important yes
13:44.13vascif (ordered_prims) {
13:44.13vasc<PROTECTED>
13:44.13vasc<PROTECTED>
13:44.13vasc<PROTECTED>
13:44.13vasc<PROTECTED>
13:44.14vasc<PROTECTED>
13:44.15vascordered_primitives[i] = primitives[ordered_prims[i]];
13:44.17vasc<PROTECTED>
13:44.19vasc<PROTECTED>
13:44.21vasc<PROTECTED>
13:44.23vasc<PROTECTED>
13:44.25vasc}
13:44.27vascthis must be wrong
13:44.29vasc<vasc>   ordered_primitives[i] = primitives[ordered_prims[i]];
13:44.32vascshould probably be
13:45.14vascordered_prims isn't initialized anywhere it's read!
13:45.15vascbah
13:45.26vascwell
13:45.34vascbecause it's a calloc, its all 0s
13:45.38vascit still makes no sense
13:46.04vascoh
13:46.12vascits ordered_prims not ordered_primitives
13:46.15vascnice names...
13:46.54vascforgot about that. the bvh construction algorithm reorders the primitives list.
13:50.17vasci suppose the code is ok
13:50.54vascBUT
13:50.54vascthe thing is...
13:50.54vascif we reorder this, then we need to store the new order someplace
13:50.57vascbecause the regions need to be in proper order
13:51.54vascthe bvh algorithm reorder the primitives so they become ordered in spatial order and thus accesses become more memory coherent
13:53.10mdtwenty[m]hmm
13:53.44mdtwenty[m]maybe we could reorder the regions accordingly somehow?
13:54.31vascyes we need to i guess.
13:55.20vascthe order is in that ordered_prims[] array in prep.c
13:55.30vascit says the new order.
13:58.45vascwe need to move the OpenCL regions prep code from primitive_util.c to prep.c
13:59.53vaschm
14:00.28vascif that code was wrong the material colors should be wrong as well no?
14:00.39vascare they?
14:01.18vasci think operators.g uses different colors for the different primitives
14:01.40mdtwenty[m]checking
14:02.34vascso perhaps the seg_ids aren't "wrong" it's just that the same primitives have a different id because of the reorder.
14:02.44vascunless you actually need the id to be the same for some reason...
14:05.29mdtwenty[m]i don't think the id needs to be the same, it only has to match with the ids in the boolean trees
14:07.23mdtwenty[m]and yes, the material colors are also incorrect
14:07.24vaschm
14:09.10vascwell it needs to be checked.
14:10.25vascthere's an easy way to test i think
14:10.55vasclike, run clt_prep regardless if we render with OpenCL or ANSI C
14:11.04vascthat should reorder the primitives
14:11.12vascfor both codes
14:11.26*** join/#brlcad Caterpillar (~caterpill@unaffiliated/caterpillar)
14:11.52vascand the ids should then be the samne
14:11.53vascsame
14:15.17vascclt_prep is called in src/rt/do.c
14:19.14vascjust remove the #ifdef USE_OPENCL and #endif on do_prep() in src/rt/do.c to make it always build the bvh and reorder regardless if its in opencl render mode or not.
14:19.35vascthat way the ids should be the same on both ANSI C and OpenCL so we can test
14:19.39vascif that's the problem
14:21.50mdtwenty[m]hm it produces the same results
14:22.13mdtwenty[m]shouldn't also remove the if (opencl_mode) condition? or it is always true?
14:22.35vascyeah remove that too
14:23.18vascso the prep always runs
14:26.10mdtwenty[m]hm i get an error ("failed to create OpenCL boolean regions buffer")
14:26.18vasc...
14:26.50vascit's because of the clt_db_store... bah
14:27.47vascstill why...
14:28.14vascoh right doh
14:28.20vascOpenCL isn't initialized.
14:28.30vascso of course the operations fail.
14:28.46vascinitialize opencl
14:30.14vascrt/main.c
14:30.50vascuncomment those #ifdef USE_OPENCL and the if() and the close in rt/main.c just like you did in do.c
14:31.02vascso clt_init() is always executed
14:31.10vasci hope that's enough...
14:32.23vascand that there isn't any voodoo left.
14:33.54*** join/#brlcad yorik (~yorik@2804:431:f720:f6ac:290:f5ff:fedc:3bb2)
14:34.35mdtwenty[m]ok it worked and the resulting image is fine
14:35.24vascgreat. now the question is are the ids the same or not.
14:35.32vascin both opencl and ansi c
14:36.12vascthe seg_ids
14:38.05mdtwenty[m](when i said the resulting image is fine i meant the image produced by the ansi c, the opencl resulting image is not)
14:38.23vascoh ok. but are the seg_ids the same now or not?
14:39.24vascyou said they weren't in the blog right?
14:40.16mdtwenty[m]they are still different
14:40.25vaschm
14:40.31vascthat's strange
14:40.37vascboth should be reordered now...
14:40.50vascoh right
14:40.55vascTHE SOLIDS ARRAY
14:40.55vascbah
14:42.13vascits never gonna work this way
14:42.37vasctime to cludge it i guess
14:43.08vascwe reorder the  rtip->rti_Solids
14:43.14vasc>:-)
14:43.35vascin clt_prep
14:43.45vasc<PROTECTED>
14:43.45vascordered_primitives[i] = primitives[ordered_prims[i]];
14:43.45vasc<PROTECTED>
14:43.51vascadd this inside the loop above:
14:44.23vascuh...
14:44.32vascright
14:45.07vasc<PROTECTED>
14:45.23vascit should work in that operators.g scene anyway.
14:45.40vascbut it's a really evil kludge...
14:46.03vascthat should reorder the ANSI C solids list to be the same order
14:46.20vascclt_prep is in prep.c
14:47.33vascnow the question is...
14:47.34vascuh
14:47.45vascare the regions created before the init or not...
14:47.46vascwell
14:48.05vascmaybe its better just to keep the ordered_prims[] array around and translate the ids so we can check...
14:48.41vascinstead of doing all this crap
14:49.08vascthing is we need a reverse translation
14:51.38mdtwenty[m]hm, so if we know that the primitive with id 1 when ordered will get the id 4 for example, couln't we go on the boolean tree and update the 1's for 4's and so on?
14:52.15vascthing is, how is the boolean tree built
14:52.20vascand are those ids wrong or not
14:58.02vascthey probably are
14:58.24vascso hmm
14:59.29vasclike i said
14:59.47vascwe need to build the regions inside clt_prep, instead of in primitive_util.c
14:59.57vasccoz clt_prep knows the order
15:00.46vascwait
15:00.51vascthe order is stored in ids[] too
15:02.09vascriight
15:02.14vascso we use that to do the translation
15:03.13vascah, but this one is the inverse mapping
15:04.05vascwe wanna know the new id with the old id in hand
15:04.43vascwell it might work
15:05.42vascnope
15:06.05vascnot without a search
15:06.12vascanyway
15:06.32vascmake sure you convert the ids in the tree to the new order before you send them to the opencl side
15:08.50vascwhen it's an UOP for a solid, .st_bit is supposed to be the solid id
15:08.52vascbut because of the bvh its out of order
15:08.55vascso that's your problem
15:09.09vascthe rtree can't be send to the opencl side without reordering it
15:09.19vascthe bits in st_bit
15:10.30vascbut you need either the inverse mapping for that, or when you do a new rtree construction algorithm specific for the opencl side.
15:11.30mdtwenty[m]i will do that
15:12.22vascthis is a bit of a nuisance.
15:13.48vascthe easiest way is to check where that solid id is in the solids array, but that requires a search
15:14.23vascthat's O(n^2) with the easiest algorithm, which kinda sucks.
15:14.47Stragushugs and cuddles hash tables
15:15.17vascnah, there's an easier way i think
15:15.38vasclike before you reorder the solids array, you store the next position for each element
15:15.45vascthe new position
15:15.49vascthat's like O(n)
15:16.01vascand the lookup is O(1)
15:16.14StragusEh, all right. I wasn't quite following the context or problem
15:17.06vascmdtwenty[m], make sure you revert those changes to rt/do.c and rt/main.c etc
15:17.36vascsorry about that
15:22.07vasclike you do a loop where map[ordered_prims[i]] = i;
15:22.20vascthat generates the inverse mapping in linear time
15:22.54vasclike, if we ordered_prims is 2,1,0
15:23.24vaschm
15:24.33vascno that's the same thing
15:36.01*** join/#brlcad merzo (~merzo@60-57-132-95.pool.ukrtel.net)
16:40.14*** join/#brlcad teepee (~teepee@unaffiliated/teepee)
16:43.59*** join/#brlcad infobot (~infobot@rikers.org)
16:43.59*** topic/#brlcad is GSoC students: if you have a question, ask and wait for an answer ... responses may take minutes or hours. Ask and WAIT. ;)
17:51.35``Erik:o https://arxiv.org/abs/1707.00934   ( https://www.technologyreview.com/s/608252/first-object-teleported-from-earth-to-orbit/ for layperson blurb )
17:51.35gcibot[ [1707.00934] Ground-to-satellite quantum teleportation ]
17:51.35gcibot[ First Object Teleported from Earth to Orbit - MIT Technology Review ]
17:52.25StragusWell, that will render all the space elevators obsolete
18:17.30``Erikentanglement, not star trek
18:18.42``Erik4ll ur ph0t0nz r bel0ng to ..
18:33.58Notify03BRL-CAD:Amritpal singh * 0 /wiki/File:Rebardistribution.jpg:
18:38.40Notify03BRL-CAD:Amritpal singh * 0 /wiki/File:Rebardistribution2.png:
18:45.28Notify03BRL-CAD:Amritpal singh * 10094 /wiki/User:Amritpal_singh/GSoC17/logs: /* Coding Period */
18:48.19Notify03BRL-CAD:Amritpal singh * 10095 /wiki/User:Amritpal_singh/GSoC17/logs: /* Coding Period */
18:57.53vascright. the chinese quantum whatever.
18:58.10vascbut i think its only good for data.
18:59.05vascthey also claimed to have quantum radar some months ago.
18:59.05vascwhatever that's supposed to be.
19:06.34vascthe problem with the map loop that i said before is that sometimes primitives are removed from the solids list
19:06.42vascso the list has holes
19:06.52vascso the ids might not map like that.
19:38.46*** join/#brlcad d_rossberg (~rossberg@104.225.5.10)
20:42.51*** join/#brlcad merzo (~merzo@60-57-132-95.pool.ukrtel.net)
21:09.01*** join/#brlcad teepee (~teepee@unaffiliated/teepee)
22:46.18*** join/#brlcad infobot (~infobot@rikers.org)
22:46.18*** topic/#brlcad is GSoC students: if you have a question, ask and wait for an answer ... responses may take minutes or hours. Ask and WAIT. ;)
23:07.48*** join/#brlcad kintel (~kintel@unaffiliated/kintel)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.