| 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.44 | vasc | hey mdtwenty[m] |
| 12:12.19 | mdtwenty[m] | Hey! |
| 12:15.36 | mdtwenty[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.08 | vasc | so why do you think those differ? |
| 12:23.18 | vasc | something about the primitive intersector? |
| 12:28.24 | mdtwenty[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.30 | vasc | one thing you could do is, like, find some pixels in a scene where that happens |
| 12:30.50 | vasc | and then compare the output segments after store_hits, with the ones in the ANSI C version |
| 12:31.01 | vasc | in those pixels |
| 12:31.53 | vasc | hm |
| 12:32.24 | vasc | are all the primitives in the file which fails, like supported? |
| 12:34.20 | vasc | otherwise 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.08 | vasc | we probably need to pass an extra array with the ANSI C primitive indices to OpenCL... |
| 12:35.44 | mdtwenty[m] | i think the primitives are all supported, because it works if I render only one region at a time |
| 12:36.21 | mdtwenty[m] | when i run the same scene 2 times |
| 12:37.17 | mdtwenty[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.37 | mdtwenty[m] | just confirmed and all the primitives in the scene are supported (the scene only contains sphere and the ehy primitive) |
| 12:42.24 | vasc | the seg_sti is supposed to be the primitive index in the primitive table |
| 12:42.32 | vasc | i think |
| 12:42.47 | vasc | so the primitives get reordered? |
| 12:44.09 | vasc | oh... right... how about the memory consumption? |
| 12:44.20 | vasc | we need to have some stats on this. |
| 12:45.11 | vasc | i 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.23 | vasc | bbl |
| 12:51.08 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 12:52.47 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 13:22.10 | vasc | . |
| 13:25.07 | Notify | 03BRL-CAD Wiki:Mariomeissner * 0 /wiki/User:Mariomeissner: |
| 13:27.08 | vasc | mdtwenty[m], got a patch for your latest version so i can take a look? |
| 13:29.54 | mdtwenty[m] | posted a file: rt_bool_final.patch (63KB) <https://matrix.org/_matrix/media/v1/download/matrix.org/PksajodYGkOgXMBdvFcoehbD> |
| 13:29.57 | mdtwenty[m] | here it is |
| 13:31.25 | Notify | 03BRL-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.44 | mdtwenty[m] | I was wondering if the reorder of primitives in the clt_prep function could cause the differences in the seg_stis |
| 13:42.11 | vasc | order is important yes |
| 13:44.13 | vasc | if (ordered_prims) { |
| 13:44.13 | vasc | <PROTECTED> |
| 13:44.13 | vasc | <PROTECTED> |
| 13:44.13 | vasc | <PROTECTED> |
| 13:44.13 | vasc | <PROTECTED> |
| 13:44.14 | vasc | <PROTECTED> |
| 13:44.15 | vasc | ordered_primitives[i] = primitives[ordered_prims[i]]; |
| 13:44.17 | vasc | <PROTECTED> |
| 13:44.19 | vasc | <PROTECTED> |
| 13:44.21 | vasc | <PROTECTED> |
| 13:44.23 | vasc | <PROTECTED> |
| 13:44.25 | vasc | } |
| 13:44.27 | vasc | this must be wrong |
| 13:44.29 | vasc | <vasc> ordered_primitives[i] = primitives[ordered_prims[i]]; |
| 13:44.32 | vasc | should probably be |
| 13:45.14 | vasc | ordered_prims isn't initialized anywhere it's read! |
| 13:45.15 | vasc | bah |
| 13:45.26 | vasc | well |
| 13:45.34 | vasc | because it's a calloc, its all 0s |
| 13:45.38 | vasc | it still makes no sense |
| 13:46.04 | vasc | oh |
| 13:46.12 | vasc | its ordered_prims not ordered_primitives |
| 13:46.15 | vasc | nice names... |
| 13:46.54 | vasc | forgot about that. the bvh construction algorithm reorders the primitives list. |
| 13:50.17 | vasc | i suppose the code is ok |
| 13:50.54 | vasc | BUT |
| 13:50.54 | vasc | the thing is... |
| 13:50.54 | vasc | if we reorder this, then we need to store the new order someplace |
| 13:50.57 | vasc | because the regions need to be in proper order |
| 13:51.54 | vasc | the bvh algorithm reorder the primitives so they become ordered in spatial order and thus accesses become more memory coherent |
| 13:53.10 | mdtwenty[m] | hmm |
| 13:53.44 | mdtwenty[m] | maybe we could reorder the regions accordingly somehow? |
| 13:54.31 | vasc | yes we need to i guess. |
| 13:55.20 | vasc | the order is in that ordered_prims[] array in prep.c |
| 13:55.30 | vasc | it says the new order. |
| 13:58.45 | vasc | we need to move the OpenCL regions prep code from primitive_util.c to prep.c |
| 13:59.53 | vasc | hm |
| 14:00.28 | vasc | if that code was wrong the material colors should be wrong as well no? |
| 14:00.39 | vasc | are they? |
| 14:01.18 | vasc | i think operators.g uses different colors for the different primitives |
| 14:01.40 | mdtwenty[m] | checking |
| 14:02.34 | vasc | so perhaps the seg_ids aren't "wrong" it's just that the same primitives have a different id because of the reorder. |
| 14:02.44 | vasc | unless you actually need the id to be the same for some reason... |
| 14:05.29 | mdtwenty[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.23 | mdtwenty[m] | and yes, the material colors are also incorrect |
| 14:07.24 | vasc | hm |
| 14:09.10 | vasc | well it needs to be checked. |
| 14:10.25 | vasc | there's an easy way to test i think |
| 14:10.55 | vasc | like, run clt_prep regardless if we render with OpenCL or ANSI C |
| 14:11.04 | vasc | that should reorder the primitives |
| 14:11.12 | vasc | for both codes |
| 14:11.26 | *** join/#brlcad Caterpillar (~caterpill@unaffiliated/caterpillar) | |
| 14:11.52 | vasc | and the ids should then be the samne |
| 14:11.53 | vasc | same |
| 14:15.17 | vasc | clt_prep is called in src/rt/do.c |
| 14:19.14 | vasc | just 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.35 | vasc | that way the ids should be the same on both ANSI C and OpenCL so we can test |
| 14:19.39 | vasc | if that's the problem |
| 14:21.50 | mdtwenty[m] | hm it produces the same results |
| 14:22.13 | mdtwenty[m] | shouldn't also remove the if (opencl_mode) condition? or it is always true? |
| 14:22.35 | vasc | yeah remove that too |
| 14:23.18 | vasc | so the prep always runs |
| 14:26.10 | mdtwenty[m] | hm i get an error ("failed to create OpenCL boolean regions buffer") |
| 14:26.18 | vasc | ... |
| 14:26.50 | vasc | it's because of the clt_db_store... bah |
| 14:27.47 | vasc | still why... |
| 14:28.14 | vasc | oh right doh |
| 14:28.20 | vasc | OpenCL isn't initialized. |
| 14:28.30 | vasc | so of course the operations fail. |
| 14:28.46 | vasc | initialize opencl |
| 14:30.14 | vasc | rt/main.c |
| 14:30.50 | vasc | uncomment those #ifdef USE_OPENCL and the if() and the close in rt/main.c just like you did in do.c |
| 14:31.02 | vasc | so clt_init() is always executed |
| 14:31.10 | vasc | i hope that's enough... |
| 14:32.23 | vasc | and that there isn't any voodoo left. |
| 14:33.54 | *** join/#brlcad yorik (~yorik@2804:431:f720:f6ac:290:f5ff:fedc:3bb2) | |
| 14:34.35 | mdtwenty[m] | ok it worked and the resulting image is fine |
| 14:35.24 | vasc | great. now the question is are the ids the same or not. |
| 14:35.32 | vasc | in both opencl and ansi c |
| 14:36.12 | vasc | the seg_ids |
| 14:38.05 | mdtwenty[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.23 | vasc | oh ok. but are the seg_ids the same now or not? |
| 14:39.24 | vasc | you said they weren't in the blog right? |
| 14:40.16 | mdtwenty[m] | they are still different |
| 14:40.25 | vasc | hm |
| 14:40.31 | vasc | that's strange |
| 14:40.37 | vasc | both should be reordered now... |
| 14:40.50 | vasc | oh right |
| 14:40.55 | vasc | THE SOLIDS ARRAY |
| 14:40.55 | vasc | bah |
| 14:42.13 | vasc | its never gonna work this way |
| 14:42.37 | vasc | time to cludge it i guess |
| 14:43.08 | vasc | we reorder the rtip->rti_Solids |
| 14:43.14 | vasc | >:-) |
| 14:43.35 | vasc | in clt_prep |
| 14:43.45 | vasc | <PROTECTED> |
| 14:43.45 | vasc | ordered_primitives[i] = primitives[ordered_prims[i]]; |
| 14:43.45 | vasc | <PROTECTED> |
| 14:43.51 | vasc | add this inside the loop above: |
| 14:44.23 | vasc | uh... |
| 14:44.32 | vasc | right |
| 14:45.07 | vasc | <PROTECTED> |
| 14:45.23 | vasc | it should work in that operators.g scene anyway. |
| 14:45.40 | vasc | but it's a really evil kludge... |
| 14:46.03 | vasc | that should reorder the ANSI C solids list to be the same order |
| 14:46.20 | vasc | clt_prep is in prep.c |
| 14:47.33 | vasc | now the question is... |
| 14:47.34 | vasc | uh |
| 14:47.45 | vasc | are the regions created before the init or not... |
| 14:47.46 | vasc | well |
| 14:48.05 | vasc | maybe its better just to keep the ordered_prims[] array around and translate the ids so we can check... |
| 14:48.41 | vasc | instead of doing all this crap |
| 14:49.08 | vasc | thing is we need a reverse translation |
| 14:51.38 | mdtwenty[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.15 | vasc | thing is, how is the boolean tree built |
| 14:52.20 | vasc | and are those ids wrong or not |
| 14:58.02 | vasc | they probably are |
| 14:58.24 | vasc | so hmm |
| 14:59.29 | vasc | like i said |
| 14:59.47 | vasc | we need to build the regions inside clt_prep, instead of in primitive_util.c |
| 14:59.57 | vasc | coz clt_prep knows the order |
| 15:00.46 | vasc | wait |
| 15:00.51 | vasc | the order is stored in ids[] too |
| 15:02.09 | vasc | riight |
| 15:02.14 | vasc | so we use that to do the translation |
| 15:03.13 | vasc | ah, but this one is the inverse mapping |
| 15:04.05 | vasc | we wanna know the new id with the old id in hand |
| 15:04.43 | vasc | well it might work |
| 15:05.42 | vasc | nope |
| 15:06.05 | vasc | not without a search |
| 15:06.12 | vasc | anyway |
| 15:06.32 | vasc | make sure you convert the ids in the tree to the new order before you send them to the opencl side |
| 15:08.50 | vasc | when it's an UOP for a solid, .st_bit is supposed to be the solid id |
| 15:08.52 | vasc | but because of the bvh its out of order |
| 15:08.55 | vasc | so that's your problem |
| 15:09.09 | vasc | the rtree can't be send to the opencl side without reordering it |
| 15:09.19 | vasc | the bits in st_bit |
| 15:10.30 | vasc | but you need either the inverse mapping for that, or when you do a new rtree construction algorithm specific for the opencl side. |
| 15:11.30 | mdtwenty[m] | i will do that |
| 15:12.22 | vasc | this is a bit of a nuisance. |
| 15:13.48 | vasc | the easiest way is to check where that solid id is in the solids array, but that requires a search |
| 15:14.23 | vasc | that's O(n^2) with the easiest algorithm, which kinda sucks. |
| 15:14.47 | Stragus | hugs and cuddles hash tables |
| 15:15.17 | vasc | nah, there's an easier way i think |
| 15:15.38 | vasc | like before you reorder the solids array, you store the next position for each element |
| 15:15.45 | vasc | the new position |
| 15:15.49 | vasc | that's like O(n) |
| 15:16.01 | vasc | and the lookup is O(1) |
| 15:16.14 | Stragus | Eh, all right. I wasn't quite following the context or problem |
| 15:17.06 | vasc | mdtwenty[m], make sure you revert those changes to rt/do.c and rt/main.c etc |
| 15:17.36 | vasc | sorry about that |
| 15:22.07 | vasc | like you do a loop where map[ordered_prims[i]] = i; |
| 15:22.20 | vasc | that generates the inverse mapping in linear time |
| 15:22.54 | vasc | like, if we ordered_prims is 2,1,0 |
| 15:23.24 | vasc | hm |
| 15:24.33 | vasc | no 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.35 | gcibot | [ [1707.00934] Ground-to-satellite quantum teleportation ] |
| 17:51.35 | gcibot | [ First Object Teleported from Earth to Orbit - MIT Technology Review ] |
| 17:52.25 | Stragus | Well, that will render all the space elevators obsolete |
| 18:17.30 | ``Erik | entanglement, not star trek |
| 18:18.42 | ``Erik | 4ll ur ph0t0nz r bel0ng to .. |
| 18:33.58 | Notify | 03BRL-CAD:Amritpal singh * 0 /wiki/File:Rebardistribution.jpg: |
| 18:38.40 | Notify | 03BRL-CAD:Amritpal singh * 0 /wiki/File:Rebardistribution2.png: |
| 18:45.28 | Notify | 03BRL-CAD:Amritpal singh * 10094 /wiki/User:Amritpal_singh/GSoC17/logs: /* Coding Period */ |
| 18:48.19 | Notify | 03BRL-CAD:Amritpal singh * 10095 /wiki/User:Amritpal_singh/GSoC17/logs: /* Coding Period */ |
| 18:57.53 | vasc | right. the chinese quantum whatever. |
| 18:58.10 | vasc | but i think its only good for data. |
| 18:59.05 | vasc | they also claimed to have quantum radar some months ago. |
| 18:59.05 | vasc | whatever that's supposed to be. |
| 19:06.34 | vasc | the problem with the map loop that i said before is that sometimes primitives are removed from the solids list |
| 19:06.42 | vasc | so the list has holes |
| 19:06.52 | vasc | so 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) | |