| 01:02.14 | Notify | 03BRL-CAD:starseeker * 65632 brlcad/trunk/src/libbrep/shape_recognition_cylinder.cpp: helps to get the format string right... |
| 01:02.41 | starseeker | vasc: what warnings? |
| 01:17.40 | Notify | 03BRL-CAD:starseeker * 65633 brlcad/trunk/src/librt/CMakeLists.txt: small program to characterize a brep model and determine what percentage of its objects might be csg conversion candidates. methodology is very crude... |
| 01:28.23 | Notify | 03BRL-CAD:starseeker * 65634 brlcad/trunk/src/libbrep/shape_recognition.cpp: Something not quite right here - NIST2 and NIST4 are suddenly failing because of this test... |
| 01:49.20 | Notify | 03BRL-CAD:starseeker * 65635 (brlcad/trunk/src/libtclcad/CMakeLists.txt brlcad/trunk/src/libtclcad/tclcad.c): Move the functions pushed into libtclcad from the lower level libs into their own file - need to look at renaming them, may need other reworking. |
| 01:52.14 | Notify | 03BRL-CAD:starseeker * 65636 brlcad/trunk/src/librt/tree.c: Shouldn't need string here - needs more testing. |
| 02:48.45 | Gurwinder | brlcad: Ping |
| 02:51.13 | vasc | CMake Warning (dev) at misc/CMake/TCL_PKGINDEX.cmake:45 (get_target_property): |
| 02:51.13 | vasc | <PROTECTED> |
| 02:51.13 | vasc | <PROTECTED> |
| 02:51.13 | vasc | <PROTECTED> |
| 02:51.13 | vasc | <PROTECTED> |
| 02:51.14 | vasc | <PROTECTED> |
| 02:51.16 | vasc | <PROTECTED> |
| 02:51.18 | vasc | Call Stack (most recent call first): |
| 02:51.20 | vasc | <PROTECTED> |
| 02:51.22 | vasc | This warning is for project developers. Use -Wno-dev to suppress it. |
| 02:51.24 | vasc | CMake Warning (dev) at misc/CMake/TCL_PKGINDEX.cmake:45 (get_target_property): |
| 02:51.26 | vasc | <PROTECTED> |
| 02:51.28 | vasc | <PROTECTED> |
| 02:51.30 | vasc | <PROTECTED> |
| 02:51.32 | vasc | <PROTECTED> |
| 02:51.34 | vasc | <PROTECTED> |
| 02:51.36 | vasc | <PROTECTED> |
| 02:51.38 | vasc | and more like 5 pages of that |
| 03:08.47 | starseeker | ah |
| 03:09.00 | starseeker | what version of CMake are you using? |
| 03:10.16 | starseeker | vasc: those can be safely ignored - they're a developer message letting us know we need to rework those bits of code to use a new system |
| 03:10.36 | starseeker | first we need to require CMake > 3.0, which we'll only do after the 7.26.0 release |
| 03:12.37 | vasc | cmake version 3.0.2 |
| 03:23.41 | Notify | 03BRL-CAD:starseeker * 65637 (brlcad/trunk/src/other/PoissonRecon/CMakeLists.txt brlcad/trunk/src/other/URToolkit/CMakeLists.txt and 12 others): Put policy settings back in for 3.0.2 |
| 03:23.47 | starseeker | vasc: give that a shot |
| 03:30.44 | vasc | just svn up and then i run cmake? or something else? |
| 03:31.00 | starseeker | you got it |
| 03:31.27 | vasc | i'm running cmake-gui .. -DBRLCAD_BUNDLED_LIBS=ON |
| 03:31.48 | starseeker | OK, that should work |
| 03:31.51 | vasc | same thing happened |
| 03:31.59 | vasc | mind you it does generate the makefiles |
| 03:32.03 | starseeker | try clearing the cache |
| 03:32.04 | vasc | its just it spews those warnings |
| 03:32.09 | vasc | ok, where is that? |
| 03:32.23 | starseeker | in the gui I believe it's under the file menu |
| 03:32.26 | vasc | hm |
| 03:32.50 | starseeker | yeah, those warnings aren't showstoppers |
| 03:33.44 | vasc | did file->delete cache |
| 03:34.01 | vasc | but same warnings. except now it's spending time detecting stuff in the middle of the warnings |
| 03:34.12 | starseeker | usually we try to keep up with new cmake policies, but 0026 is a challenge |
| 03:34.24 | starseeker | vasc: you've updated to 65637? |
| 03:34.48 | vasc | At revision 65637. |
| 03:34.51 | vasc | yep |
| 03:34.53 | starseeker | huh |
| 03:35.02 | starseeker | I'll have to try 3.0.2 |
| 03:35.18 | vasc | yeah it's the one i use. it came with ubuntu |
| 03:35.57 | starseeker | nods |
| 04:11.24 | Notify | 03BRL-CAD:starseeker * 65638 brlcad/trunk/CMakeLists.txt: Back up policy simplification - not working as expected |
| 04:34.17 | *** join/#brlcad ejno (~ejno@unaffiliated/kazaik) |
| 06:48.25 | Gurwinder | brlcad: Are you free now? |
| 06:55.27 | *** join/#brlcad Izakey (~Isaac@41.205.22.55) |
| 07:02.35 | Gurwinder | Izakey: Hello |
| 07:27.43 | *** join/#brlcad dracarys983 (dracarys98@nat/iiit/x-abfthvuqksrwdlmz) |
| 08:01.31 | *** join/#brlcad dracarys983 (dracarys98@nat/iiit/x-fflhynkiaimbhwgt) |
| 08:51.33 | *** join/#brlcad teepee-- (bc5c2134@gateway/web/freenode/ip.188.92.33.52) |
| 09:02.39 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 10:08.49 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 10:11.26 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 11:28.45 | *** join/#brlcad kintel_ (~kintel@unaffiliated/kintel) |
| 13:42.34 | Notify | 03BRL-CAD:starseeker * 65639 (brlcad/trunk/src/libanalyze/raydiff.c brlcad/trunk/src/libged/shape_recognition.cpp): Add a basic valid/not-valid check using raytracing for the csg conversion - need to figure out why parallel tree building isn't working in libanalyze... |
| 13:48.23 | Notify | 03BRL-CAD:starseeker * 65640 (brlcad/branches/embree/AUTHORS brlcad/branches/embree/CHANGES and 117 others): Update to r65639 |
| 13:54.28 | Notify | 03BRL-CAD:starseeker * 65641 (brlcad/branches/embree/CMakeLists.txt brlcad/branches/embree/db/CMakeLists.txt and 2 others): Add a flag to allow disabling building of STEP pieces |
| 14:03.57 | *** join/#brlcad Izakey (~Izakey@41.205.22.51) |
| 14:15.47 | *** join/#brlcad milinda (~milinda@124.43.80.119) |
| 14:25.34 | Notify | 03BRL-CAD Wiki:Sean * 9004 /wiki/Google_Summer_of_Code/2015: remove the template and student that didn't pass midterm evaluation |
| 14:27.58 | brlcad | notes that this year's gsocers are apparently the worst (generally speaking) at IRC to date... :( |
| 14:28.10 | brlcad | so many drive-by disconnects |
| 14:49.44 | Notify | 03BRL-CAD:carlmoore * 65642 brlcad/trunk/include/rt/geom.h: remove a trailing whitespace character I overlooked yesterday |
| 14:50.45 | Izakey | Hi brlcad |
| 15:00.28 | brlcad | hi Izakey |
| 15:02.25 | Izakey | Have an issue https://paste.kde.org/pab6nw3ai with building BRL-CAD, Any help ? |
| 15:03.29 | Izakey | Think someone needs to advise students on importance of IRC |
| 15:08.13 | *** join/#brlcad sofat (~androirc@223.225.216.34) |
| 15:08.24 | brlcad | sofat: hang around, we can talk in a bit :) |
| 15:08.38 | sofat | Ok |
| 15:08.55 | Izakey | waves at sofat |
| 15:15.37 | sofat | So tell me any updates for website |
| 15:32.34 | Notify | 03BRL-CAD Wiki:Deekaysharma * 9005 /wiki/User:Deekaysharma/logs: |
| 15:36.04 | Notify | 03BRL-CAD:starseeker * 65643 brlcad/trunk/src/libanalyze/raydiff.c: Need resource initialization before calling rt_gettrees. Something odd here - the original NIST2 brep takes much longer to prep with rt_gettrees than with rt_gettree alone... |
| 15:51.14 | sofat | brlcad, so we will talk now ? |
| 15:52.58 | Izakey | sofat Please use IRC more during development. Open source development is more about communication than code :) |
| 15:53.38 | sofat | Okay |
| 15:54.28 | Izakey | Code comes and goes sofat but community lives on longer |
| 15:54.42 | Izakey | hope you get it sofat |
| 15:55.31 | sofat | Yes got it |
| 15:57.41 | sofat | So what is my mistake ?? |
| 15:57.57 | sofat | I am doing anything wrong ?? |
| 15:58.28 | Notify | 03BRL-CAD:starseeker * 65644 (brlcad/trunk/src/libged/brep.c brlcad/trunk/src/libged/ged_private.h brlcad/trunk/src/libged/shape_recognition.cpp): Add a way to proceed with and without verification - should probably make this a user settable value (maybe both the multiplier and an absolute tolerance?) |
| 15:58.50 | Izakey | No sofat , Just asking you to be on and use IRC more during development :) |
| 15:59.46 | brlcad | sofat: now that you have a .bz account, you should learn how to use screen+irssi |
| 16:00.04 | brlcad | so you don't have to keep detaching from IRC |
| 16:00.11 | brlcad | it less you remain connected 24-7 |
| 16:01.26 | sofat | Ok |
| 16:01.27 | brlcad | simple tutorial: open a terminal, log in to your account, run 'screen', run 'irssi' and join freenode, then close your terminal window, then log back into .bz, and run 'screen -x yourusername' |
| 16:01.37 | Notify | 03BRL-CAD:starseeker * 65645 brlcad/trunk/src/libged/shape_recognition.cpp: Definitely need something other than an arbitrary constant multiplier here... for some objects this isn't enough, for others it's major overkill. |
| 16:02.13 | sofat | Ok |
| 16:02.20 | sofat | Thanks |
| 16:02.39 | *** join/#brlcad milinda (~milinda@112.134.125.254) |
| 16:02.50 | Izakey | <PROTECTED> |
| 16:02.51 | sofat | I will try this . |
| 16:04.19 | sofat | This is for me ? |
| 16:09.34 | sofat | Izakey, this link for me ? |
| 16:10.23 | brlcad | sofat: the link is for everyone, it's a build failure |
| 16:10.57 | brlcad | if you don't have a suggestion, then you could answer and say that -- if you do, you might be able to help |
| 16:11.05 | Izakey | Thanks brlcad |
| 16:11.46 | sofat | Ok |
| 16:13.17 | sofat | brlcad, you checked my website i have done language work so you want any changes ? |
| 16:13.47 | brlcad | sofat: yeah.. it's in the right direction |
| 16:14.12 | sofat | Ok now this part is done |
| 16:14.14 | brlcad | but few changes -- include both the name and flag |
| 16:14.23 | sofat | Ok |
| 16:14.29 | sofat | I will do |
| 16:14.42 | Izakey | What's the link to the website ? |
| 16:14.52 | brlcad | the google-drop-down you had was better, just needed flags --- that's why I sent you those links |
| 16:16.10 | sofat | Where is drop down there is only flags |
| 16:17.30 | brlcad | I know |
| 16:17.41 | brlcad | that's no good |
| 16:18.05 | brlcad | sofat: Izakey asked you a question... |
| 16:19.17 | brlcad | it looks like it's not responding right now |
| 16:19.27 | brlcad | he'll probably ping-timeout |
| 16:19.41 | sofat | There is many flags so i use show hide effect in juery |
| 16:19.52 | sofat | Jquery |
| 16:20.14 | brlcad | I know, its a huge wall of flags -- nobody knows what all those flags are |
| 16:21.41 | *** join/#brlcad gurwinder (75dcabb9@gateway/web/freenode/ip.117.220.171.185) |
| 16:22.21 | Izakey | Hi gurwinder |
| 16:22.29 | gurwinder | brlcad: sorry I have to leave IRC because thats my time to go on physical training |
| 16:22.30 | sofat | So you want to show all flag without drop down i am right ?? |
| 16:22.44 | gurwinder | Izakey: Hi |
| 16:23.27 | Izakey | gurwinder, That's all right. Make sure however, that you be on iRC when working on your GSoC project :) |
| 16:24.06 | gurwinder | Ok, I will keep that in mind :) |
| 16:24.30 | Izakey | brlcad, when running cmake, I get some warnings |
| 16:24.57 | brlcad | gurwinder: just because *you* go somewhere does not mean that your IRC client must disconnect |
| 16:25.20 | brlcad | Izakey: yes, I know -- starseeker made some changes that are noisy |
| 16:25.28 | Izakey | Warings like : This warning is for project developers. Use -Wno-dev to suppress it. |
| 16:25.51 | brlcad | those are safe to ignore (you can add -Wno-dev to cmake line) |
| 16:26.02 | brlcad | sofat: no, that is not right |
| 16:26.04 | gurwinder | brlcad: I disconnect by thinking that if I didn't reply it put bad impression |
| 16:26.22 | sofat | Ok |
| 16:26.23 | brlcad | sofat: a) show language name WITH all flags |
| 16:26.54 | gurwinder | brlcad: I will keep that in mind in future |
| 16:26.58 | brlcad | sofat: b) use the links I gave you for customizing the google-translate drop-down |
| 16:27.17 | brlcad | sofat: c) use the better icons I gave you links for |
| 16:27.51 | brlcad | gurwinder: I don't understand -- if you didn't reply to what? |
| 16:28.00 | brlcad | you mean if I answer and then you don't reply to my answer? |
| 16:28.58 | sofat | Ok i will do this as soon as possible |
| 16:29.05 | gurwinder | brlcad: yes if I didn't reply to your answer |
| 16:29.18 | brlcad | and why would you not answer? :) |
| 16:31.31 | Izakey | feels frustrated about this build issue |
| 16:31.45 | gurwinder | brlcad: haha confusing you? I am telling that if I am online on IRC and if I am outside like I was today and disconnected my IRC |
| 16:32.33 | gurwinder | And you put a message for me and I was not able to reply to you that make bad impression |
| 16:32.48 | brlcad | gurwinder: you're not confusing me, I'm trying to get you to understand how to use IRC appropriately... |
| 16:33.12 | brlcad | you clearly can't reply if you fully disconnect from IRC |
| 16:33.17 | brlcad | and that's my point |
| 16:33.23 | brlcad | don't disconnect your IRC client |
| 16:33.33 | gurwinder | brlcad: Oh ok got it |
| 16:33.37 | brlcad | for that, you probably need a better IRC client, the web interface is only meant to be temporary |
| 16:33.51 | brlcad | if you're afraid of missing my repsonse when you get back, then you're using IRC wrong |
| 16:34.05 | brlcad | and/or need to learn how to use "/last -hilight" |
| 16:34.57 | brlcad | IRC is not meant to require your full attention all the time, that's why when I write gurwinder that it is highlighted to you differently (at least most real IRC clients do this well) |
| 16:35.11 | brlcad | you can also set up triggers to watch for that will cause additional hilighting |
| 16:35.56 | brlcad | like if you want to know when anyone says anything about "web", you can set that up as a highlight and revisit discussions when you get back to IRC |
| 16:36.13 | brlcad | most that use IRC productively remain connected 24/7 |
| 16:36.59 | archivist | and they dont use flaky wifi connections |
| 16:37.02 | Stragus | Most IRC clients also log everything so you can check if you have missed anything, or what was discussed days ago |
| 16:37.58 | brlcad | exactly |
| 16:38.30 | gurwinder | brlcad: Thats great. I will improve myself. Thanks for good suggestion. :) |
| 16:38.48 | Izakey | They log discussions when you tell them to - not by default |
| 16:38.50 | brlcad | gurwinder: FYI, i'll be sending an announcement out later, but being connected to IRC while working on GSoC is going to be required for the second half of GSoC |
| 16:39.27 | brlcad | Izakey: they log internall.. not all write it out to a file for you without you telling them |
| 16:39.52 | gurwinder | brlcad: Ok, I will remain connected when I'm on work for GSoC. |
| 16:40.13 | brlcad | meta-p and meta-n (esc key == meta) with take you forward and backward through your backlog |
| 16:40.26 | brlcad | gurwinder: that's a minimum requirement, everyone should be connected 24/7 |
| 16:40.41 | brlcad | we're collectively failing on communication this year in a big way |
| 16:40.42 | gurwinder | brlcad: need to discuss about next work |
| 16:41.04 | brlcad | and I blame myself for not establishing the importance of IRC earlier on during evaluations and selections |
| 16:41.31 | brlcad | gurwinder: sure, lets discuss |
| 16:41.50 | brlcad | Izakey: did blowing out the build dir and re-running cmake not work? |
| 16:42.10 | brlcad | Izakey: post the full transcript (from rm-rf through cmake to error) |
| 16:42.28 | Izakey | Yes it didn't. Google isn't either |
| 16:42.43 | gurwinder | brlcad: I have discussion with Izakey and I came to decision that I will go with g-pov export project |
| 16:43.12 | gurwinder | and after doing that I will do linuxcnc. Is it right? |
| 16:43.16 | *** join/#brlcad ih8sum3r (~ih8sum3r@122.173.51.91) |
| 16:43.33 | brlcad | gurwinder: no right (partially) ;) |
| 16:44.17 | brlcad | gurwinder: I spoke about things with the linuxcnc folks and we've decided to let this opportunity pass |
| 16:44.35 | brlcad | so you can just focus on your original proposal, continue to work on the povray exporter |
| 16:44.47 | brlcad | no more cross-project collaboration |
| 16:45.50 | brlcad | gurwinder: that said, I'd still like to hear more from you on what happened, why it didn't work out |
| 16:46.14 | gurwinder | brlcad: ok, that sentence give me releif :P |
| 16:46.17 | brlcad | first, thank you for your efforts, for trying to accommodate a project, switch your plan, invest effort and energy |
| 16:46.42 | brlcad | we really did want a collaboration this year, and it was a big undertaking that was not planned well in advance |
| 16:47.26 | brlcad | I still think you would be qualified given what you've demonstrated with the povray work and your ability writing C code, so I'm left wondering what the problem(s) were |
| 16:47.51 | brlcad | what were the biggest challenges? |
| 16:48.33 | gurwinder | why it didn't work out? I think you are talking about linuxcnc right? |
| 16:49.00 | gurwinder | challenges? for povray or linuxcnc? |
| 16:49.58 | brlcad | blinks |
| 16:50.06 | brlcad | we're talking about linuxcnc |
| 16:50.21 | brlcad | why a project was not easy to establish |
| 16:50.39 | gurwinder | brlcad: ok, |
| 16:50.53 | gurwinder | first, according to me |
| 16:51.21 | Izakey | brlcad, Konrado told me it there was no access to documentation about a machine |
| 16:51.23 | brlcad | you've arguably been productive and are experienced with C and they have potential C projects, so I'm left wondering why finding a project was seemingly so difficult |
| 16:51.47 | gurwinder | its a project which requires knowledge and also some experiance of how to work with cnc machine |
| 16:52.11 | gurwinder | brlcad: No the part on which I was working is on python |
| 16:53.32 | gurwinder | I have tried to get in C code but I'm not able. So I decided to work on help page |
| 16:54.21 | brlcad | why not able? |
| 16:54.32 | gurwinder | which was well appriciated by developers. So I have done some work on help pages. Write help pages for stepconf |
| 16:54.38 | Izakey | brlcad, pastebin and kde Paste are down. |
| 16:54.49 | brlcad | ~pastebin |
| 16:54.49 | infobot | A "pastebin" is a web-based service where you should paste anything over 3 lines so you don't flood the channel. Here are links to a few: http://www.pastebin.com, http://pastebin.ca, http://channels.debian.net/paste, http://paste.lisp.org, http://bin.cakephp.org/; or install pastebinit with yum or aptitude. |
| 16:55.02 | brlcad | just not pastebin.com |
| 16:55.33 | Izakey | here is link to doc https://docs.google.com/document/d/1y6nxJr2zOsWgywcea8oX_VYn95KyxRr-02Zatq4nysU/edit?usp=sharing |
| 16:55.39 | ih8sum3r | Hey brlcad, I'm trying to install meteor on freeBSD 10.1. Due to no direct support I have used meteor bundle to install it. Right now I'm facing this error http://brlcad.org/wiki/File:Meteor_freeBSD_libm.so.6_error.png and following this tutorial http://grigio.org/meteorjs_freebsd_11_current/. I explored for the solution, and found that installing compact6x from ports may help. I did but it didn't worked out. Do you have any idea what is this? |
| 16:55.42 | brlcad | gurwinder: this isn't an evaluation of your work with them, I want to understand why it was difficult |
| 16:56.27 | gurwinder | brlcad: I was not able because it need to know how cnc machines are working. |
| 16:56.28 | brlcad | ih8sum3r: ditto comments to you too about needing to be on IRC more, discussing more .. not disconnecting from IRC |
| 16:56.52 | brlcad | ih8sum3r: just because your body steps away from the computer doesn't mean you need to disconnect from IRC ;) |
| 16:57.13 | brlcad | i'll be sending out a note later about this to everyone, so just a heads up that being on IRC is going to be enforced more in this second half |
| 16:57.39 | brlcad | gurwinder: I'm specifically remembering the tapping proposal idea .. it didn't really require any knowledge of the machine |
| 16:57.46 | Izakey | brlcad, There you go http://pastebin.ca/3062161. |
| 16:57.49 | brlcad | gurwinder: so what was the issue there? |
| 16:57.51 | *** join/#brlcad vasc (~vasc@bl13-100-5.dsl.telepac.pt) |
| 16:58.25 | brlcad | ditto to vasc, heads up that being more available on IRC is an announcement that is going to get sent out to everyone |
| 16:59.06 | ih8sum3r | brlcad: Okay will take care of it :) |
| 17:00.21 | gurwinder | brlcad: But I found that it requires because thats the way to work properly and understand what the code does. |
| 17:03.08 | sofat | brlcad, if i use hover effect means when mouse over the flag and then language name highlight it is ok or not ? |
| 17:03.40 | brlcad | ih8sum3r: libm.so.6 is installed in compats |
| 17:04.12 | brlcad | you have to find where (presumably in npm) and how it's linking libm |
| 17:04.55 | brlcad | and either relink it so it uses the correct /lib/libm.so.5 or the /usr/compat/linux/lib/libm.so.6 |
| 17:05.21 | brlcad | gurwinder: how is it required? |
| 17:05.39 | brlcad | sofat: hovering is not good |
| 17:05.54 | brlcad | hovering leads to searching, and searching is bad |
| 17:06.03 | brlcad | (blindly searching) |
| 17:06.32 | brlcad | ih8sum3r: are you able to run npm? |
| 17:06.33 | sofat | Ok so i need list view which contain flag and name |
| 17:07.14 | brlcad | sofat: I gave you 6 links yesterday that showed how to do it (including 2 links to good flag resources) |
| 17:07.16 | ih8sum3r | brlcad: I checked in compats and found libm.so only. Let me check one more time. Yes I'm able to run npm but with sudo power. |
| 17:07.57 | *** join/#brlcad milinda (~milinda@112.134.0.219) |
| 17:08.15 | brlcad | sofat: don't forget to learn screen+irssi |
| 17:08.35 | brlcad | sofat: seriously, try and learn it now not later .. it's affecting your productivity |
| 17:10.57 | gurwinder | brlcad: As i have discussed with community on it. They gave me some task for bigners. I afraid that C coding part is harder for bigneer as I didn't know much about linuxcnc |
| 17:12.01 | gurwinder | So I started linuxcnc from easy tasks. |
| 17:13.34 | brlcad | what makes it hard? |
| 17:15.11 | ih8sum3r | brlcad: I have encounter with a strange error, that I'm not able to checkout in my branch it remains in master always. In master I think meteor 0.8 version is present and mine is upgraded to the latest i.e 1.0.2 :-/ |
| 17:16.41 | Notify | 03BRL-CAD:ejno * 65646 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: write CCONE1 records |
| 17:17.21 | brlcad | ih8sum3r: I don't understand what you're saying there -- if you have a git clone, then you should be able to checkout |
| 17:17.58 | brlcad | also the relevance of the versions of meteor is not apparent |
| 17:18.29 | brlcad | given there is no official port, you could try to get either version to work (and probably face different challenges) |
| 17:19.02 | brlcad | ih8sum3r: do you have a .bz account? |
| 17:19.24 | ih8sum3r | Yes I have. |
| 17:20.16 | brlcad | gurwinder: what makes it hard? |
| 17:21.26 | gurwinder | brlcad: Sorry, yes I'm trying to write I easy language so that I you can understand what I'm trying to say |
| 17:21.30 | brlcad | ih8sum3r: please explain? |
| 17:21.51 | ih8sum3r | Okay give me a moment. |
| 17:22.49 | gurwinder | brlcad: harder for me to understand the whole code then know how it works and then put myself on proper working. |
| 17:23.18 | brlcad | ih8sum3r: if you need something installed via sudo npm , you just have to ask |
| 17:24.30 | brlcad | gurwinder: yes, but why? I talked with the linuxcnc guys and they said they talked with you a lot and gave you specific guidance (much more than usual) |
| 17:24.48 | ih8sum3r | okay sure I will. Please give me a few minutes I'll explain you step by step, and which command I'm facing the error |
| 17:24.55 | brlcad | so why do you think it was it hard to understand the whole code? |
| 17:25.55 | brlcad | I can't see having access to a CNC machine really helping here... it frankly just makes things much more complicated as that'd be one more distraction to learn that wouldn't help you write code |
| 17:26.16 | brlcad | is their documentation lacking in some particular way? |
| 17:28.27 | gurwinder | brlcad: yes its true that they helped me very much. But if I frankly answer you then, I didn't want to start from that point which put me in troble in future in GSoC. So I have discussed with them |
| 17:28.36 | gurwinder | one of them is Chris Morley |
| 17:28.59 | Notify | 03BRL-CAD:ejno * 65647 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: write a CCONE2 if the CCONE1 internal radii are zero |
| 17:30.02 | gurwinder | he told me to start from basics and then go for C or further deeper. |
| 17:30.40 | brlcad | it would not have put you in trouble in future gsoc |
| 17:30.49 | brlcad | so maybe there was also a communications issue |
| 17:31.38 | brlcad | the objective from the beginning was to work towards a small goal .. you would have only been in trouble if you didn't work or made zero progress |
| 17:34.30 | gurwinder | brlcad: Yes I have done and show progress from first day to them. |
| 17:34.45 | vasc | ok. i was already trying to be here more often. |
| 17:34.48 | gurwinder | I have added help pages make help button workable |
| 17:35.04 | brlcad | vasc: that's good, you can't be here too much ;) |
| 17:35.38 | brlcad | but there's been lots of communication issues this summer of code, more than any other, so some changes have to be made |
| 17:35.56 | vasc | being on different timezones doesn't help. |
| 17:36.03 | brlcad | gurwinder: again, i'm not really interested in what you actually did |
| 17:36.21 | brlcad | vasc: on IRC, that really is minimized if IRC is used properly |
| 17:36.38 | brlcad | which is part of the problem (IRC is not being used properly by nearly everyone) |
| 17:37.21 | brlcad | gurwinder: to clarfiy, I appreciate what you did -- but I really want to understand what made it difficult |
| 17:38.10 | brlcad | e.g., lack of example, lack of docs, lack of discussion, language issues navigating code, code complexity without support from their mentors, etc... |
| 17:38.22 | *** join/#brlcad milinda (~milinda@112.134.0.168) |
| 17:38.48 | brlcad | I'm guessing, only you (and linuxcnc folks to a lesser extent) can really say why it was difficult |
| 17:39.08 | brlcad | maybe you just don't have enough programming experience to feel confident with their code base? |
| 17:39.12 | gurwinder | brlcad: yes lack of eaxmple, code complexity |
| 17:39.36 | ih8sum3r | Summary : |
| 17:39.38 | ih8sum3r | 1) Firstly, I ran this command : meteor build <my_app> This command will create a bundle of meteor app |
| 17:39.40 | brlcad | the tapping problem is a prime example -- that seemed very straightforward and simple to me |
| 17:39.41 | vasc | even if you know c reading someone else's code can be really daunting at first |
| 17:39.47 | gurwinder | and yes I didn't have that much experiance with code |
| 17:39.51 | vasc | especially if the codebase is big |
| 17:40.06 | ih8sum3r | 2). Then moved this bundle to virtual-machine (i.e in freeBSD). I encounter error while moving tar file so I pushed it to github and then clone and then untar it. |
| 17:40.07 | vasc | you have to abstract out of the big issues and focus on a small part of the code |
| 17:40.11 | vasc | or its just too daunting |
| 17:40.17 | brlcad | gurwinder: but you also didn't have much experience with brl-cad and was able to make progress with g-pov .. so what is the difference? |
| 17:40.26 | vasc | which tools are you using? are you using an IDE? |
| 17:41.09 | vasc | i was using vim but i switched to netbeans coz its a lot more practical to navigate the code |
| 17:41.30 | brlcad | our code is considerably more complex and bigger than theirs, and he didn't seem to have a problem making progress with brl-cad |
| 17:41.38 | brlcad | which leaves me wondering why it was difficult with linuxcnc |
| 17:42.34 | brlcad | ih8sum3r: you're running freebsd in a VM, why not on .bz? |
| 17:43.03 | gurwinder | brlcad: I was working on BRL-CAD from a year almost and thats enough time for me to understand how to work on it. |
| 17:43.47 | ih8sum3r | I haven't ever used freeBSD before so I gave a first try on VM. I'll move it right now to .bz :) |
| 17:44.09 | gurwinder | In Linuxcnc its another one for me with new coding so I don't want that I take too much time for it to do that C coding work. |
| 17:44.44 | gurwinder | Maybe others can found it easy :) |
| 17:44.50 | vasc | linuxcnc seems kinda like low level |
| 17:46.03 | vasc | ioctls and stuff |
| 17:46.04 | brlcad | gurwinder: okay, so you had a difference in exploration levels |
| 17:46.09 | vasc | i guess its a hardware control library |
| 17:46.13 | brlcad | and we did have a succinct comparable examples you could follow |
| 17:46.52 | brlcad | gurwinder: I'm also hearing that "you didn't want to do a project with them", I think |
| 17:46.56 | brlcad | is that true? |
| 17:47.42 | brlcad | otherwise "taking too much time for it to do that C coding work" makes no sense to me .. it's simply a 1-month project |
| 17:48.50 | gurwinder | brlcad: I didn't told them directly but I wonder when I told them like this :P |
| 17:49.16 | gurwinder | brlcad: but in the end I decided to complete g-pov export |
| 17:49.21 | vasc | lack of motivation? hm |
| 17:49.26 | brlcad | "I wonder when I told them like this" <-- do not understand |
| 17:49.33 | gurwinder | and then move further |
| 17:50.36 | gurwinder | Sorry I have taken alots of time of you to tell this ;) |
| 17:50.40 | brlcad | aaaand we come full circle back to irrelevant point |
| 17:51.05 | brlcad | yeah, we're still not getting to the heart of what made it difficult exactly |
| 17:51.36 | brlcad | other than what can be inferred like lacking motivation |
| 17:53.06 | brlcad | gurwinder: let me summarize and you tell me if anything is inaccurate since it doesn't sound like you understand what I'm trying to discuss with you |
| 17:54.25 | brlcad | I reached out to you (and others) to consider a linuxcnc project, you reluctantly agreed and began looking at their code and talking with their people |
| 17:54.42 | brlcad | a project however was not established |
| 17:54.57 | brlcad | the main reasons it was not established seem to be a combination of factors including: |
| 17:55.48 | brlcad | 1) deviating from your original proposal worried you that it would affect your gsoc evaluation |
| 17:56.34 | brlcad | 2) the linuxcnc codebase is complex with low-level calls, limited documentation, and seeminly limited examples to work with |
| 17:57.41 | brlcad | 3) you have no experience with linuxcnc and limited programming experience for learning their code base on the fly |
| 17:58.06 | *** join/#brlcad milinda (~milinda@124.43.115.180) |
| 17:58.15 | brlcad | 4) there was a perception that you needed access to CNC hardware in order to be successful or productive |
| 17:58.30 | vasc | what did they make him do for the project anyway? |
| 17:58.42 | gurwinder | brlcad: correct |
| 17:58.43 | vasc | if you don't mind the question |
| 17:59.08 | brlcad | 5) you were not really motivated/interested in working on linuxcnc, especially the more daunting it seemed (it's fine to admit this) |
| 17:59.23 | vasc | well |
| 17:59.32 | brlcad | vasc: they didn't make him do anything |
| 17:59.33 | vasc | if he isn't motivated it would be nice to know exactly way |
| 17:59.37 | vasc | why |
| 17:59.46 | brlcad | we were trying to come up with a half-project proposal |
| 18:00.12 | Stragus | Working on linuxcnc sounds more fun when you know something about CNC in general |
| 18:00.22 | Izakey | brlcad, I think it looked like an optional project and optional projects aren't always taken seriously :) |
| 18:00.27 | gurwinder | brlcad: yes, all the above are true |
| 18:00.46 | vasc | it seems kinda fun to me. but is there are simulator at least? or a way to validate the output? |
| 18:00.49 | brlcad | indeed, motivation rationale would be something like 6) you did not perceive value in contributing to linuxcnc? |
| 18:01.07 | vasc | is there any |
| 18:01.10 | brlcad | Izakey: optional? |
| 18:01.38 | vasc | the thing is, was it the subject area, the library itself, the task he was going to work on, or something else? |
| 18:01.39 | Izakey | GSoC project was kinda mandatory brlcad |
| 18:01.49 | brlcad | you guys are missing some preliminary context that was discussed over e-mail with the cnc guys |
| 18:01.56 | Izakey | So LinuxCNC was looked upon as optional |
| 18:02.00 | brlcad | Izakey: this is a gsoc project |
| 18:02.34 | Izakey | may be missing something |
| 18:02.43 | brlcad | there was nothing optional about it -- he was going to stop working on project A (for BRL-CAD) after the first half and work on project B (for LinuxCNC) in the second half |
| 18:02.51 | brlcad | two half-projects, nothing optional about it |
| 18:02.55 | vasc | oh context switch |
| 18:03.01 | brlcad | reviews and evaluations separate |
| 18:03.11 | vasc | was there any connection between both tasks? |
| 18:03.25 | brlcad | the question is why a project B couldn't be devised |
| 18:03.27 | Izakey | That wasn't announced - again mentors had to be informed |
| 18:03.51 | brlcad | Izakey: eh? |
| 18:04.06 | ih8sum3r | brlcad: Following npm needs sudo to install : npm install fibers@1.0.1 in my repo : public_html/OGV/bundle/programs/server/node_modules. Can you please do so. |
| 18:04.07 | brlcad | it doesn't affect anyone except the student and his mentor |
| 18:04.16 | Izakey | I was under the impression that he had to work on his BRL-CAD project throughout and optionally contribute to LinuxCNC |
| 18:04.19 | brlcad | and it was discussed with them in the loop |
| 18:05.00 | brlcad | Izakey: so that's just a misunderstanding on your part, that was made clear to gurwinder when discussions were set up initially |
| 18:05.20 | brlcad | like I said, just missing some preliminary context |
| 18:05.24 | vasc | but was there a connection between the brl-cad and linuxcnc tasks or not? |
| 18:05.27 | brlcad | didn't mean for this to turn into a big discussion |
| 18:05.34 | Izakey | Initially, it had to be written down somewhere - proposal or something |
| 18:05.45 | brlcad | just trying to understand what made it difficult and what we can change so it's not difficult next time |
| 18:06.02 | brlcad | vasc: none whatsoever |
| 18:06.04 | Izakey | Not a big issue brlcad |
| 18:06.07 | vasc | that's no good |
| 18:06.28 | Izakey | let's dive back inot what hitches were experienced by students working on LinuxCNC |
| 18:06.35 | vasc | context switch bad for productivity |
| 18:06.37 | Izakey | s/inot/into |
| 18:06.46 | vasc | like in the preparation phase |
| 18:06.54 | vasc | he probably prepared for brlcad and not for linuxcnc |
| 18:07.05 | brlcad | vasc: he wasn't doing both simultaneously |
| 18:07.07 | Izakey | I think so too vasc |
| 18:07.19 | vasc | sure |
| 18:07.24 | vasc | but the timeline for project |
| 18:07.33 | vasc | you have preparation phase then coding and then evaluation |
| 18:07.38 | vasc | you needed another preparation phase |
| 18:07.42 | brlcad | it's irrelevant, the timelines were being (re)defined |
| 18:08.02 | brlcad | yes, and lack of preparation was completely accepted |
| 18:08.02 | vasc | what was the brlcad task? |
| 18:08.11 | brlcad | and taken into consideration scoping a new "half-project" |
| 18:08.34 | gurwinder | vasc: brlcad task is g-pov export |
| 18:08.41 | brlcad | the issue was basically that a half-project could not be scoped, even after weeks of discussions |
| 18:08.47 | vasc | you did that one from what i understand |
| 18:09.03 | vasc | well |
| 18:09.06 | vasc | the thing is |
| 18:09.17 | vasc | think if you are motivated about working on linuxcnc or not |
| 18:09.28 | vasc | if you are then think of something you would like to do with it |
| 18:09.48 | brlcad | yes... and that's exactly what I'm trying to get at here |
| 18:09.50 | brlcad | was it motivation? |
| 18:09.53 | brlcad | was it complexity? |
| 18:10.13 | brlcad | what / how can we improve |
| 18:10.24 | vasc | the thing he said is relevant |
| 18:10.24 | brlcad | or even better, what/how can linuxcnc improve |
| 18:10.30 | gurwinder | brlcad: Mostly motivation towards linuxcnc. |
| 18:10.33 | vasc | how can you measure that your work is doing something or not |
| 18:10.47 | Stragus | Motivation can overcome many other difficulties. :) But if gurwinder has no experience or interest with CNC, I can see the problem |
| 18:10.53 | vasc | its hard to work without seeing improved results as you work |
| 18:11.06 | vasc | he doesn't have a cnc machine so he can't see the output |
| 18:11.10 | vasc | i think that's his problem |
| 18:11.45 | brlcad | point taken, and entirely consistent with what was said above |
| 18:11.48 | brlcad | just not the whole picture |
| 18:11.56 | Izakey | vasc += 1 |
| 18:12.38 | vasc | is there a simulator? |
| 18:12.57 | vasc | and then there's the question if a simulator provides enough motivation |
| 18:13.50 | brlcad | it's sounding like the biggest issue was a lack of interest/motivation which became compounded with lacking experience, lacking familiarity, and overall percieved complexity |
| 18:14.02 | vasc | https://www.youtube.com/watch?v=PFdNbaBq760 |
| 18:14.16 | vasc | it seems there are simulators |
| 18:14.36 | brlcad | sure, but you really didn't even need that (remember that a really tiny project is being proposed) |
| 18:15.01 | Stragus | It's still a matter of contributing to software you can't use or test |
| 18:15.02 | brlcad | the C one discussed was basically "write a function that periodically backs out the bit" |
| 18:15.37 | vasc | sure but its kinda dry |
| 18:16.00 | brlcad | Stragus: that might be a concern to you, certainly .. I can come with all sorts of potential detractors :) |
| 18:16.20 | brlcad | the point was understanding gurwinder's specific issues |
| 18:16.35 | Stragus | Fine. :) I'm absolutely terrible at writing code when there's no motivation |
| 18:16.40 | vasc | me too |
| 18:16.47 | brlcad | e.g., did *he* find it dry? in which case I can give them feedback that it sounded boring or the impact was unclear |
| 18:16.57 | brlcad | who isn't? |
| 18:17.00 | vasc | unclear yes |
| 18:17.13 | brlcad | he was initially motivated, hence weeks of discussions |
| 18:17.13 | vasc | like why do you need to do that in the first place |
| 18:17.21 | brlcad | that was discussed |
| 18:17.26 | vasc | so he probably likes the idea of working in cnc then |
| 18:17.36 | brlcad | I'm really oversimplifying because you guys are overanalyzing without context :) |
| 18:17.46 | vasc | that's what humans do |
| 18:18.05 | vasc | anyway |
| 18:18.05 | brlcad | not all of them :P |
| 18:18.14 | vasc | from what i understand you want to salvage this somehow |
| 18:18.17 | brlcad | nope |
| 18:18.34 | vasc | my advice is start from scratch |
| 18:18.44 | vasc | figure out a task he wants to do |
| 18:18.49 | vasc | somewhere |
| 18:18.52 | brlcad | this was simply a post-mortem -- learn from what happened and try to institute changes so it's better next time if the exact same entry criteria were encountered |
| 18:18.53 | Stragus | likes how 4 individuals are debating gurwinder's motives, feelings and motivations ... without any knowledge of the situation or the person involved |
| 18:19.00 | vasc | oh ok |
| 18:19.05 | vasc | :-) |
| 18:19.15 | vasc | we can ask him then |
| 18:19.20 | brlcad | was :) |
| 18:19.40 | brlcad | the six points summarized seemed to fix, yes gurwinder? |
| 18:20.18 | Stragus | trades a 't' to brlcad against a 'x' |
| 18:20.23 | brlcad | he kept responding with what he did with them, not understanding the underlying motivations (or lack thereof) underpinning his actions |
| 18:20.37 | brlcad | s/fix/fit/ ;) |
| 18:20.48 | vasc | i thought you made 5 points |
| 18:20.55 | brlcad | the six points summarized seemed to fit your situation, yes gurwinder? |
| 18:21.40 | gurwinder | brlcad:yes |
| 18:22.21 | brlcad | then we're done :) |
| 18:22.26 | brlcad | gurwinder: thanks |
| 18:22.59 | gurwinder | brlcad: Thanks to you:) |
| 18:23.49 | brlcad | heh, I don't do anything around here except make things complicated ;) |
| 18:24.44 | vasc | i read his gsoc summary page so he was supposed to work on the machine cnc setup gui or something |
| 18:24.57 | Stragus | That does sound boring |
| 18:26.50 | brlcad | from my understanding talking with them, they were having problems discussing and making technical progress on other projects -- given the level of programming experience |
| 18:27.07 | brlcad | so they kept suggesting simpler and simpler topics |
| 18:27.34 | brlcad | the drill tapping problem was actually somewhat interesting to me, and seemed doable in a couple weeks |
| 18:28.09 | brlcad | you improve the bit life and machining tolerances if you back the bit up periodically when cutting material |
| 18:28.38 | brlcad | e.g., drilling a hole, it's what humans do holding hand drills -- pull back to extract the material |
| 18:29.32 | brlcad | doing that programmatically, automatically, was pretty cool -- they had demo videos, similar code refs, and a real need/value |
| 18:30.00 | brlcad | but he couldn't seem to even understand the problem domain, perhaps a language barrier issue |
| 18:30.19 | vasc | yeah probably |
| 18:30.20 | brlcad | which I'm sure doesn nothing for motivation... |
| 18:30.51 | Stragus | What's his first language? I frequently notice subpar english around here... |
| 18:31.15 | vasc | i used to be around my dad when he was fiddling in the garage with tools when i was a kid so i get the point |
| 18:31.17 | Stragus | (though it's also a second or third language for me) |
| 18:31.40 | vasc | he's indian from the name man |
| 18:32.12 | ih8sum3r | brlcad: Ping |
| 18:33.23 | brlcad | Stragus: there are several people participating this year that have limited english skills .. at least one that actively uses google translate on everything yet is somehow still able to make progress and hold a conversation |
| 18:33.41 | Stragus | :) Cool |
| 18:33.57 | vasc | maybe he doesn't have background to allow him to relate to it |
| 18:34.12 | Stragus | Yes, I wouldn't be very interested in CNC either |
| 18:34.13 | Izakey | An article should be written about that and published to ospo blog |
| 18:34.18 | vasc | i'm interested |
| 18:34.25 | brlcad | ~ask |
| 18:34.25 | infobot | Questions in the channel should be specific, informative, complete, concise, and on-topic. Don't ask if you can ask a question first. Don't ask if a person is there; just ask what you intended to ask them. Better questions more frequently yield better answers. We are all here voluntarily or against our will. |
| 18:34.55 | brlcad | Stragus: so have you noticed your code getting ripped apart? :) |
| 18:35.01 | vasc | i'm portuguese so english isn't my first language either |
| 18:35.09 | brlcad | wouldn't know it |
| 18:35.13 | Stragus | Which one? The ball pivoting deserved it |
| 18:35.28 | Stragus | I have always promoted a better approach and was pretty much ignored |
| 18:35.41 | brlcad | no, ball pivoting was outright yanked because .. patented! ugh |
| 18:36.13 | brlcad | well it's completely unusable now that particuarly legality came to light |
| 18:36.54 | Stragus | Yes, I heard. Maybe someone will now actually listen to my ideas for a viable approach |
| 18:36.55 | brlcad | the incremental decimation code |
| 18:37.18 | Stragus | Okay, why did you want to rip it apart? :) I think it's solid code |
| 18:37.21 | brlcad | it's hooked in and working |
| 18:37.24 | Stragus | Cool |
| 18:37.32 | brlcad | oh nothing too tragic |
| 18:37.40 | brlcad | a lot of dead code elimination |
| 18:37.59 | brlcad | and ton of changed needed to make it portabile |
| 18:38.10 | Stragus | Ah yes, removal of #if switches and experimental code everywhere |
| 18:38.17 | brlcad | pretty much only worked on like one platform out of the box (linux) |
| 18:38.24 | Stragus | Oh uh... |
| 18:38.26 | Stragus | hides! |
| 18:38.59 | brlcad | much of the asm that could be made portable is getting ripped / tested for portable C |
| 18:39.05 | Stragus | Besides portability issues, I really like the algorithms and performance, the best mesh decimation code I'm aware of |
| 18:39.16 | Stragus | Ah yes, mmatomic.h |
| 18:39.29 | brlcad | I think that's all gone now, or near to it |
| 18:39.46 | brlcad | threading model is getting converted |
| 18:40.11 | Stragus | mmthread.h was a thin wrapper so you would change the inner guts as desired |
| 18:40.27 | brlcad | I think he told me you used a thread interruption model just so you could peek at their status (% complete) |
| 18:40.50 | Stragus | It wasn't interrupting anything, just using atomics |
| 18:41.20 | brlcad | mm, that's not the story I heard, but I haven't looked at the code myself |
| 18:41.36 | brlcad | pausing threads |
| 18:41.56 | brlcad | or at least code-wise, you had calls in there that could do that given some condition/request |
| 18:42.14 | brlcad | anyways, that's all gotten / getting changed |
| 18:42.23 | brlcad | it is working and mostly working well |
| 18:42.27 | brlcad | gotten it to crash a few times |
| 18:42.39 | brlcad | (before all the changes) |
| 18:43.00 | Stragus | Looking at the code now. The only global barrier is there just to make sure all threads have started so that I can poke at their data |
| 18:43.09 | Stragus | If you remove that barrier check, you can have a race condition |
| 18:43.45 | Stragus | It's certainly not interrupting anything |
| 18:43.49 | brlcad | nods, sounds like what's being changed to a different threading setup |
| 18:44.28 | brlcad | could have misunderstood on my part, it was a brief discussion |
| 18:44.41 | brlcad | but there have been tons of commits |
| 18:44.50 | Stragus | I'll have to look it up |
| 18:44.52 | brlcad | making good progress turning it into a feature |
| 18:44.56 | Stragus | Cool |
| 18:45.12 | brlcad | way better than our old naive tolerance-based method |
| 18:45.58 | brlcad | did you ever profile how much gain your atomics provided on the algo? |
| 18:46.22 | Stragus | Hum yes. I remember it was significant |
| 18:46.32 | Stragus | Can't quite remember what "significant" meant back then |
| 18:46.35 | brlcad | heh, what's significant to you |
| 18:46.59 | brlcad | for decimation, it's got to be pretty huge to make a difference |
| 18:47.08 | Stragus | I think that on machines with many cores (like 64), it was big |
| 18:47.10 | brlcad | 11s vs 20s is not interesting |
| 18:47.17 | brlcad | 11s vs 200s is interesting ;) |
| 18:47.21 | Stragus | Without atomics, it stopped scaling |
| 18:48.11 | brlcad | 0.2s vs 5s is not "very" interesting, but 0.2s vs 50s is .. |
| 18:48.17 | *** join/#brlcad deepak (~deepak@122.173.51.91) |
| 18:48.29 | brlcad | basically does it make small models no longer interactive if asm is ripped out |
| 18:48.45 | brlcad | or is this like a sub-order-of-magnitude tweaking |
| 18:48.50 | Stragus | It's a matter of scalability with the count of cores |
| 18:48.57 | Stragus | Remove atomics on a single core, who cares |
| 18:49.12 | Stragus | Remove atomics on 64 cores, and it may be 10x slower (can't remember what it was) |
| 18:49.25 | brlcad | we'll have to test that |
| 18:49.37 | Stragus | This is an algorithm based on lock-free multithreaded hash tables |
| 18:49.40 | brlcad | though that still might not matter then |
| 18:50.28 | Stragus | I see the MD_CONFIG_ATOMIC_SUPPORT switch, to use spin locks instead of atomics everywhere |
| 18:50.43 | brlcad | it'll depend on context, 10x slower than what baseline will matter |
| 18:51.00 | brlcad | yeah, he saw that |
| 18:51.54 | Stragus | Why would you want to remove atomics? Portability? |
| 18:52.05 | brlcad | basically we have to characterize the performance gain with the maintenance cost .. portable asm is pretty much non-existent, so it's generally really costly to make pervasively cross-platform -- the gain has to be huge |
| 18:52.07 | Stragus | At least make them optional, that's the whole point of MD_CONFIG_ATOMIC_SUPPORT |
| 18:52.44 | Stragus | When I write platform-specific code, I always code a portable fallback path, like that switch |
| 18:52.45 | brlcad | it's got a cost whether it's enabled or not |
| 18:52.59 | brlcad | we take that into consideration |
| 18:53.09 | Izakey | brlcad, I'd apprecaite it if you look at the paste and suggest some ideas ;) |
| 18:53.14 | Stragus | All right. But the algorithm was really designed to be lock-free through atomics |
| 18:53.27 | brlcad | Stragus: like I said .. "ripped" |
| 18:53.29 | brlcad | :) |
| 18:54.36 | vasc | i think there are gnu c extensions for some of that |
| 18:54.38 | Notify | 03BRL-CAD:lbutler * 65648 brlcad/branches/embree/src/ert/ert.cxx: We are shooting our first embree ray on BRLCAD geometry |
| 18:54.40 | brlcad | I'm half-kidding, we'll just have to see what the performance looks like |
| 18:55.17 | Stragus | Darn, so you guys tore out all the elegance of the algorithms used for "ease of maintenance" :p |
| 18:56.08 | brlcad | vasc: and on intel compiler, embarcadero compiler, ibm compiler, llvm, msvc? .. we historically value extreme portability very highly, more than most. :) |
| 18:56.08 | Stragus | Pthread spin locks are still just an int32_t, but don't go replacing them with mutexes taking 80 bytes, memory usage will be catastrophic |
| 18:56.32 | brlcad | Stragus: not yet, still baselining performance -- or at least it's mid-tearing |
| 18:56.44 | vasc | ah platform compatibility is overrated. only x86 and arm matter. rest is irrelevant. |
| 18:57.11 | brlcad | there's a reason brl-cad has survived longer than I have :) |
| 18:57.34 | brlcad | over the past three decades I could have said that same statement for at least three different architectures |
| 18:57.59 | brlcad | and they inevitably died |
| 18:58.02 | vasc | well x86 is nearly as old as i am |
| 18:58.12 | brlcad | i frankly doubt x86 would have survived without microsoft |
| 18:58.31 | Stragus | I would rather add support for new archs in mmatomic.h than obliterate performance |
| 18:59.27 | brlcad | Stragus: there's no way you would perform all the long-term maintenance involved in supporting and maintaining portability -- it's just not what you do (no motivation, heh) |
| 18:59.28 | Stragus | And when C gets native atomics, mmatomic.h could just wrap then with a tiny performance impact |
| 18:59.52 | brlcad | especially all the build system management and support for platforms as changes come about |
| 19:00.23 | Stragus | (C atomics would have issues with spin locks with the special "NOP" encoding meant to switch to the other thread in hyperthreading processors, and other very small such issues) |
| 19:01.21 | vasc | so you can't use stdatomic? |
| 19:02.15 | brlcad | if the atomics get ripped out and it's only double-digit-% slower through 32 cores, it won't really have any discernable impact on the feature (which really is what this is all about) |
| 19:02.25 | Stragus | It's C code, and C11 is supposed to support native atomics. Not that BRL-CAD would demand C11 before 2025 anyway :p |
| 19:03.07 | brlcad | pfft, maybe 2020 |
| 19:03.36 | Stragus | I suppose you also throw out all traces of SSE? |
| 19:03.48 | brlcad | don't know |
| 19:04.11 | brlcad | we have other SSE code, so that bit doesn't add much to maintenance complexity |
| 19:04.19 | brlcad | there are already build system checks and it's easy to toggle off |
| 19:04.30 | brlcad | and hasn't demonstrated much of a maintenance cost over time |
| 19:04.33 | Stragus | Okay. |
| 19:04.37 | brlcad | the code duplication is annoying |
| 19:04.44 | brlcad | s/code/logic/ |
| 19:04.48 | vasc | imo sse is a waste. |
| 19:04.58 | Izakey | brlcad, did Vladbogo finish the Qt project |
| 19:05.08 | brlcad | Izakey: define finish |
| 19:05.17 | Izakey | ? |
| 19:05.19 | vasc | intel obsoletes and supersedes those instructions sets so quickly why bother... |
| 19:05.26 | Stragus | A "waste"? A free 3x performance boost? |
| 19:05.35 | vasc | well its like a said |
| 19:05.37 | brlcad | Izakey: what do you mean by "finish the Qt project"? |
| 19:05.49 | Stragus | It may become "obsolete" but it still runs, even if there's the fancy new AVX |
| 19:05.49 | vasc | that's why i went in to opencl anyway |
| 19:06.13 | brlcad | there were two Qt efforts, related by distinct and specific in focus |
| 19:06.15 | vasc | you get the performance and you can ignore the flavor du jour vector instruction |
| 19:06.19 | brlcad | s/by/but/ |
| 19:06.40 | Stragus | vasc, that only works for very simple and trivial parallelization |
| 19:06.50 | Izakey | Is BRL-CAD ready to fully transition to Archer instead of dabbling between mged and archer brlcad ? |
| 19:07.10 | vasc | it's good enough for what i've been using it for |
| 19:07.24 | vasc | its a lot more complicated than sse in a lot of ways |
| 19:07.48 | vasc | opencl is c with vector extensions basically |
| 19:07.54 | Stragus | Try to get OpenCL to output phminposuw instructions :p |
| 19:08.08 | brlcad | Stragus: I claim most problems can be implemented with simple and trivial parallelization terms, and it's actually a VERY GOOD THING to do them that way |
| 19:08.26 | Stragus | Or even movmskps |
| 19:08.27 | brlcad | easier for other devs to understand the logic, easier to maintain, easier to debug ... |
| 19:08.50 | vasc | there are libraries that can do that on arbitraly length vectors |
| 19:09.13 | Stragus | brlcad, if you don't mind lower performance, yes |
| 19:09.20 | vasc | well |
| 19:09.31 | vasc | i expect the compiler to optimize that and if it doesn't i don't care anyway |
| 19:09.49 | Stragus | Right. I care about performance a lot more than this |
| 19:09.54 | vasc | is it that much more efficient than using multiple ops? |
| 19:09.59 | Stragus | Oh yes |
| 19:10.40 | vasc | or this could be a CISC vs RISC like issue |
| 19:14.20 | brlcad | Stragus: indeed, that is the issue -- performance is secondary to maintainability when involving more than one dev, which is inevitable |
| 19:14.23 | brlcad | (the author eventually moves on, gets bored, doesn't have time/motivation, dies) |
| 19:15.13 | brlcad | you don't care if it's maintainable because you're willing to maintain it now (for your limited environment) and when you're not willing, you just won't care |
| 19:15.43 | Stragus | That's why there's an #if to handle all these non-supported platforms/compilers/whatever |
| 19:15.50 | vasc | i'm more concerned of trying to compile it in 5-10 years and finding it doesn't work anymore |
| 19:16.00 | Stragus | It will work, it will fall back on the slow #else path |
| 19:16.05 | brlcad | Stragus: that still doesn't extrapolate to maintenance |
| 19:16.11 | brlcad | the code will eventually change |
| 19:16.24 | Stragus | Then fix both branches of the #if ;) |
| 19:16.26 | brlcad | and now I have N versions that have to be updated that have cost*N (really more) |
| 19:17.00 | brlcad | there's plenty of history on that bitrot pattern being long-term unsustainable |
| 19:17.25 | Stragus | You can also cut away the #if when it has become irrelevant |
| 19:17.40 | brlcad | which is the point that it works and is fast enough ;) |
| 19:17.45 | vasc | the problem sometimes is that one of the sides of the #if doesn't get tested |
| 19:17.53 | vasc | and eventually goes stale and doesn't work |
| 19:17.58 | vasc | but is still there |
| 19:18.10 | vasc | and no one wants to take it out |
| 19:18.37 | vasc | and you don't refactor it coz you can't because it would break the #if that no one uses and doesn't work anyway |
| 19:18.49 | vasc | shit like that |
| 19:19.01 | Stragus | You can always that disable that #define permanently if it becomes unsupported |
| 19:20.35 | Stragus | Eh well. :) I understand your points, but a programmer is also an artist, and to see an elengant and efficient piece of code made inferior for... poor reasons (from my point of view) is rather sad |
| 19:21.06 | Stragus | elegant* |
| 19:21.22 | brlcad | except even the time to debug the failed build when it eventually became unsupported, having to evaluate the cost to inspect/analyze that old code (which by that point it would be), has a signficant cost in itself, especially for secondary authors |
| 19:22.15 | brlcad | at that point, it's just old broken code in a large ecosystem of code, one small feature out of thousands |
| 19:22.17 | Stragus | I guess the code should document clearly when some switches can be safely disabled, whenever desired or have become irrelevant |
| 19:23.03 | brlcad | heh, that's like planting a timebomb |
| 19:25.02 | Stragus | hides his CUDA code from brlcad, where some PTX assembly somewhere is relying on the undocumented behavior of a specific generation of CUDA hardware |
| 19:25.04 | brlcad | if I simply scale performance two orders of magnitude (approximately 12 years), these performance adjustments and architecture linkages will be pretty much irrelevant, it's almost a given |
| 19:25.53 | Stragus | 3x faster is always 3x faster, it doesn't become irrelevant |
| 19:26.04 | Stragus | You can just handle more data |
| 19:27.35 | brlcad | sure it does, because of new architecture pipeline that provided a new set of instructions or made a whole method of "coherent" calculation obsolete |
| 19:28.07 | Stragus | Fine, these new instructions (let's call them AVX!) are now 6 times faster. But the old stuff is still 3x faster than plain C |
| 19:28.43 | ih8sum3r | brlcad: Following npm needs sudo to install : npm install fibers@1.0.1 in my repo : public_html/OGV/bundle/programs/server/node_modules. |
| 19:28.52 | brlcad | or a new compiler that takes the 0.9x code and makes it 5x faster .. or a plenty of other imaginable scenarios 12 years from now that will make the *code* irrelevant |
| 19:29.26 | brlcad | ih8sum3r: on it |
| 19:29.49 | ih8sum3r | okay |
| 19:30.10 | Stragus | brlcad, that's a possible scenario, and that's why we should always keep a plain C portable version of the code |
| 19:30.25 | Stragus | hugs the preprocessor |
| 19:30.35 | brlcad | at the end of the day, it will still be far more important to a user that the little feature in their app that takes a mesh and simplifies it for them is robust and easy to use, regardless of it taking 1s vs 5s |
| 19:30.58 | Stragus | With the meshes Lee was managing, it was a matter of minutes |
| 19:31.04 | brlcad | more than likely, an entirely different decimation algorithm will get coded up that has fantastical properties and it all becomes moot |
| 19:31.10 | Stragus | Hence the optimized multithreaded lock-free algorithms |
| 19:31.43 | brlcad | if it's during export, nobody cares |
| 19:32.10 | brlcad | they care only LONG after it's tightly integrated into their pipeline of activities and is repeated (usually for months, years) |
| 19:32.23 | brlcad | a one-off export that takes minutes, literally .. nobody cares |
| 19:32.36 | brlcad | they care when it doesn't work! |
| 19:33.01 | brlcad | different value system from devs |
| 19:33.06 | Stragus | Right. In Lee's code, it was to convert CSG meshes to triangles after raytracing, so performance mattered |
| 19:33.13 | Stragus | You don't want to wait 10 minutes to open a file |
| 19:34.06 | brlcad | except that was also for an analysis purpose which I would have argued that I don't want decimation until I can prove it has no analytic impact :P |
| 19:34.26 | brlcad | performance for the sake of performance without scientific justification |
| 19:34.51 | brlcad | extraordinary claims require extraordinary proof, which he did not do |
| 19:35.14 | brlcad | heck, he didn't do any |
| 19:36.06 | Stragus | I believe good mesh decimation was "okay" there, but ball pivoting was catastrophic |
| 19:36.22 | Stragus | An algorithm not guaranteed to generate watertight meshes... for analysis... |
| 19:36.53 | Stragus | wrote the code but isn't responsible for that |
| 19:37.15 | brlcad | no way that "okay" was anything more than visually inspected |
| 19:37.33 | brlcad | which is not in any way scientific for the given problem domain :) |
| 19:38.06 | Stragus | Point accepted :) |
| 19:38.14 | ih8sum3r | brlcad: I have read following quote on official meteor docs "(The current release of Meteor [1.1.0.2] has been tested with Node 0.10.36.)". Will this cause any kind of conflict, as our node version is 0.12.6? |
| 19:38.32 | brlcad | geometrically, I did extensive studies that helped to understand that tessellation+decimation as currently implemented is a guaranteed mass loss because of the techniques being used |
| 19:38.42 | brlcad | and that mass loss is highly biased towards small components |
| 19:38.56 | Stragus | brlcad, ah yes, that's interesting |
| 19:39.03 | brlcad | so if you have small important components losing mass, that could be dramatically influencing analytic results |
| 19:39.31 | brlcad | does it matter? nobody has studied this but it geometrically and numerically is signficiant |
| 19:39.38 | Stragus | nods |
| 19:40.52 | brlcad | on some "real" models, I was seeing about 3-5% mass loss overall iirc |
| 19:41.17 | Stragus | Weird. I was guessing 1-2%, but that's still pretty high |
| 19:41.18 | brlcad | (again biased towards the small curvy components like .. fuel lines) |
| 19:42.05 | brlcad | that was amortized, the distribution was huge with some (really small) components seeing a 50% mass loss |
| 19:42.36 | Stragus | Weird. The fuel line was becoming a 3 sided prism or what? |
| 19:43.04 | brlcad | is speaking abstractly for understanding purposes |
| 19:43.33 | Stragus | Right. I just don't think my mesh decimation would do that, unless the original point clouds wasn't dense enough |
| 19:43.49 | brlcad | loss of detail/resolution, aggregate interior edges chop of mass quickly on small objects (especially curvy and thin ones) |
| 19:44.04 | brlcad | s/chop of/chop off/ |
| 19:44.37 | Notify | 03BRL-CAD:brlcad * 65649 brlcad/trunk/src/librt/primitives/datum/datum.c: update copyright to inception, even though it was derived from the template. |
| 19:44.49 | vasc | keeps trying to understand this piece of code but it seems to be fairly dense. |
| 19:45.04 | vasc | ah what the hell i'll just program as i was a robot and to hell with understanding it |
| 19:45.32 | brlcad | heh |
| 19:45.42 | brlcad | beep boop, what code? |
| 19:46.01 | vasc | its the scenegraph traversal |
| 19:46.11 | brlcad | if you're on the weaver, you might want to check out the .. oh okay :) |
| 19:46.21 | vasc | no thankfully i'm not working on that yet |
| 19:46.31 | vasc | this is the "simple" bit |
| 19:46.59 | brlcad | I frankly think you should just focus on traversal, plan for that being it |
| 19:47.15 | brlcad | dispatch and evaluate in bundles from the front |
| 19:47.25 | brlcad | let the weaver and intersections happen serially |
| 19:47.28 | vasc | i'm still trying to do it without the bundles at first |
| 19:47.30 | brlcad | (they can be next) |
| 19:47.35 | vasc | well |
| 19:49.22 | vasc | this code is so neat and lasagnified that i'm having trouble simplifying some things without rewriting it all |
| 19:50.06 | brlcad | mm. lasagna |
| 19:50.11 | brlcad | so hungry |
| 19:50.42 | vasc | its nicely multilayered and abstracted |
| 19:50.50 | vasc | shame is the abstraction isn't the one i actually want to use |
| 19:51.17 | vasc | something like that |
| 19:51.25 | Stragus | At least he said lasagnified and not spaghettified, so he's not poking my raytracing scene graph code :p |
| 19:51.28 | brlcad | I think that's the first nice thing you've said about it :) |
| 19:52.05 | vasc | that's the pasta theory of software |
| 19:52.27 | vasc | there's spaghetti code, lasagna code, and ravioli code. |
| 19:53.00 | Stragus | My spaghetti code is actually fettucini code, due to thick SSE/AVX parallelism |
| 19:53.03 | brlcad | gives in and goes to get some food |
| 19:56.16 | vasc | oh man... |
| 19:56.41 | vasc | now i get it. a cutter is kinda like an iterator |
| 19:57.06 | vasc | hm no |
| 19:58.25 | vasc | man is this for storing the whole traversal tree? jesus |
| 19:59.25 | Stragus | hands vasc some tasty spinash, horse meat and mushroom sauce to go with that lasagna |
| 20:01.45 | brlcad | only the finest thorobreds |
| 20:01.54 | vasc | oh this is a nice and generic structure that allows you do use grids inside kd-trees and shit like that |
| 20:02.10 | vasc | the question is: is this actually useful or not. i would guess probably not. |
| 20:02.40 | vasc | it probably sounded like a good idea at the time. |
| 20:02.47 | vasc | reminds me of my first ray tracer... |
| 20:06.07 | vasc | c++ dumbs coders. really. |
| 20:06.09 | Notify | 03BRL-CAD:brlcad * 65650 brlcad/trunk/src/librt/primitives/datum/datum.c: document what's going on here better with the buffer size padding, so simple changes to datum data don't end up leaving pockets of dead objects throughout the .g file. also fix a bug in the size where we weren't allocating space for the decode size bytes. |
| 20:06.15 | vasc | it blunts the mind. |
| 20:06.47 | vasc | you start wanting to generalize everything even when you aren't supposed to. |
| 20:06.50 | Stragus | We need a new flexible portable interface to encapsulate the interface around our intermediary interfaces! |
| 20:06.55 | Stragus | Indeed. |
| 20:06.59 | Stragus | cuddles C |
| 20:08.30 | vasc | don't remember me of that. i used to write java server code when i was in the private sector. |
| 20:09.00 | Stragus | I once had to debug OpenSceneGraph, so I run it in my home-made memory debugger, and it was making like 130000 malloc() calls to render a cube |
| 20:09.22 | Stragus | so I ran* it |
| 20:10.49 | vasc | now the question is how can i simplify this without a whole rewrite |
| 20:12.05 | vasc | java is the worst regarding that. especially the j2ee stuff. |
| 20:12.12 | vasc | java itself is an ok language. |
| 20:12.28 | vasc | the problem is what people do with it, and what's considered to be "best practices" |
| 20:13.17 | Stragus | I tried to learn Java once, and they lost me with that "one class per file" non-sense |
| 20:14.00 | vasc | you use too many abstractions and layers to program; so to improve productivity the IDEs GENERATE reams and reams of useless interface code at the press of a button |
| 20:14.46 | vasc | when you can put more than one class per file i think |
| 20:14.56 | vasc | but when you compile it it generates separate .class files |
| 20:15.16 | Stragus | Ahaha |
| 20:15.23 | Stragus | That's definitely not for me |
| 20:15.29 | vasc | so it's considered "best practice" to put one class per source file |
| 20:15.31 | Stragus | Even C++ is too high-level for my taste |
| 20:16.23 | vasc | c++ is convoluted that's the problem. |
| 20:16.32 | vasc | in that regard its even worse than java |
| 20:18.30 | Stragus | The cultures around the languages are also terrible, everyone feels a need to encapsulate everything |
| 20:19.10 | Stragus | They they want to use SSE/AVX with their "vertex" class, and wonder why they have to scrap everything |
| 20:19.16 | Stragus | Then* they want... |
| 20:19.24 | vasc | yes. in that regard i think modula-2 was better. |
| 20:20.03 | Stragus | Wikipedia'ing, never heard of it |
| 20:20.21 | vasc | its ancient and dead |
| 20:20.27 | vasc | its pascal with library support more or less |
| 20:20.31 | Stragus | Oh, eheh |
| 20:20.48 | Stragus | I'm very fond of C, I have looked around and I always come back to it |
| 20:21.49 | Stragus | Or lower level; I have written a x86/amd64 opcode emitter to produce custom-optimized assembly at runtime, and other such stuff that brlcad will absolutely never want to touch... ;) |
| 20:21.58 | vasc | its kinda like if you added namespaces to c. but those namespaces are better than usual. |
| 20:23.10 | vasc | i think most people who want to do that kind of thing now in a portable way use llvm to do it |
| 20:23.43 | Stragus | Yes probably |
| 20:24.02 | vasc | i did a compiler once as a course project |
| 20:24.07 | Stragus | Cool |
| 20:24.15 | vasc | it was a pascal like language |
| 20:24.30 | vasc | and i did everything optimizations and x86 asm output etc |
| 20:24.38 | vasc | besides the parsing and so on |
| 20:24.42 | vasc | which i also did |
| 20:24.57 | Stragus | Very neat. I also wrote a low-level C for my opcode emitter |
| 20:25.20 | Stragus | It was designed to be lower level than C, with extra keywords to communicate more information to the compiler for better optimization |
| 20:25.23 | vasc | so it did parsing, tree generation, convert the tree to ssa form, optimize the ssa, then output x86 |
| 20:25.50 | Stragus | Except I didn't put that much work on it, so GCC pretty much beats it anyway |
| 20:26.12 | vasc | well its a lot of work to do your own compiler |
| 20:26.23 | Stragus | Indeed |
| 20:26.57 | vasc | mine ended up doing a lot of redundant moves and things like that because i didn't do register allocation properly |
| 20:27.26 | vasc | sometimes the asm output looked kinda pathetic |
| 20:28.39 | Stragus | Register allocation is complex. My low-level C also had keywords to specify the probabilities of branches, for the compiler to take better decisions |
| 20:29.28 | Stragus | In the end, I opted for a brute force approach, it would try stuff for minutes until it converged to the lowest "cost" of variable allocation |
| 20:30.32 | vasc | what i did was i did some post optimizations to the actual assembly generated to remove redundant moves and things like that |
| 20:30.40 | vasc | it kinda looked ok except when it didn't |
| 20:31.07 | Stragus | Eheh |
| 20:33.34 | vasc | i also did things like instead of doing a mov eax, 0 i would do a xor eax, eax and things like that |
| 20:34.02 | Stragus | Sure, that's trivial |
| 20:34.24 | vasc | yeah the complicated optimizations were the ssa ones |
| 20:34.36 | vasc | like common sub-expression elimination and dead-code removal |
| 20:34.47 | Stragus | I liked the idea of reshuffling the code through pure brute force, converging towards the least cost solution |
| 20:35.34 | Stragus | The "cost" was meant to be machine-dependent, with knowledge of the pipelines, instruction latency, and so on |
| 20:35.52 | vasc | yeah i didn't do anything like that |
| 20:35.57 | Stragus | I want my compiler to spend a hour optimizing my code to get that last 10% :) |
| 20:36.15 | vasc | that's more complicated. gcc has hardware knowledge to do it |
| 20:37.21 | Stragus | I had coded the information for my own chip back then, Nocona |
| 20:37.47 | vasc | oh |
| 20:37.54 | vasc | you did your own cpu? |
| 20:38.20 | vasc | simulator or fgpa or what? |
| 20:38.38 | Stragus | Of course not, I meant I entered all the pipeline, delay and instruction latency information for the Nocona chip |
| 20:38.43 | Stragus | Intel Xeon Nocona |
| 20:38.45 | vasc | oh |
| 20:38.49 | vasc | right it seemed familiar |
| 20:39.40 | vasc | cona is a slang word here actually |
| 20:39.59 | Stragus | Which language? |
| 20:40.03 | vasc | portuguese |
| 20:40.30 | vasc | there was this software suite, i think was from borland, it was called kona |
| 20:40.30 | Stragus | Right, there's a similar slang word in spanish |
| 20:40.31 | vasc | man |
| 20:40.38 | Stragus | Hum :) |
| 20:40.41 | vasc | i bet they didn't sell a lot in portuguese speaking countries |
| 20:41.16 | vasc | anyway |
| 20:41.30 | vasc | see its a problem to choose a good product name for an international audience |
| 20:41.54 | Stragus | Some companies just rename the product |
| 20:42.02 | vasc | yeah |
| 20:42.24 | vasc | i do know intel and amd basically stuck with using those bogus latin sounding names |
| 20:42.32 | vasc | to prevent that |
| 20:42.41 | vasc | like athlon, pentium, itanium |
| 20:42.58 | Stragus | Here in Quebec, Canada, there's a strong "nationalist" culture, protective of the french language |
| 20:43.16 | Stragus | Some companies or products get renamed in french just here, and nowhere else in the world, not even in France |
| 20:43.20 | vasc | i used to watch french cartoons when i was a kid |
| 20:43.21 | Stragus | (In France, english names are "cool") |
| 20:44.52 | vasc | sometimes people can get really protective of their national identity |
| 20:45.12 | vasc | especially if they feel its threatened somehow |
| 20:46.05 | Stragus | Well yes, it's a long history, with the federal Canadian government trying to assimilate Quebec's french culture for many decades |
| 20:46.20 | vasc | i mean portugal was ruled by foreigners like 4 times in its history. 2x by spanish, 1x by french, 1x by english. last time was like 200 years ago and we still remember it. |
| 20:46.32 | Stragus | Right |
| 20:46.33 | vasc | the english were invited, kind of so |
| 20:46.39 | vasc | that one wasn't an invasion |
| 20:47.12 | vasc | and now its the germans |
| 20:47.15 | vasc | ahem |
| 20:47.35 | Stragus | That's... a complex topic :) |
| 20:54.08 | vasc | the more i look at it the more i feel like rewriting it |
| 20:54.36 | Stragus | What's the code? |
| 20:54.48 | vasc | its just the traversal |
| 20:54.51 | vasc | rt_shootray |
| 20:55.02 | vasc | the abstraction it uses is getting in the way of doing this like i want |
| 20:55.09 | vasc | abstraction(s) |
| 20:56.48 | vasc | i'll just #if 0 a huge chunk out and reimplement it |
| 20:57.15 | Stragus | I have no authority to advise on the direction of BRL-CAD's source, but my opinion is that all this must be rewritten |
| 20:57.28 | vasc | yeah it needs to eventually |
| 20:57.33 | vasc | or it won't run fast in OpenCL |
| 20:57.52 | Stragus | Or with SSE/AVX/CUDA or any modern and future parallel hardware |
| 20:58.00 | vasc | my problem is i'm going to have to make the code a lot different and i didn't want to |
| 20:58.28 | Notify | 03BRL-CAD:lbutler * 65651 (brlcad/branches/embree/src/ert/ert.cxx brlcad/branches/embree/src/librt/shoot.c): starting to build partitions on embree constructed segs |
| 20:58.47 | vasc | i wanted to be able to put these little pieces of opencl here and there and eventually do everything in the rendering part in opencl |
| 20:59.08 | vasc | without losing functionality |
| 20:59.29 | vasc | but i need to simplify some things in the beginning or i'll never finish it :) |
| 20:59.33 | Stragus | That code is terribly NOT designed for OpenCL |
| 20:59.39 | vasc | yes |
| 20:59.44 | Notify | 03BRL-CAD:lbutler * 65652 brlcad/branches/embree/src/librt/shoot.c: backing out changes to shoot.c that were readability |
| 20:59.44 | vasc | it's bad in several ways |
| 21:00.11 | vasc | the worst issue is too much dynamic memory allocation |
| 21:00.13 | Stragus | I have written a lot of CUDA, same hardware, and that is terrible |
| 21:00.41 | Stragus | That's probably the worst, of many terrible issues |
| 21:00.50 | vasc | yeah its like i said it made sense at the time i guess |
| 21:01.02 | Stragus | On 1985 machines, yeah |
| 21:01.11 | vasc | people sometimes forget |
| 21:01.17 | vasc | back then the memory wall wasn't as much of an issue |
| 21:01.34 | Stragus | Memory was fast, computations were slow |
| 21:01.35 | vasc | so all this memory allocation and accesses and shit made sense |
| 21:01.38 | vasc | but now it doesn't |
| 21:02.05 | Stragus | Modern hardware has very strict requirements for memory coherency access if you want good performance |
| 21:02.09 | Stragus | And *especially* GPUs |
| 21:02.40 | Stragus | You really need to rewrite everything for OpenCL |
| 21:02.44 | vasc | yes |
| 21:02.50 | vasc | but i need to work in steps |
| 21:03.03 | Stragus | Support just one primitive type |
| 21:03.06 | vasc | i want to at least understand minimally what i'm replacing |
| 21:03.31 | vasc | yeah that will be done later |
| 21:03.33 | vasc | well |
| 21:03.40 | vasc | i already did the intersection routines for a couple of them |
| 21:03.55 | vasc | now i was trying to do the traversal |
| 21:04.10 | Stragus | And you are stuck at the hit/segment buffering I would assume |
| 21:04.12 | vasc | all of this is suboptimal as i'm calling the kernels way too often and they don't do enough work |
| 21:04.30 | vasc | i'm just trying to simplify the existing code |
| 21:04.33 | Stragus | Woah woah... how so? A single kernel should trace the whole ray |
| 21:04.40 | vasc | into clean ANSI C that can actually be ported |
| 21:04.48 | vasc | yeah |
| 21:04.53 | vasc | but it doesn't yet. |
| 21:05.14 | vasc | i'm just trying to clean the layers of lasagna right now |
| 21:05.19 | Stragus | Are you allowed to change the "interface"? |
| 21:05.21 | vasc | to the bone |
| 21:05.36 | vasc | welll |
| 21:05.57 | Stragus | My CUDA raytracer obviously supports multi-hit traversal, but it returns each hit to a CUDA inlined "callback", letting the user whatever he wants with that hit (buffering, immediate processing, etc.) |
| 21:06.12 | vasc | that makes sense |
| 21:06.14 | Stragus | Which is a lot more convenient on GPU hardware than trying to dynamically accumulate a bunch of hits, which may not even be required! |
| 21:06.27 | vasc | yeah this one is a bit messed up |
| 21:06.32 | Stragus | But obviously, librt/shoot.c wasn't designed that way at all |
| 21:06.36 | vasc | yep |
| 21:06.43 | vasc | that was my second step after this |
| 21:06.51 | vasc | trying to change that |
| 21:07.03 | vasc | the callback is a good idea |
| 21:07.13 | Stragus | The inlined callback is also extremely efficient, results are processed immediately |
| 21:07.40 | Stragus | The user can output pixels on an OpenGL texture right there if he wants, no temporary storage of anything in global memory |
| 21:07.53 | vasc | i'm just trying to implement a grid acceleration structure in ANSI C and then i'll port it to OpenCL |
| 21:08.08 | vasc | coz its simple |
| 21:08.17 | Stragus | Well... I wouldn't recommend a grid |
| 21:08.20 | vasc | i know |
| 21:08.22 | vasc | but its a start |
| 21:08.28 | vasc | the structure itself isn't the big deal |
| 21:08.44 | vasc | its just so we'll have something |
| 21:08.46 | Stragus | It's not an ambitious start, but okay |
| 21:08.52 | vasc | yeah i know |
| 21:09.25 | vasc | i'm already building it |
| 21:09.29 | vasc | i'm just not traversing it |
| 21:09.40 | vasc | so it isn't being used yet |
| 21:09.50 | vasc | i could implement a bvh |
| 21:09.57 | vasc | but the main problems aren't things like this |
| 21:10.05 | vasc | it will be the multi-hit processing and the rendering loop |
| 21:10.13 | vasc | i wanna focus on that and not the accel structure |
| 21:10.14 | Stragus | I agree that scene traversal isn't that critical for CSG geometry |
| 21:10.34 | Stragus | You have few objects and they are very complex, completely the other way from triangle raytracing (which I what I did) |
| 21:10.35 | vasc | it should be if the model is complex enough |
| 21:10.49 | vasc | yeah i know |
| 21:10.51 | vasc | well |
| 21:11.02 | vasc | like we say rome wasn't built in a day |
| 21:11.28 | Stragus | I also expect that a grid will make your OpenCL wrap coherency break up, when it shouldn't have to |
| 21:11.36 | vasc | hm? |
| 21:11.46 | Stragus | Well, or whatever a CUDA "wrap" is called in OpenCL talk |
| 21:12.01 | vasc | i think i understand |
| 21:12.08 | vasc | you mean the traversal won't be memory coherent |
| 21:12.23 | Stragus | Right, while it could be with a better acceleration structure |
| 21:12.36 | vasc | there are ways around that you know. but i'm not going to optimize that. |
| 21:12.44 | vasc | i'll give you an example. |
| 21:12.54 | vasc | chess programs don't store the board in just one orientation. |
| 21:13.28 | vasc | you you could store the grid in multiple orientation and pick the one that best matches the orientation of the ray |
| 21:13.32 | vasc | which is messed up |
| 21:13.37 | vasc | anyway |
| 21:13.41 | vasc | i'm just digressing here |
| 21:14.02 | vasc | if it becomes an issue |
| 21:14.07 | vasc | i'll just do a bvh or whatever |
| 21:14.15 | Stragus | Right, focus on the bigger problems first, the multi-hit thing |
| 21:14.15 | vasc | right now we have a lot bigger issues... |
| 21:15.00 | Stragus | likes solving all problems at once, having planned a complete solution, before writing any code |
| 21:15.23 | vasc | well that works great. |
| 21:15.40 | vasc | except when the whole problem doesn't fit into the head easily or isn't easily compreensible |
| 21:15.52 | vasc | sometimes its easier to chop things up first and then think it over |
| 21:16.13 | Stragus | I still then prefer to spend a few days on it, but you'll know what works best for you |
| 21:16.31 | vasc | i've tried that for much of the last week and went nowhere so... |
| 21:16.38 | Stragus | Got it. :D |
| 21:18.42 | vasc | it seems kind of like a waste of time, or how it could be better starting off a blank sheet but... |
| 21:18.52 | vasc | i've a similar experience before on a different codebase |
| 21:18.59 | vasc | had a |
| 21:19.37 | vasc | rewriting existing code to match existing code can be a great way of learning how the code works |
| 21:19.44 | vasc | rewriting code |
| 21:19.45 | Stragus | Sure, that works |
| 21:20.06 | vasc | i would rather not need to do it but that's how this one is |
| 21:24.31 | vasc | man this is messed up |
| 21:25.33 | vasc | seems there's some guy working on embree right? |
| 21:27.13 | vasc | last time i checked it didn't seem to do enough though... |
| 21:27.16 | Stragus | I have only noticed the commit logs here as you have |
| 21:27.20 | vasc | i actually considered basing mine on that |
| 21:30.45 | vasc | ohhh |
| 21:30.47 | vasc | snap |
| 21:31.26 | vasc | so its like |
| 21:31.34 | vasc | each cell has a list of solids i.e. objects |
| 21:31.36 | vasc | but |
| 21:31.40 | vasc | it also has a list of pieces |
| 21:31.53 | vasc | which is an indirect numeric array into the list of solids |
| 21:32.03 | vasc | which also has its own cached list of the same solids |
| 21:34.25 | vasc | or whatever |
| 21:35.58 | vasc | or is this to support complex solids which have smaller things inside like a mesh which ends in different grid cells and this way we can cache which parts of the mesh are in which cell? |
| 21:36.00 | vasc | ah well |
| 21:36.43 | Stragus | can't help with librt's internal guts |
| 21:53.43 | vasc | yeah it seems to be that |
| 21:53.51 | vasc | like 'bot' bag of triangles has pieces |
| 21:53.55 | vasc | while a sphere doesn't |
| 21:54.23 | vasc | this is an interesting optimization |
| 21:54.37 | vasc | but it makes the code more complicated |
| 21:56.08 | vasc | in fact only "bot" and "ars" use this functionality... |
| 21:56.42 | vasc | arbitrary faceted solid |
| 21:57.11 | vasc | so |
| 21:57.17 | vasc | what i thought was the general case of the code |
| 21:57.24 | vasc | is actually a corner case on used for meta-objects |
| 21:57.28 | vasc | pfeh |
| 21:57.36 | vasc | only used |
| 22:00.12 | vasc | ok now this seems more doable |
| 22:00.54 | vasc | i'll have to think if i'll implement the pieces optimization like the old rendering code does or some different way |
| 22:01.47 | Stragus | Better consider how this could be more efficient on synchroneous parallel hardware |
| 22:01.54 | vasc | well |
| 22:02.10 | vasc | the idea is if you have a bag of triangles and you're gonna put it in a grid or whatever |
| 22:02.37 | vasc | you need some way to say which triangles in the bag of triangles are in each cell of you'll end up intersecting all that are in the bot |
| 22:02.39 | vasc | again and again |
| 22:02.52 | Stragus | Certainly |
| 22:03.01 | Stragus | But that's a single-thread consideration as well |
| 22:03.05 | vasc | the way i do this in my raytracer is that i just store triangles or whatever in a flat hierarchy |
| 22:03.13 | vasc | shallow |
| 22:03.31 | vasc | so i don't encapsulate |
| 22:04.00 | vasc | now the question is which approach is better |
| 22:04.29 | vasc | if say |
| 22:04.43 | vasc | there's a routine that wants to know which object id is closest to the ray or whatever |
| 22:05.02 | vasc | you wanna be able to know the id of the bot of the triangle not some triangle id |
| 22:05.13 | vasc | i'll think that some other day |
| 22:05.19 | vasc | but yes this isn't mt related |
| 22:05.27 | Stragus | Each triangle needs an identifier of some sort |
| 22:06.26 | Stragus | By knowing to which "bot" the triangle belongs, you can find the index of that triangle by subtracting its pointer from the base pointer of the bot |
| 22:06.27 | vasc | yeah but librt doesn't store triangles it store meshes |
| 22:06.34 | Stragus | Assuming all triangles are tightly packed, which they should be |
| 22:07.06 | vasc | yeah |
| 22:08.25 | Stragus | You say librt doesn't store triangles, it stores meshes, but surely it doesn't test every triangle? |
| 22:08.49 | Stragus | There must be some kind of acceleration structure, either within a mesh or incorporated in the scene mesh... |
| 22:09.01 | Stragus | ... in the scene graph* |
| 22:09.09 | vasc | a bot is a mesh |
| 22:09.11 | vasc | basically |
| 22:09.20 | vasc | yeah |
| 22:09.24 | vasc | that it does is like this |
| 22:09.46 | vasc | the bot is a solid that has triangle pieces in it |
| 22:09.59 | vasc | and when you build the acceleration structure |
| 22:10.17 | vasc | you not only check which cells overlap each solid, you also check in which cells each piece is |
| 22:10.21 | vasc | and store that |
| 22:10.51 | Stragus | So you have a list of triangles per cell |
| 22:10.55 | vasc | yes |
| 22:11.05 | vasc | but its stored per object |
| 22:11.10 | vasc | or something |
| 22:11.38 | vasc | right now i'll just ignore the bot |
| 22:11.47 | vasc | and only support plain solids |
| 22:11.59 | vasc | but i'll need to think it over later |
| 22:12.05 | Stragus | You better plan ahead to support bots efficiently |
| 22:12.13 | vasc | yeah |
| 22:12.42 | Stragus | Don't write a bunch of code without planning the whole solution :), you don't want to have to rewrite |
| 22:12.46 | vasc | the thing is i originally thought about doing this differently than how it is |
| 22:12.57 | vasc | when i hit a mesh i just called a mesh intersection routine |
| 22:13.04 | vasc | and the mesh had its own accel structure |
| 22:13.20 | vasc | but the thing is |
| 22:13.33 | vasc | this might mess up the partitioning |
| 22:13.36 | Stragus | Why? |
| 22:13.47 | vasc | well the bot already does that |
| 22:13.59 | vasc | the bot stores the triangles in a kd-tree i think |
| 22:14.14 | vasc | so |
| 22:14.32 | vasc | i'm actually wondering what's the use in knowing which triangles are in this cell anyway |
| 22:15.24 | Stragus | Normally, you could build a better top-level acceleration structure if it includes everything, instead of more sub-acceleration-structures |
| 22:15.32 | Stragus | Doesn't make much sense with a grid though |
| 22:18.22 | vasc | src/librt/primitives/bot/tie.c |
| 22:18.43 | vasc | so the triangles mesh (bot) solid has a kd-tree inside... |
| 22:19.03 | Stragus | That kd-tree will perform better than your grid |
| 22:19.41 | vasc | yeah but its CPU ANSI C code |
| 22:21.06 | Stragus | You'll probably want code to flatten and pack these kd-tree in just a chunk of memory, no internal pointers, just offsets |
| 22:21.26 | vasc | bot support is only to be done later |
| 22:22.58 | vasc | there are a whole lot of ways to store a mesh efficiently.... |
| 22:23.17 | vasc | i don't want to hardcode something which might not be the desired one too soon |
| 22:24.14 | Stragus | In my CUDA raytracer, there are no pointers: everything (the whole graph, sectors, nodes, triangles, etc.) is stored relatively with shifted offsets |
| 22:24.46 | Stragus | It makes the whole graph just a big single chunk of memory, usable directly on both CPU and CUDA |
| 22:25.06 | Stragus | Also, offsets take a lot less memory than whole pointers (64 bits? come on) |
| 22:25.45 | Notify | 03BRL-CAD Wiki:Bhollister * 9006 /wiki/User:Bhollister/Proposal: /* Project Details */ |
| 22:25.59 | Stragus | Since everything is interleaved with shifted offsets, it's also possible to organize the internal layout to maximize caching |
| 22:26.43 | vasc | http://gamma.cs.unc.edu/RS/ |
| 22:26.46 | Stragus | It may be overkill for you, but this could be stuff worth considering |
| 22:28.10 | Stragus | also doesn't store triangle vertices in the graph |
| 22:28.58 | vasc | this is going to be more messed up since we have several primitive/solid types |
| 22:29.01 | vasc | not just triangles |
| 22:29.44 | Stragus | I know, I'm just saying this is an efficient approach, and very convenient once written (a single big chunk of memory, yay) |
| 22:30.01 | vasc | yeah |
| 22:30.13 | vasc | i once read a bvh paper by yoon that was like that |
| 22:30.21 | vasc | but i think he even stored by vertex in the bvh |
| 22:30.26 | vasc | stored the vertexes |
| 22:30.50 | Stragus | I store the triangles in the graph memory, but not the vertices (I don't use vertices) |
| 22:30.52 | vasc | in a bvh a triangle can only be in one cell |
| 22:31.34 | vasc | he compresses the bvh as well |
| 22:31.43 | vasc | with the geometry in it |
| 22:31.59 | Stragus | Haven't tried that, but it's already tightly packed with offsets taking just few bits |
| 22:32.59 | vasc | if you know the vertexes of the triangles in that cell are inside the cell bounding box |
| 22:33.21 | Stragus | That's not enough, a triangle's area can intersect a cell without the vertices being in that cell |
| 22:33.24 | vasc | you can compress the triangle vertex floats |
| 22:33.33 | vasc | not in a bvh |
| 22:33.39 | vasc | you're thinking a kd-tree |
| 22:33.42 | Stragus | Ah right, bvh sorry |
| 22:33.48 | Stragus | Not thinking kd-tree either :p |
| 22:33.55 | Stragus | I use a graph, not a hierarchy |
| 22:33.57 | vasc | well a spatial partitioning |
| 22:34.05 | vasc | a bvh is object partitioning |
| 22:34.09 | Stragus | Right. |
| 22:34.58 | Stragus | Compressing vertices is an interesting idea. I store triangle edge planes, so that wouldn't work there |
| 22:36.27 | vasc | he also compresses the bounding boxes in the bvh |
| 22:36.43 | *** join/#brlcad bhollister (~behollis@dhcp-59-221.cse.ucsc.edu) |
| 22:37.09 | vasc | its like the bounding boxes of the leafs are inside those of the parent node and so on |
| 22:37.13 | vasc | so you don't need full precision |
| 22:37.19 | Stragus | nods |
| 22:37.51 | Notify | 03BRL-CAD Wiki:Bhollister * 9008 /wiki/MGED_CMD_nmg: |
| 22:39.03 | *** join/#brlcad ih8sum3r (~deepak@122.173.51.91) |
| 22:44.38 | Notify | 03BRL-CAD Wiki:Konrado DJ * 9009 /wiki/User:Konrado_DJ/GSoc2015/logs: /* 15 JULY 2015 */ |
| 22:45.42 | *** join/#brlcad ih8sum3r (~deepak@122.173.51.91) |
| 22:51.50 | Notify | 03BRL-CAD Wiki:Bhollister * 9010 /wiki/MGED_CMD_nmg: /* Argument(s) */ |
| 22:56.12 | *** join/#brlcad ih8sum3r_ (~ih8sum3r@122.173.51.91) |
| 22:56.12 | *** part/#brlcad ih8sum3r_ (~ih8sum3r@122.173.51.91) |
| 23:24.34 | vasc | well it compiled |
| 23:25.01 | vasc | and it seems to work. what a miracle |
| 23:25.56 | vasc | seems too good to be true. i'll comment the intersection to see if it still renders the scene or not |
| 23:27.06 | vasc | man |
| 23:27.09 | vasc | it really works |
| 23:29.13 | Stragus | Cool :) |
| 23:30.33 | vasc | it simplified the traversal code a whole lot |
| 23:30.38 | vasc | now only the weaving is complicated |
| 23:30.47 | vasc | only regression is it can't process bots |
| 23:31.10 | Notify | 03BRL-CAD Wiki:Bhollister * 9011 /wiki/MGED_CMD_nmg: /* Subcommands(s) */ |
| 23:31.33 | Notify | 03BRL-CAD Wiki:Bhollister * 9012 /wiki/MGED_CMD_nmg: |
| 23:32.51 | Notify | 03BRL-CAD Wiki:Bhollister * 9013 /wiki/MGED_CMD_nmg: /* See Also */ |
| 23:33.35 | vasc | i would like having more complex scenes to test this with though |
| 23:33.41 | vasc | my test scene has only one solid in it... |
| 23:33.43 | Notify | 03BRL-CAD Wiki:Bhollister * 9014 /wiki/MGED_CMD_nmg: /* Proposed subcommands(s) */ |
| 23:34.27 | Notify | 03BRL-CAD Wiki:Bhollister * 9015 /wiki/MGED_CMD_nmg: |
| 23:35.52 | Notify | 03BRL-CAD:starseeker * 65653 brlcad/trunk/src/libbrep/shape_recognition.cpp: This test was known to be insufficient/incorrect from the outset - it's going to take a raytracing based approach to resolve this question generally. Will have to punt and return the to-be-evaluated cases in a struct, so bu_ptbl won't cut it as a return type either. |
| 23:37.26 | Notify | 03BRL-CAD Wiki:Bhollister * 9016 /wiki/User:Bhollister/Proposal: /* Project Schedule */ |
| 23:38.34 | vasc | tomorrow i'll work on doing the grid construction on the gpu instead |
| 23:38.59 | Stragus | That doesn't sound necessary |
| 23:39.40 | Stragus | It should be a relatively fast operation, considering CSG has fewer objects than triangles meshes |
| 23:39.41 | vasc | its kewl to have |
| 23:39.53 | Stragus | Sure. But raytracing is probably more critical |
| 23:40.25 | vasc | maybe i'll reuse the grid code for the meshes |
| 23:41.18 | vasc | the major next step actually |
| 23:41.33 | vasc | is going to be doing the multi-hit code and the boolean weaving a lot simpler |
| 23:41.37 | vasc | so that it can be ported to the gpu |
| 23:41.44 | vasc | and other little things |
| 23:41.50 | vasc | like supporting multiple solid types |
| 23:41.58 | vasc | copying the solid data to the gpu |
| 23:42.00 | vasc | etc |
| 23:42.19 | vasc | then there's little nagging details... |
| 23:42.20 | vasc | like |
| 23:42.41 | vasc | what if i have a primitive type that doesn't have a gpu render code yet |
| 23:42.43 | Stragus | Multi-hit buffering? |
| 23:42.53 | vasc | do i draw nothing or split the database or what |
| 23:43.08 | vasc | you said callbacks were better right? |
| 23:43.14 | vasc | the current code uses these double linked lists |
| 23:43.19 | Stragus | Yes, but I wonder how compatible that would be with the rest of the code base |
| 23:43.23 | vasc | dynamic linked lists |
| 23:43.27 | Stragus | Yes, don't do that on the GPU |
| 23:43.37 | Stragus | You really shouldn't do that on the CPU either |
| 23:43.42 | vasc | no kidding |
| 23:44.10 | vasc | https://sourceforge.net/p/brlcad/patches/_discuss/thread/60701e92/d48f/attachment/m4.patch |
| 23:44.26 | Stragus | I expect most code calling the raytracer at the moment will expect a list of hits |
| 23:44.38 | Stragus | So either that code gets ported to GPU to process hits as they come in the inlined callback... |
| 23:44.51 | Stragus | Or ... ... or it gets really messy |
| 23:45.15 | vasc | that's why i'm not doing any opencl programming until i get a simple ansi c code in the gpu that can be easily ported |
| 23:45.22 | vasc | in the cpui |
| 23:45.40 | vasc | so |
| 23:46.13 | vasc | after i build the grid on the gpu as i planned i'll work on a callback version of multi-hit and boolean weaving |
| 23:46.34 | vasc | in ansi c |
| 23:47.01 | Notify | 03BRL-CAD:starseeker * 65654 brlcad/trunk/src/libbrep/shape_recognition.cpp: This'll be a job - has to be done in libged land (or possibly libanalyze/librt) but make some notes for now on how we'll have to go at it. |
| 23:47.16 | vasc | the code for multi-hit is a real mess |
| 23:47.55 | Stragus | It would be disastrous to try to buffer multiple hits per ray on the GPU then try to return that to CPU code |
| 23:48.09 | Stragus | Everything must go on the GPU, instant inlined processing |
| 23:49.09 | vasc | in the long run yeah |
| 23:49.30 | vasc | the current opencl implementation as it is on svn basically calls a kernel on each solid intersection |
| 23:49.32 | vasc | it's that bad |
| 23:49.39 | Stragus | What! |
| 23:49.43 | vasc | yeah |
| 23:49.52 | Stragus | o.O |
| 23:50.19 | vasc | see there's a lot of room for improvement |
| 23:50.36 | vasc | what i'm doing is i'm doing a simple ANSI C rendering pipeline |
| 23:50.39 | vasc | for everything |
| 23:50.43 | vasc | which i'll port to opencl |
| 23:50.56 | vasc | none of my work has been commited yet |
| 23:51.29 | vasc | i loaded the ktank.g file |
| 23:51.39 | vasc | but how to render this thing inside mged... |
| 23:54.00 | vasc | seems to work |
| 23:54.17 | vasc | so it can render scenes with more than one solid in it |
| 23:54.18 | vasc | great |
| 23:54.38 | Notify | 03BRL-CAD Wiki:Bhollister * 9017 /wiki/MGED_CMD_nmg: /* Example(s) */ |
| 23:56.16 | vasc | it can also render bigger scenes but it takes forever |
| 23:59.16 | Notify | 03BRL-CAD Wiki:85.246.100.5 * 9018 /wiki/User:Vasco.costa/GSoC15/logs: |
| 23:59.16 | vasc | so any suggestions on how to store the solid database in GPU RAM? |
| 23:59.16 | vasc | i have an idea but its gonna do a lot of cache misses |
| 23:59.43 | Stragus | A single big chunk of memory, all packed, no pointers, based on offsets, with nearby geometry stored close |
| 23:59.58 | Stragus | The single big chunk of memory also makes it possible to fetch the data as a texture |
