| 00:22.45 | *** join/#brlcad infobot (~infobot@rikers.org) |
| 00:22.45 | *** 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. ;) |
| 00:37.04 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 01:57.44 | *** join/#brlcad gabbar1947 (uid205515@gateway/web/irccloud.com/x-onbflyporlxwrqjb) |
| 03:14.01 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 06:23.01 | Notify | 03BRL-CAD:Amritpal singh * 10078 /wiki/User:Amritpal_singh/GSoC17/logs: /* Coding Period */ |
| 06:23.45 | Notify | 03BRL-CAD:Amritpal singh * 10079 /wiki/User:Amritpal_singh/GSoC17/logs: /* Coding Period */ |
| 07:50.42 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 08:27.03 | *** join/#brlcad Caterpillar (~caterpill@unaffiliated/caterpillar) |
| 08:29.46 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 08:32.31 | *** join/#brlcad merzo (~merzo@user-94-45-58-139.skif.com.ua) |
| 08:54.48 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 09:09.19 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 09:39.22 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 09:52.23 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 10:07.24 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 10:36.12 | *** join/#brlcad KimK (~Kim__@2600:8803:7a81:7400:1455:b829:407:67b6) |
| 10:44.27 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 11:31.30 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 13:13.40 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 13:25.58 | *** join/#brlcad yorik (~yorik@2804:431:f720:f6ac:290:f5ff:fedc:3bb2) |
| 15:27.35 | *** join/#brlcad vasc (~vasc@bl5-168-126.dsl.telepac.pt) |
| 15:27.40 | vasc | hey mdtwenty[m] |
| 15:29.14 | mdtwenty[m] | hello |
| 15:32.52 | vasc | so wassup? |
| 15:34.15 | vasc | you were looking at rt_boolfinal i think. |
| 15:35.51 | mdtwenty[m] | i have been working on rt_boolfinal. At this moment i have created the 'regiontable', which contains the information about the regions involved in each partition |
| 15:36.33 | mdtwenty[m] | and i evaluate the partitions against all the regions involved |
| 15:37.20 | vasc | yes that is a good approach. once you figure out the data and the dataflow you've understood most of the problem. |
| 15:37.43 | mdtwenty[m] | i still cant reproduce the same image for the operators.g scene, but that could be because of not resolving overlaping partitions yet |
| 15:40.29 | vasc | well, once you have something you can test that you know should work, if have issues i can proofread it,. |
| 15:41.18 | vasc | and do a code review. |
| 15:41.46 | vasc | in fact, show me the new stuff you've written so i can have a look at it |
| 15:43.16 | vasc | if you think it's too early we can do this later. |
| 15:44.32 | mdtwenty[m] | sure, give me a second to get the diff file |
| 15:47.40 | *** join/#brlcad gabbar1947 (uid205515@gateway/web/irccloud.com/x-wdvzlshlcetllnbk) |
| 15:54.37 | mdtwenty[m] | posted a file: rt_boolfinal_regiontable.patch (89KB) <https://matrix.org/_matrix/media/v1/download/matrix.org/XWxfMEAVtuCheaqtgUFjtBVw> |
| 15:55.16 | mdtwenty[m] | this doens't contains much yet.. apart from sending the regions to the kernel, and building the regiontable |
| 15:55.36 | mdtwenty[m] | i also already started working on using shade_segs to shade the resulting partitions |
| 15:56.06 | mdtwenty[m] | so you won't find the white shading code on the 'eval_partitions' kernel |
| 15:57.41 | mdtwenty[m] | i'm using a private bitvector of 32 bits to represent the regiontable, but i plan to implement a dynamic bitvector once i have a working algorithm |
| 15:59.29 | vasc | well i got a couple of things i can say just from looking at the datastructure.... |
| 16:00.35 | vasc | i'm not sure if the results of the evaluation of the partitions should be stored in that datastructure, or a separate data structure. |
| 16:00.57 | vasc | and having pointers inside structs in opencl, like cl_bool_region does can be problematic. |
| 16:01.09 | vasc | coz you see the memory map of the gpu and the cpu aren't the same. |
| 16:01.45 | vasc | so the gpu may not be able to access data you allocated on the cpu. that's why you need to copy data around to opencl in the first place. |
| 16:03.54 | mdtwenty[m] | noted, i will have a look at that |
| 16:05.01 | vasc | there also might be struct alignment issues. |
| 16:05.45 | vasc | make sure to put elements in the struct by order of size. |
| 16:05.51 | vasc | biggest first. |
| 16:06.08 | vasc | e.x. first doubles, then ints, then shorts, etc. |
| 16:06.27 | Stragus | Struct alignment stuff should be quite identical for CPU and GPU codes |
| 16:06.37 | vasc | don't be on it. |
| 16:06.40 | vasc | i had problems. |
| 16:06.50 | vasc | the code crashed until i reordered things around. |
| 16:07.01 | Stragus | Are you sure that was the issue? |
| 16:07.02 | vasc | don't bet on it. |
| 16:07.09 | vasc | well, it stopped crashing. |
| 16:07.18 | Stragus | Yes well... :) |
| 16:07.38 | Stragus | That would be a very surprising compiler bug |
| 16:08.14 | Stragus | I know sizeof(size_t) was wrong in CUDA 3.x (many years ago) only on OSX 64 bits. That was fun to debug without access to an OSX machine |
| 16:08.17 | vasc | https://community.amd.com/thread/146853 |
| 16:08.19 | gcibot | [ OpenCL alignment | Community ] |
| 16:08.22 | vasc | more people with vcrashing issues. |
| 16:08.51 | vasc | i think i had problems with cl_double4s |
| 16:10.06 | vasc | https://stackoverflow.com/questions/17361274/how-to-set-the-right-alignment-for-an-opencl-array-of-structs |
| 16:10.06 | gcibot | [ gpu programming - How to set the right alignment for an OpenCL array of structs? - Stack Overflow ] |
| 16:10.37 | vasc | and cl_double3s |
| 16:10.55 | Stragus | Geez, why can't the C and OpenCL codes use the same darn struct |
| 16:11.26 | Stragus | Well, that's terrible. I'm glad it has never been a concern with CUDA |
| 16:12.59 | vasc | don't assume because something works some way in CUDA it works the same in OpenCL or vice-versa. |
| 16:13.14 | vasc | they're quite similar but sometimes they're not. |
| 16:16.51 | mdtwenty[m] | other thing that i noted is that the boolean tree in the rpn notation doesn't seem to differentiate reverse difference operations |
| 16:17.13 | mdtwenty[m] | i.e: A-B and B-A produce the same tree |
| 16:23.24 | *** join/#brlcad HoloIRCUser3 (~holoirc@122.162.252.32) |
| 16:25.08 | vasc | hm |
| 16:25.33 | vasc | that shouldn't happen though |
| 16:25.33 | vasc | the tree is followed in a specific order. |
| 16:26.01 | *** join/#brlcad sagarwal (~holoirc@122.162.252.32) |
| 16:26.02 | vasc | so it should be like |
| 16:26.13 | vasc | A B - |
| 16:26.13 | vasc | vs |
| 16:26.16 | vasc | B A - |
| 16:27.38 | mdtwenty[m] | yes, i did some testing, by printing the normal tree, and the scene with reverse difference operation prints that |
| 16:28.24 | mdtwenty[m] | but when printing the rpn tree i get A B - and A B - |
| 16:28.34 | vasc | hm |
| 16:28.45 | vasc | give me an example file that shows this |
| 16:28.58 | vasc | i'll have to check that out later |
| 16:29.23 | mdtwenty[m] | the scene operators.g contains it |
| 16:30.31 | vasc | well it would be better with a simpler example.. |
| 16:30.36 | mdtwenty[m] | you can browse throught the geometry to draw only the region with that example |
| 16:30.38 | vasc | if you can get one |
| 16:41.13 | mdtwenty[m] | posted a file: reverse.g (0KB) <https://matrix.org/_matrix/media/v1/download/matrix.org/uwWDpxvyQwVbKjAdqRmLLILp> |
| 16:41.14 | mdtwenty[m] | here it is |
| 16:43.46 | vasc | ok god it |
| 16:43.47 | vasc | got |
| 16:44.01 | vasc | i'll look at it later as i would need to reboot. |
| 16:44.21 | vasc | meanwhile just try to get the same output as the ANSI C side. |
| 16:44.33 | vasc | since that also uses the RPN tree with the patch. |
| 16:45.19 | mdtwenty[m] | no worries, i just wanted to notify you about it |
| 16:45.42 | vasc | no, it's good. i want to fix any bugs the code might have. |
| 16:46.02 | vasc | i don't know if we'll use the RPN tree in the long run though. it's space and code efficient but it might not be computationally efficient. |
| 16:46.09 | vasc | need to perform tests on that. |
| 16:49.36 | vasc | but that's a long term concern. |
| 16:53.39 | mdtwenty[m] | okay, i will keep working on rt_boolfinal (resolving overlaping partitions) to see if i can get the operators.g scene to render correctly |
| 17:12.24 | vasc | i guess i need to read some compile papers. |
| 17:12.29 | vasc | compiler |
| 17:31.57 | *** join/#brlcad d_rossberg (~rossberg@104.225.5.10) |
| 18:09.17 | Notify | 03BRL-CAD:d_rossberg * 69941 (brlcad/trunk/include/bu/magic.h brlcad/trunk/include/rt/primitives/annot.h and 8 others): iterative patch from #469 (https://sourceforge.net/p/brlcad/patches/469/): latest annot_updated.patch from 2017-07-04, from Shubham Rathore "annot.c"...will be continued... |
| 18:09.18 | gcibot | [ A 404 Error has Occurred ] |
| 18:11.38 | d_rossberg | gabbar1947: any progress with the segmentation fault? |
| 18:13.44 | gabbar1947 | https://paste.ee/p/i9lLv |
| 18:13.44 | gcibot | [ Paste.ee - View paste i9lLv ] |
| 18:13.56 | gabbar1947 | This is the code for the func |
| 18:17.20 | d_rossberg | the first thing i see is that you allocate only one vertex |
| 18:18.47 | d_rossberg | ...ok, it's for the text, not a line |
| 18:19.02 | gabbar1947 | That was only for testing the function, once this works it can be extended to many vertices |
| 18:24.33 | gabbar1947 | regarding the extension of the vlist, the line functionalities already exist, right? all we need to add is support for the text. So what does BN_VLIST_DISPLAY_LINE_MOVE, BN_VLIST_DISPLAY_LINE_DRAW exactly signify ? Or is it the mandatory placement in plane of the screen that differentiates LINE and DISPLAY_LINE ? |
| 18:29.42 | d_rossberg | the segmentation violation is in rt_annot_export5() (src/librt/primitives/annot/annot.c:1217) - does this help? |
| 18:31.11 | gabbar1947 | I had a doubt regarding the export5(), so I checked it previously ! I'll go through it again. This really helps ! |
| 18:31.51 | d_rossberg | maybe ant.reverse should be set to a good value too? |
| 18:32.49 | gabbar1947 | https://www.irccloud.com/pastebin/f93ECx2O/ |
| 18:32.49 | gcibot | [ Snippet | IRCCloud ] |
| 18:33.33 | gabbar1947 | I don't think not inititalizing ant.reverse will cause this error |
| 18:34.15 | d_rossberg | the line where it crashes is: *(uint32_t *)cp = htonl(annot_ip->ant.reverse[seg_no]); |
| 18:34.30 | d_rossberg | (line 1217 ;) |
| 18:34.55 | gabbar1947 | Oh ! I see |
| 18:35.20 | d_rossberg | btw, do you know how to use gdb (the gnu debugger)? |
| 18:35.42 | gabbar1947 | Yes I've used gdb and ddd |
| 18:35.53 | gabbar1947 | previously |
| 18:36.10 | gabbar1947 | setting reverse will remove the error ..I think |
| 18:36.11 | d_rossberg | this was the line gdb showed to me |
| 18:39.54 | gabbar1947 | I'll build it again using the cmake DEBUG flag to make sure I don't encounter these kind of errors |
| 18:42.09 | gabbar1947 | regarding the previous question ..... LINE and DRAW_LINE.. what are your views ? |
| 18:44.42 | d_rossberg | BN_VLIST_DISPLAY_LINE_~ means that the coordinate it contains are screen coordinates, not 3d world coordinates |
| 18:45.36 | d_rossberg | i.e. it has to use a different transformation matrix then for the BN_VLIST_LINE_~ |
| 18:46.10 | gabbar1947 | Get it.... then there will be a lot to change in the handling of dm's |
| 18:46.30 | d_rossberg | ... some |
| 18:46.56 | gabbar1947 | on it ! |
| 18:47.05 | d_rossberg | but you have to touch all of them |
| 18:47.33 | gabbar1947 | Will surely do ! |
| 18:48.29 | d_rossberg | one you managed to retrieve the pixels-per-inch it should be easy |
| 18:50.47 | gabbar1947 | for that I think I'll have to touch the model,view,projection matrices.. |
| 18:52.20 | d_rossberg | don't think so, you can very much draw directly to the screen |
| 18:53.15 | d_rossberg | there is already a matrix wich transformes the reference point to pixels |
| 18:53.40 | d_rossberg | then you have to draw some lines based to this pixel |
| 19:02.49 | gabbar1947 | x-y plane can be chosen as the default plane for the lines, and then those coordinates can be mapped to the screen using the matrix mentioned by you |
| 19:16.02 | d_rossberg | this was my idea |
| 19:16.10 | d_rossberg | is crossing fingers |
| 19:16.36 | gabbar1947 | credits to you ! |
| 22:25.53 | *** join/#brlcad LoH (~lenox@173-18-199-103.client.mchsi.com) |
| 22:28.42 | *** join/#brlcad adtyn (18603139@gateway/web/freenode/ip.24.96.49.57) |
| 22:35.15 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |