| 00:01.44 | vasc | yeah. the simt model helped tremendously with that |
| 00:01.59 | vasc | coz it maps good to simd and mimd |
| 00:01.59 | Stragus | True, it's a lot more flexible than SIMD |
| 00:02.05 | vasc | yeah and that |
| 00:02.13 | vasc | simd programming is so cumbersome |
| 00:02.30 | vasc | its like trying to fight with one hand on your back |
| 00:02.51 | Stragus | Depends how you see it. :) I like telling the compiler which instructions to use exactly |
| 00:03.08 | vasc | well its not like opencl doesn't have vector instructions |
| 00:03.14 | Stragus | But I agree OpenCL/CUDA style SIMT is a lot more convenient |
| 00:03.34 | vasc | it doesn't have all of them but |
| 00:04.21 | Stragus | Nvidia hardware doesn't have any per-lane vector instructions, besides read/write 64 bits (which is somewhat a float2 operation) |
| 00:04.39 | Stragus | I think AMD is the same |
| 00:05.38 | vasc | i think amd is more mixed |
| 00:05.54 | vasc | it's kinda like an array of VLIW processors |
| 00:06.22 | vasc | oh |
| 00:06.25 | Stragus | Mmhm, perhaps. I don't have much experience with AMD |
| 00:06.37 | vasc | or an array of SIMD ones depending on the architecture |
| 00:06.43 | vasc | well i don't have one of their gpus either |
| 00:06.50 | vasc | i read it somewhere |
| 00:07.28 | Stragus | So they have parallelism per SIMT lane and SIMD within the lanes themselves? |
| 00:07.59 | Stragus | Seems like... a little too intense, how to allocate their transistor budget |
| 00:10.06 | vasc | can't find it |
| 00:10.34 | vasc | i had some slides with a diagram |
| 00:11.00 | Stragus | It just seems like a lot of transistors dedicated to SIMD on top of the SIMT parallelism |
| 00:11.25 | vasc | http://www.slideshare.net/DevCentralAMD/gs4106-the-amd-gcn-architecture-a-crash-course-by-layla-mah |
| 00:11.53 | vasc | 5-element VLIW |
| 00:12.24 | vasc | and now its 4-element VLIW |
| 00:13.46 | Stragus | Okay, so it's not SIMD, just many instructions packed together |
| 00:14.04 | vasc | ah crap that was the old arch |
| 00:14.15 | vasc | GCN is on slide 19 |
| 00:14.39 | vasc | and 20 |
| 00:14.44 | vasc | 4x SIMD-16 units |
| 00:15.14 | vasc | each SIMD-16 unit has a 16-lane vector ALU |
| 00:15.33 | Stragus | So it's 16-wide SIMD |
| 00:15.55 | vasc | kinda like larabee but without the x86 baggage i guess |
| 00:16.19 | Stragus | Given that it's a GPU, it's probably a lot more flexible than x86 SIMD |
| 00:16.29 | vasc | it also has a dedicated local memory |
| 00:16.35 | Stragus | x86, Larabee, Xeon Phi, it's all terrible |
| 00:16.47 | vasc | so in that arch _local is prolly useful. |
| 00:16.52 | Stragus | Same as CUDA, it's basically a software-managed L1 cache |
| 00:17.09 | vasc | no it has an L1 cache in addition to that |
| 00:17.14 | vasc | see slide 19 |
| 00:17.40 | vasc | kinda interesting |
| 00:17.42 | Stragus | I know, I know |
| 00:18.10 | Stragus | Shared/local memory is still some very fast on-chip memory, the closest GPU equivalent to a CPU L1 cache |
| 00:18.14 | vasc | it even has a scalar unit |
| 00:18.34 | vasc | well the difference is that i don't need to manage an L1 cache |
| 00:18.41 | vasc | as much |
| 00:19.32 | Stragus | It's better when managed by software :p |
| 00:19.58 | Stragus | Nvidia Fermi had excellent L1/L2 cache, the automated caches became all crappy after that |
| 00:20.31 | Stragus | Kepler and Maxwell have a great read-only texture cache though |
| 00:21.49 | Stragus | AMD's local memory even has the same bank conflicts as Nvidia CUDA shared memory |
| 00:23.07 | vasc | the problem with amd as usual is the software |
| 00:23.39 | vasc | their drivers stink |
| 00:23.53 | Stragus | That's very polite |
| 00:23.53 | vasc | i actually liked their opencl cpu compiler |
| 00:24.41 | vasc | one issue, or so i heard, was that because they had no binary compat like nvidia they constantly needed to rewrite the driver code |
| 00:24.53 | vasc | and they don't have a lot of resources to begin with |
| 00:25.15 | Stragus | I wish they would focus a little more on their CPUs |
| 00:25.16 | vasc | the cpu guys don't have those issues |
| 00:25.26 | vasc | well they're in dire straits |
| 00:25.33 | Stragus | I know :( |
| 00:25.35 | vasc | if it wasn't for the console win they would be dead now |
| 00:25.59 | vasc | ibm's going out of the market totally |
| 00:26.01 | Stragus | I plan on upgrading AMD in about a month, dual Opteron 6370P |
| 00:26.15 | vasc | i have a piledriver |
| 00:26.21 | vasc | amd fx-8350 or something |
| 00:26.40 | Stragus | They haven't made any new FX chip for a while |
| 00:27.03 | vasc | yeah i think there was like one speed bump after that and that was it |
| 00:27.11 | vasc | and i bought it a looong time ago years ago |
| 00:27.24 | vasc | when it came out |
| 00:27.29 | Stragus | I'm really sad, I have always like AMD since the Athlon XP |
| 00:27.49 | vasc | they did too many management mistakes |
| 00:27.50 | Stragus | 3dnow! was great, and they had fast big number arithmetics and other things that were terrible on Intel |
| 00:27.54 | vasc | they didn't handle their resources well |
| 00:28.24 | vasc | the ati buy was a real mistake |
| 00:28.33 | vasc | it drained them of all the cash they had |
| 00:29.09 | Stragus | Most low-end laptops now run AMD CPU+GPU, at least they got that |
| 00:29.09 | vasc | hector ruiz basically took a company that was finally doing ok and brought it to its knees |
| 00:29.17 | vasc | that and the consoles |
| 00:29.24 | vasc | its the same arch i think |
| 00:29.25 | vasc | jaguar |
| 00:29.30 | vasc | or is it zen now |
| 00:29.38 | Stragus | Their NUMA Opterons were/are great machines at an excellent prices |
| 00:30.09 | Stragus | Come on, 32 cores for $1400, try getting that with Intel |
| 00:30.16 | vasc | yeah. not a lot of processor with cheap large socket count like that |
| 00:30.18 | vasc | and that |
| 00:30.28 | vasc | losing their fabs cost them big time |
| 00:31.03 | vasc | they probably thought it was a good idea because TSMC was executing so well |
| 00:31.08 | vasc | WAS until they slipped |
| 00:31.36 | vasc | intel has too much of a process advantage right now |
| 00:31.55 | Stragus | Intel has slightly higher performance for 2.5x the cost |
| 00:32.12 | Stragus | I don't understand people don't go more for AMD chips |
| 00:32.22 | vasc | well right now the amd chips really suck |
| 00:32.50 | Stragus | Opterons 63xx are okay |
| 00:33.30 | Stragus | In fact, they are faster than Intel chips *if* you are running NUMA-aware code able to allocate memory for each core in its own specific NUMA bank, with threads locked to the cores |
| 00:33.39 | Stragus | But very little software does that |
| 00:34.46 | vasc | 32nm |
| 00:35.22 | vasc | that's at least two processes behind intel |
| 00:36.07 | vasc | so its like they are using 4 years older fabs |
| 00:36.19 | Stragus | The chips still perform well, so the design is probably fairly good |
| 00:37.21 | Stragus | Some two years ago, I benchmarked Opteron 63xx against the latest Intel with NUMA-aware code and AMD was faster |
| 00:37.37 | Stragus | Except AMD hasn't produced anything new since then |
| 00:37.50 | Stragus | (32 cores in both cases) |
| 00:38.03 | vasc | which kind of code? |
| 00:38.19 | vasc | int, fp? |
| 00:38.37 | Stragus | Mostly floating point |
| 00:38.47 | vasc | seems weird |
| 00:38.49 | Stragus | Consuming a lot of memory bandwidth too |
| 00:39.03 | vasc | i think haswell has a wider simd unit |
| 00:39.28 | Stragus | The code was only SSE, no AVX |
| 00:39.33 | vasc | oh ok |
| 00:41.24 | Stragus | AVX is really bothersome sometimes |
| 00:41.51 | Stragus | You can do shuffles... but only within the upper and lower 128 bits "lanes", and all other kind of weird stuff limited within 128 bits lanes |
| 00:42.05 | Stragus | It's really awkward to write good AVX, the instruction set is messed up |
| 00:43.21 | vasc | that's one reason why i went opencl |
| 00:43.26 | vasc | the constant ISA changes |
| 00:43.51 | Stragus | It's still good to know what the hardware can do, or you'll generate terribly slow AVX code without knowing it |
| 00:44.08 | vasc | DLXV was a lot nicer. |
| 00:44.12 | vasc | classical vector. |
| 00:45.56 | Stragus | I wonder what OpenCL does if you have a 8 floats AVX vector and you want to shuffle float [0] with [7] |
| 00:46.07 | Stragus | Or can you even do that in OpenCL?... |
| 00:48.03 | vasc | i think so |
| 00:48.08 | vasc | there's a float8 type |
| 00:48.20 | Stragus | No, a shuffle between lanes of the same wavefront |
| 00:48.28 | *** join/#brlcad gurwinder (~chatzilla@59.91.119.36) |
| 00:49.52 | vasc | there's a shuffle() and shuffle2() instruction |
| 00:50.22 | vasc | i think you can't do comms in the same lane in opencl like that |
| 00:53.24 | vasc | CUDA has some instructions but i think opencl doesn't |
| 00:54.19 | Stragus | Right... so you can't use CUDA shuffles, nor SSE/AVX shuffles and so on |
| 00:54.27 | Stragus | OpenCL is a little limited on certain things |
| 00:55.46 | vasc | the thing that really annoys me is the opencl texture support. it's crap. |
| 00:56.02 | Stragus | What's missing? |
| 00:56.09 | vasc | no mipmaps for one |
| 00:56.11 | Stragus | In CUDA, we don't have compressed textures and some other things |
| 00:56.16 | Stragus | Ouch |
| 00:56.46 | vasc | there's an extension now |
| 00:56.59 | vasc | but at the rate nvidia updates their opencl implementation maybe we'll have it in a decade or two |
| 00:58.33 | Stragus | Eh, they want to promote CUDA first |
| 00:59.08 | Stragus | Where you can do a trilinear mipmapped lookup into a seamless cubic texture, by the way :p |
| 00:59.12 | vasc | only intel and amd are serious about opencl |
| 00:59.20 | Stragus | cube* texture |
| 00:59.20 | vasc | that's nice |
| 00:59.38 | vasc | do they have bitmaps which are real bitmaps instead of bytemaps? |
| 01:00.03 | Stragus | Bitmaps? Bit maps? |
| 01:00.09 | vasc | yeah |
| 01:00.16 | Stragus | Not quite following what you mean |
| 01:00.21 | vasc | 1 bit per pixel |
| 01:00.25 | vasc | instead of 8 bits |
| 01:00.50 | Stragus | It's not a format supposed by the hardware |
| 01:00.53 | vasc | see |
| 01:01.00 | vasc | i did my own implementation of that |
| 01:01.16 | vasc | in cuda |
| 01:01.22 | Stragus | Of course, but the hardware texturing logic doesn't do 1 bit textures |
| 01:01.32 | vasc | it's a shame though i could use that |
| 01:01.53 | vasc | mipmapped 1 bit per pixel 3d textures with my own filtering function |
| 01:02.33 | Stragus | That's nice, the hardware texturing is fast but it has some limitations |
| 01:02.52 | Stragus | Although it does support a wide range of very useful formats, like RGBA 10,10,10,2 |
| 01:03.02 | Stragus | Which is fantastic to store 3D vectors |
| 01:13.22 | Notify | 03BRL-CAD:starseeker * 65737 brlcad/trunk/src/librt/db_tree.c: Make sure rt_uniresource is initialized before using it |
| 01:57.56 | Notify | 03BRL-CAD:starseeker * 65738 (brlcad/trunk/include/analyze.h brlcad/trunk/src/libanalyze/find_subtracted_shapes.cpp brlcad/trunk/src/libged/shape_recognition.cpp): Back up to the last point that didn't crash. |
| 02:05.32 | Notify | 03BRL-CAD:starseeker * 65739 brlcad/trunk/src/libged/shape_recognition.cpp: This step doesn't seem to cause problems... |
| 02:26.27 | vasc | blech |
| 02:26.42 | vasc | the quartic solver is annoyingly codey |
| 02:29.57 | Stragus | I assumed it would mostly be copy/paste to OpenCL |
| 02:30.21 | vasc | kind of. |
| 02:30.27 | vasc | but it's branchy like heck. |
| 02:31.09 | Stragus | Eh yes, that could be optimized for SIMT hardware |
| 02:33.07 | vasc | BRL-CAD uses this generic solver for up to 6th order polys |
| 02:33.20 | vasc | and for some reason the torus intersector uses that code |
| 02:33.34 | vasc | it may be that it has extra checks for weird polys |
| 02:33.44 | vasc | but it's still annoying like heck |
| 02:35.00 | vasc | like if you have lots of zeros then it uses the cubic solver. or the quadratic solver. etc |
| 02:35.08 | vasc | branch and branch and branch |
| 02:35.53 | vasc | BAH |
| 02:36.00 | vasc | i'll just use the quadratic solver |
| 02:36.06 | vasc | quartic |
| 02:36.35 | vasc | and you know which is the primitive that uses 6th order polys? |
| 02:36.38 | vasc | the HEART primitive |
| 02:36.52 | Stragus | Ahah! |
| 02:36.58 | vasc | so we have a 6th order solver just because of that |
| 02:37.39 | vasc | bangs his head with a hammer |
| 02:37.50 | Stragus | Having all primitives use the same solver code can be useful for incoherent rays |
| 02:38.02 | Stragus | But if they are coherent, you would be much better off with optimized code for each primitive |
| 02:38.09 | vasc | well ya know |
| 02:38.35 | vasc | this thing supports more than implicits |
| 02:38.51 | vasc | and the sphere and ellipsoid actually use the quadratic solver instead of the general one |
| 02:39.28 | vasc | for some reason no one uses the quartic solver directly |
| 02:39.45 | vasc | its probably because of numeric instabilities |
| 02:39.48 | vasc | but lets ignore that for now |
| 02:39.54 | vasc | uses the quartic solver |
| 02:41.38 | vasc | gah |
| 02:42.02 | vasc | its like looking at the niagara falls or something |
| 02:42.07 | vasc | cascading branches again |
| 02:42.27 | Stragus | Start with copy/paste, someone can optimize that later |
| 02:44.21 | vasc | i'm doing that and some inlining |
| 02:48.13 | vasc | i feel like just doing my own based on the wolfram or wikipedia page for the quartic solver would be quicker though |
| 02:49.20 | Stragus | I wouldn't recommend that, stability can be tricky for these things |
| 02:49.49 | vasc | yeah i know |
| 02:49.59 | vasc | but i'm not gonna use the generic solver that's for sure |
| 02:50.36 | Stragus | Before using any other code, I would bombard both codes with billion of equations to detect any glitch |
| 02:50.47 | Stragus | Which is time consuming, so it's probably best to copy/paste for now |
| 02:51.46 | Notify | 03BRL-CAD:starseeker * 65740 (brlcad/trunk/include/brep.h brlcad/trunk/src/libbrep/shape_recognition.cpp and 2 others): looks like I had gummed up the name handling, and it was showing up as weird errors in the tree build... |
| 02:55.11 | vasc | bah humbug |
| 03:01.02 | Notify | 03BRL-CAD:starseeker * 65741 (brlcad/trunk/include/analyze.h brlcad/trunk/src/libanalyze/find_subtracted_shapes.cpp brlcad/trunk/src/libged/shape_recognition.cpp): switch in rt_wdb |
| 03:04.03 | vasc | good. time to start finding bugs |
| 03:21.39 | vasc | blam |
| 03:21.43 | vasc | crash |
| 03:21.52 | vasc | well that's a start |
| 03:23.11 | Stragus | How easy is OpenCL debugging? |
| 03:23.24 | vasc | it's bad |
| 03:23.42 | vasc | at least this time it didn't lock my display |
| 03:23.44 | Stragus | CUDA is slightly painful, I generally write the whole CUDA-designed code in C and pretty much copy/paste |
| 03:23.46 | vasc | computer |
| 03:23.52 | vasc | yeah |
| 03:23.54 | vasc | i do that usually |
| 03:24.02 | vasc | an ANSI C mockup and then i port it |
| 03:24.07 | Stragus | Exactly |
| 03:24.17 | Stragus | With dummy malloc/free for shared memory and stuff |
| 03:24.43 | vasc | hm this ain't working so well |
| 03:24.59 | vasc | maybe the quartic solver alone doesn't work |
| 03:25.35 | vasc | i'll try doing that in the ANSI C bit to see what happens |
| 03:25.40 | Stragus | nods |
| 03:28.43 | vasc | yeah it doesn't work either |
| 03:28.43 | vasc | great |
| 03:29.07 | vasc | the generic 6th order solver it is then |
| 03:31.25 | vasc | oh its recursive |
| 03:31.28 | vasc | now i notice that |
| 03:31.30 | vasc | hmm |
| 03:31.50 | Stragus | Damn. |
| 03:32.38 | vasc | well i think opencl supports recursionm |
| 03:33.51 | Stragus | Probably, although it's darn slow |
| 03:34.28 | vasc | ah no it ain't |
| 03:34.35 | vasc | it just calls a function with a really similar name |
| 03:38.36 | vasc | holy cascading function calls batman |
| 03:40.05 | vasc | you're in a maze of twisty passages all aline |
| 03:40.06 | vasc | alike |
| 03:40.31 | vasc | i need complex numbers as well |
| 03:40.32 | vasc | neato |
| 03:41.26 | Notify | 03BRL-CAD:starseeker * 65742 (brlcad/trunk/src/libanalyze/find_subtracted_shapes.cpp brlcad/trunk/src/libged/shape_recognition.cpp): There we go - getting what should be all the key pieces we need. Next up is a) a bbox filter for the missing gaps and b) the final decision logic. |
| 03:43.10 | Stragus | You are in a maze of twisty branches, all alike |
| 03:44.11 | starseeker | brlcad: my apologies - I was feeding in nonsense names to the combs and didn't realize it |
| 03:45.02 | starseeker | notes to self to remember that comb building does no sanity checking on names... |
| 03:47.02 | vasc | if it was the amd gpu compiler it would probably barf on this code |
| 03:48.36 | Notify | 03BRL-CAD:brlcad * 65743 brlcad/trunk/src/librt/primitives/datum/datum.c: add an arrowhead onto the tip of axes as an indicator of directionality, fix placement of the plane plots too. |
| 04:28.48 | vasc | well its working |
| 04:44.41 | Notify | 03BRL-CAD Wiki:85.246.114.172 * 9138 /wiki/User:Vasco.costa/GSoC15/logs: |
| 04:48.18 | vasc | too tired. it's the crack of dawn here. |
| 04:48.24 | vasc | see you tomorrow |
| 04:53.16 | Notify | 03BRL-CAD Wiki:85.246.114.172 * 9139 /wiki/User:Vasco.costa/GSoC15/logs: |
| 04:53.49 | Notify | 03BRL-CAD Wiki:85.246.114.172 * 9140 /wiki/User:Vasco.costa/GSoC15/logs: |
| 04:54.19 | Notify | 03BRL-CAD Wiki:85.246.114.172 * 9141 /wiki/User:Vasco.costa/GSoC15/logs: |
| 04:56.49 | Notify | 03BRL-CAD Wiki:85.246.114.172 * 9142 /wiki/User:Vasco.costa/GSoC15/logs: |
| 04:59.53 | Notify | 03BRL-CAD Wiki:85.246.114.172 * 9143 /wiki/User:Vasco.costa/GSoC15/logs: |
| 05:01.11 | Notify | 03BRL-CAD Wiki:85.246.114.172 * 9144 /wiki/User:Vasco.costa/GSoC15/logs: |
| 05:03.13 | Notify | 03BRL-CAD Wiki:85.246.114.172 * 9145 /wiki/User:Vasco.costa/GSoC15/logs: |
| 05:07.59 | Notify | 03BRL-CAD Wiki:85.246.114.172 * 9146 /wiki/User:Vasco.costa/GSoC15/logs: |
| 05:19.49 | Notify | 03BRL-CAD:brlcad * 65744 brlcad/trunk/NEWS: libdm changes to improve the appearance of points -- actually drawing circles instead of squares -- is user visible in a variety of places, most notably the point cloud primitive. |
| 05:32.15 | *** join/#brlcad shaina (~shaina@59.89.41.116) |
| 05:50.43 | *** join/#brlcad ries (~ries@D979C47E.cm-3-2d.dynamic.ziggo.nl) |
| 06:11.48 | Notify | 03BRL-CAD Wiki:Gurwinder Singh * 9147 /wiki/User:Gurwinder_Singh/GSoc15/log_developmen: |
| 06:13.48 | Notify | 03BRL-CAD Wiki:Gurwinder Singh * 9148 /wiki/User:Gurwinder_Singh/GSoc15/log_developmen: |
| 06:18.00 | brlcad | notes the solver Stragus and vasc were talking about is not 6th order just for heart, it's Nth order with N set at compile-time -- and it amazingly worked very stable for 6th order although having never been implemented with that in mind |
| 06:19.02 | brlcad | I tested about a half dozen different solvers available online a few years ago and brl-cad's substantially outperformed ALL of them including the venerable GMP |
| 06:20.36 | brlcad | frankly shocking result, because I was looking to replace it with a 3rd party solver lib .. assuming there would be something faster out there |
| 06:21.57 | gurwinder | brlcad: I'm working on pipe. Not able to understand bend radius. I run make pipe make it has bend radius 500 but there is no bend at all. |
| 06:22.33 | gurwinder | the pipe is strait |
| 06:23.45 | brlcad | Stragus: my comment about not caring about performance was specifically with regards to vasc's gsoc project, please don't turn that into a bigger statement than that :) |
| 06:25.08 | brlcad | dracarys983: not enough info, how are you printing the vls to the mged window? |
| 06:26.21 | brlcad | gurwinder: you got half working? |
| 06:27.14 | brlcad | gurwinder: see http://brlcad.org/wiki/Documentation principles of effective meodeling document for a pipe overview |
| 06:27.27 | gurwinder | brlcad: yes half is working well. POV-Ray support it as plane. |
| 06:28.19 | gurwinder | here is link http://www.povray.org/documentation/view/3.6.1/297/ |
| 06:29.17 | gurwinder | brlcad: I read about bend in http://brlcad.org/VolumeIII-Principles_of_Effective_Modeling.pdf |
| 06:30.15 | gurwinder | but it confuses me when I run make pipe make and it show pipe with two points and bend radius 500. |
| 06:31.08 | gurwinder | So If there are only two points so whats the meaning of bend here? |
| 06:32.04 | brlcad | you have a radius but no point around which to bend (you need a third point) |
| 07:03.01 | dracarys983 | brlcad: Using bu_vls_printf(). bu_log() works perfectly, bu_vls_printf() doesn't. |
| 07:39.11 | *** join/#brlcad teepee-- (bc5c2134@gateway/web/freenode/ip.188.92.33.52) |
| 08:07.33 | *** join/#brlcad dracarys983 (dracarys98@nat/iiit/x-tqmhgqesmhgvsphs) |
| 08:34.12 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) |
| 08:51.54 | *** join/#brlcad gurwinder (~chatzilla@59.91.119.36) |
| 09:28.38 | dracarys983 | d_rossberg: I updated the rt^3 tests patch. I sent a mail regarding the API design on mailing list. Is that design alright? |
| 09:29.01 | dracarys983 | I have implemented it in that way and volume is working now. Centroid needs the density table to be imported. It'll be done in a day. |
| 09:29.18 | dracarys983 | Surface area is next up, and then the caller functions. |
| 09:29.26 | dracarys983 | in C++ interface |
| 09:35.29 | d_rossberg | the over all design looks reasonable |
| 09:36.16 | d_rossberg | the only thing i would like to mention is that api.c doesn't contain an API but internal helper functionality |
| 09:36.52 | d_rossberg | this is a little bit confusing |
| 09:39.56 | dracarys983 | d_rossberg: Okay. I have implemented the ray shooting logic in api.c (I will change the name if it's misleading). It fills in the structures and a ray context structure. |
| 09:40.26 | dracarys983 | I pass the ray context structure to volume, centroid and surface area calculating functions in libanalyze. |
| 09:40.46 | dracarys983 | They calculate the grand totals and return the required value. |
| 09:41.14 | dracarys983 | s/ray/raytracing |
| 09:42.26 | dracarys983 | The ray shooting code is the same as that in gqa, no changes right now. |
| 09:43.23 | dracarys983 | d_rossberg: One thing I'm not able to do is print messages to MGED window using bu_vls_printf(). bu_log() works. |
| 10:50.18 | d_rossberg | as far as i can see bu_vls_printf() writes the output to a bu_vls struct, no emged window there |
| 10:52.59 | dracarys983 | Yes, I'm using a bu_vls struct to which I write using bu_vls_printf(). Now, there's ged_result_str which is a bu_vls struct and it's used to print output to MGED window. |
| 10:53.22 | dracarys983 | I've made a bu_vls struct named analyze_struct_str to do the same. Not working. |
| 11:03.34 | d_rossberg | and how do you want to write the buffer (t.e. the vls struct) to the mged window? |
| 11:04.33 | d_rossberg | ged is a structure which comes from the tcl interpreter, the ged routines write something to it, snd then the tcl interpreter will do something with it |
| 11:04.47 | dracarys983 | As I would write a string to stdout -- I want to write the string to MGED output. |
| 11:05.04 | d_rossberg | e.g. write the ger_result_str to the tcl command window |
| 11:05.30 | dracarys983 | d_rossberg: Ah, right. So it's the Tcl interpreter that writes the contents of ged_result_str to MGED window. |
| 11:05.33 | d_rossberg | do you have a handle of the mged window? |
| 11:06.11 | dracarys983 | No, I don't pass gedp. I only pass the dbip pointed to by gedp. |
| 11:07.00 | dracarys983 | If I pass the gedp, I can use gedp->ged_result_str to print to Tcl command window. |
| 11:07.10 | d_rossberg | tcl is (ideally) a layer above the kernel |
| 11:08.22 | d_rossberg | you shouldn't mix them |
| 11:09.39 | dracarys983 | d_rossberg: Hm okay. So is it possible to switch output bu_vls struct to analyze_result_str when analyze command is called? |
| 11:09.55 | dracarys983 | There's one way to avoid using bu_vls_printf() -- to use bu_log(). |
| 11:12.35 | d_rossberg | this would be the appropriate method for logging at kernel level |
| 11:14.15 | d_rossberg | btw, libraries can define debug levels (see include/rt/debug.h) |
| 11:17.30 | dracarys983 | d_rossberg: Those flags are to be assigned to RT_G_DEBUG to get debugging info, right? |
| 11:17.45 | dracarys983 | And yes, I'll switch to bu_log() then. :) |
| 11:21.43 | d_rossberg | yes, but i don't know if you want to make it that complex, but a switch to switch the libanalyze debug output on and of like in librt ... |
| 11:41.10 | *** join/#brlcad gurwinder (~chatzilla@59.91.119.36) |
| 12:49.06 | brlcad | dracarys983: bu_vls_printf() lets you use a printf-style interface to print INTO a vls, not print that vls to stdout |
| 12:50.10 | brlcad | you have to use bu_log or fprintf or printf or std::cout or write or some other standard method to write to standard out |
| 12:50.33 | brlcad | fprintf("%s\n", bu_vls_addr(&your_vls)); |
| 12:50.41 | brlcad | er, fprintf(stdout, "%s\n", bu_vls_addr(&your_vls)); |
| 13:00.08 | *** join/#brlcad ih8sum3r (~deepak@122.173.207.45) |
| 14:03.18 | *** join/#brlcad sofat (~sofat@202.164.45.212) |
| 14:11.02 | Notify | 03BRL-CAD:starseeker * 65745 brlcad/trunk/src/libanalyze/find_subtracted_shapes.cpp: Use the bbox to limit which gaps are being considered for the given candidate object. |
| 14:14.20 | Notify | 03BRL-CAD:starseeker * 65746 (brlcad/trunk/include/wdb.h brlcad/trunk/src/libwdb/reg.c): Empty strings as wmember names leads to a number of problems, including infinite loops when trees with nested empty string entries are interperted as referring to each other. Extra fun when debugging since there's no unique name handy to help identify what might be causing the problem. While we're at it, sanity check headp. |
| 14:50.01 | *** join/#brlcad sofat (~sofat@202.164.45.212) |
| 14:57.52 | *** join/#brlcad packrat (~packrator@c-71-231-32-234.hsd1.wa.comcast.net) |
| 15:01.27 | dracarys983 | brlcad: Ah, I see. Thank you. So, printing using bu_vls_printf() solved. |
| 15:27.18 | Notify | 03BRL-CAD:starseeker * 65747 brlcad/trunk/src/libanalyze/find_subtracted_shapes.cpp: Make an initial subtract/no-subtract determination. Need to refine in situations where we're getting relatively small numbers of rays. |
| 15:29.22 | *** join/#brlcad shaina (~shaina@59.89.41.116) |
| 16:14.35 | *** join/#brlcad sofat (~sofat@202.164.45.212) |
| 16:32.11 | *** join/#brlcad vasc (~vasc@bl7-121-4.dsl.telepac.pt) |
| 16:49.43 | dracarys983 | brlcad: Are there any primitives who have a NULL entry in either of ft_volume/centroid/surf_area but it's *analyze_<primitive>* function has been implemented? |
| 16:56.13 | *** join/#brlcad sofat (~sofat@202.164.45.212) |
| 17:22.08 | *** join/#brlcad bhollister2 (~brad@2601:647:cb02:7a00:6e71:d9ff:fe7c:6803) |
| 17:57.30 | *** join/#brlcad konrado (~konro@41.205.22.39) |
| 18:29.35 | *** join/#brlcad sofat (~sofat@202.164.45.204) |
| 18:59.08 | *** join/#brlcad konrado (~konro@41.205.22.58) |
| 19:01.22 | Notify | 03BRL-CAD:brlcad * 65748 brlcad/trunk/src/libdm/dm-X.c: calling BN_VLIST_DRAW_POINT should move the cursor to that position, so we don't have to explicitly call MOVE if drawing from there. |
| 19:21.26 | Notify | 03BRL-CAD:brlcad * 65749 (brlcad/trunk/TODO brlcad/trunk/src/libdm/dm-wgl.c): make sure the vlist cursor is always moved to the current point so that point drawing works as expected, but this begs for a quick test to make sure wireframes were not broken in the process if there is some statefulness implied. it should be save though as it's exactly what the ogl manager is currently doing. this brings them back closer |
| 19:21.28 | Notify | into alignment. |
| 19:21.30 | Notify | ... |
| 19:21.49 | Notify | 03BRL-CAD:brlcad * 65750 (brlcad/trunk/src/libdm/dm-X.c brlcad/trunk/src/libdm/dm-qt.cpp): we want to stash in lpnt after drawing a point |
| 19:24.53 | Notify | 03BRL-CAD:brlcad * 65751 brlcad/trunk/TODO: plot and tk are in the same boat, needing support for points |
| 19:34.55 | Notify | 03BRL-CAD:brlcad * 65752 (brlcad/trunk/TODO brlcad/trunk/src/libdm/CMakeLists.txt): separate out libdm-specific issues into a libdm README file. as our ledger has grown over the years, there are too many developer-only entries that could just as well live as comments in the code or notes in a library README file and don't really have any user-visible value for being tracked on our public TODO backlog. |
| 19:40.13 | *** join/#brlcad ries_nicked (~ries@D979C47E.cm-3-2d.dynamic.ziggo.nl) |
| 19:47.59 | Notify | 03BRL-CAD Wiki:Deekaysharma * 9149 /wiki/User:Deekaysharma/logs: |
| 20:05.14 | vasc | nope opencl doesn't support recursion |
| 20:06.36 | Stragus | Really? No "true" function calls then? |
| 20:07.09 | Notify | 03BRL-CAD:starseeker * 65753 (brlcad/trunk/src/libanalyze/find_subtracted_shapes.cpp brlcad/trunk/src/libanalyze/util.cpp): This undoubtely needs a lot of refinement, but get a subtract/no-subtract decision from the ray tracing. Need more context - for example, need to distinguish when a solid in a candidate is removing positive material it shouldn't vs. subtracting empty space. |
| 20:07.16 | Stragus | The first generation of CUDA hardware from 2008 didn't support functions either |
| 20:18.11 | ``Erik | shakes fist at 2008 via his 2008 laptop :/ |
| 20:26.31 | Notify | 03BRL-CAD:brlcad * 65754 brlcad/trunk/src/librt/primitives/datum/datum.c: big improvement on datum plane plotting, just draw a simple box in the plane with an up vector. |
| 20:27.28 | Notify | 03BRL-CAD:ejno * 65755 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: fix an issue in which WALLs between components with thin-wall cones/spheres could result in creation of nonexistent cones/spheres |
| 20:27.57 | *** join/#brlcad sofat (~sofat@202.164.45.212) |
| 20:34.49 | *** join/#brlcad Shubham (6719e766@gateway/web/freenode/ip.103.25.231.102) |
| 20:37.06 | Notify | 03BRL-CAD:brlcad * 65756 brlcad/trunk/src/libbn/mat.c: bn_vec_perp() is really jumpy and inconsistent, making it undesirable when rendering GUI elements. implementation needs to be more continuous . |
| 20:50.00 | Notify | 03BRL-CAD:brlcad * 65757 brlcad/trunk/include/vmath.h: VPROJECT() needs to swap args .. yikes. |
| 20:55.28 | Notify | 03BRL-CAD:starseeker * 65758 brlcad/trunk/src/libanalyze/find_subtracted_shapes.cpp: Add the new subtractions to the final csg definition |
| 20:57.30 | *** join/#brlcad sofat (~sofat@202.164.45.204) |
| 21:04.35 | Notify | 03BRL-CAD:starseeker * 65759 brlcad/trunk/src/libged/shape_recognition.cpp: Only do the raytracing prep when we actually need it. |
| 21:23.54 | Notify | 03BRL-CAD:starseeker * 65760 brlcad/trunk/src/librt/mkbundle.c: zeros won't work here... |
| 21:42.01 | Notify | 03BRL-CAD:starseeker * 65761 (brlcad/trunk/src/libanalyze/find_subtracted_shapes.cpp brlcad/trunk/src/libanalyze/util.cpp): avoid crashing in some error cases. |
| 21:48.00 | vasc | BTW i tried doing a rendering loop where i first compute the intersections and store the lengths of the lists, alloc, and then compute the intersections and store the intersections |
| 21:48.09 | vasc | the performance loss is like %30 |
| 21:48.19 | vasc | so i think i'll do that |
| 21:48.36 | vasc | instead of the dynamic allocation |
| 21:49.08 | vasc | doing the intersections twice doesn't make things twice slower |
| 21:49.12 | vasc | its like 30% slower |
| 21:49.22 | vasc | because a lot of time is spent on the boolean weaving |
| 21:49.37 | vasc | there's just one snag |
| 21:49.52 | vasc | because i only do boolean weaving in the end i can't do early termination |
| 21:50.02 | vasc | on the rays |
| 21:50.08 | *** join/#brlcad ries (~ries@D979C47E.cm-3-2d.dynamic.ziggo.nl) |
| 21:50.28 | vasc | so i always need to trace rays all the way |
| 21:51.05 | vasc | the performance impact would be on scenes with high depth complexity |
| 21:51.12 | Stragus | If you are going to count all hits then trace again, early termination makes no sense indeed |
| 21:51.23 | vasc | but AFAIK usually scenes don't have a lot more depth complexity than 2 or 3 anyway |
| 21:51.39 | Stragus | I think they manage fairly complex scenes :p |
| 21:52.47 | vasc | well between that kind of extra calcs and the extra mallocs |
| 21:52.55 | vasc | i kinda suspect the extra calcs win |
| 21:53.34 | vasc | 30% is a worst case btw |
| 21:53.40 | Stragus | Well... I disagree, but the other way is complex, so it's good enough for now |
| 21:54.07 | vasc | there's just one thing though |
| 21:54.34 | vasc | i plan to transfer the light of segments to the CPU and do the boolean weaving there as a temporary step |
| 21:54.42 | vasc | that's gonna suck until that gets rewritten |
| 21:55.17 | vasc | but this also means we can compute non-GPU accelerated intersections on the CPU and merge the results |
| 21:55.49 | vasc | s/light/list/g |
| 21:56.17 | vasc | back to tgc |
| 22:03.45 | Notify | 03BRL-CAD:brlcad * 65762 brlcad/trunk/src/libbn/mat.c: bail earlier on degenerate case |
| 23:15.50 | Notify | 03BRL-CAD Wiki:85.240.121.4 * 9150 /wiki/User:Vasco.costa/GSoC15/logs: |
| 23:16.09 | Notify | 03BRL-CAD Wiki:85.240.121.4 * 9151 /wiki/User:Vasco.costa/GSoC15/logs: |
| 23:18.19 | vasc | brlcad, if you apply any of my patches, apply them in this order: #341, #393 |
| 23:21.45 | Notify | 03BRL-CAD Wiki:85.240.121.4 * 9152 /wiki/User:Vasco.costa/GSoC15/logs: |
| 23:22.59 | Notify | 03BRL-CAD Wiki:85.240.121.4 * 9153 /wiki/User:Vasco.costa/GSoC15/logs: |
| 23:24.57 | Notify | 03BRL-CAD Wiki:Konrado DJ * 9154 /wiki/User:Konrado_DJ/GSoc2015/logs: /* 29 JULY 2015 */ |
| 23:28.11 | Notify | 03BRL-CAD Wiki:85.240.121.4 * 9155 /wiki/User:Vasco.costa/GSoC15/logs: |
| 23:32.55 | Notify | 03BRL-CAD Wiki:85.240.121.4 * 9156 /wiki/User:Vasco.costa/GSoC15/logs: |
| 23:34.27 | Notify | 03BRL-CAD Wiki:85.240.121.4 * 9157 /wiki/User:Vasco.costa/GSoC15/logs: |
| 23:35.14 | Notify | 03BRL-CAD Wiki:85.240.121.4 * 9158 /wiki/User:Vasco.costa/GSoC15/logs: |
| 23:45.34 | vasc | well the primitives are ported |
| 23:45.40 | Notify | 03BRL-CAD:brlcad * 65763 brlcad/trunk/src/libged/typein.c: fix a couple bugs including not validating that we got proper numeric args where expected and needing to allocate datums individually instead of as an array (as they must be released individually). |
| 23:45.53 | vasc | so we got SPH, EHY, ELL, ARB8, TOR, TGC |
| 23:48.02 | vasc | with that off time to consider how to implement the rendering architecture |
| 23:48.03 | vasc | so |
| 23:48.08 | vasc | time to write stuff on paper |
| 23:48.09 | Notify | 03BRL-CAD:brlcad * 65764 brlcad/trunk/src/librt/primitives/datum/datum.c: WIP, needing a better solution for off-angle planes as bn_vec_perp() is unstable. also fix 4 byte per datum overallocation (no harm, but wasted). |