| 00:23.15 | maths22 | starseeker: look at the new build-much better |
| 03:09.34 | *** join/#brlcad bhollister2 (~behollis@dhcp-59-221.cse.ucsc.edu) | |
| 03:22.32 | *** join/#brlcad packrat (~packrator@c-71-231-32-234.hsd1.wa.comcast.net) | |
| 03:35.31 | *** join/#brlcad packrat (~packrator@c-71-231-32-234.hsd1.wa.comcast.net) | |
| 03:40.11 | *** join/#brlcad packrat (~packrator@c-71-231-32-234.hsd1.wa.comcast.net) | |
| 03:51.13 | *** join/#brlcad packrat (~packrator@c-71-231-32-234.hsd1.wa.comcast.net) | |
| 04:06.06 | *** join/#brlcad hackrat (~packrator@c-71-231-32-234.hsd1.wa.comcast.net) | |
| 05:04.46 | *** join/#brlcad packrat (~packrator@c-71-231-32-234.hsd1.wa.comcast.net) | |
| 05:12.45 | *** join/#brlcad hackrat (~packrator@c-71-231-32-234.hsd1.wa.comcast.net) | |
| 05:14.49 | Notify | 03BRL-CAD:vasco_costa * 65964 (brlcad/branches/opencl/include/rt/shoot.h brlcad/branches/opencl/src/librt/primitives/primitive_util.c and 4 others): do the pixel pushing with opencl. |
| 05:22.36 | Notify | 03BRL-CAD:vasco_costa * 65965 (brlcad/trunk/include/rt/shoot.h brlcad/trunk/src/librt/primitives/primitive_util.c and 4 others): do heavy duty pixel pushing with the gpu. this speeds up rendering of havok around 3x on my system. |
| 05:24.19 | *** join/#brlcad packrat (~packrator@c-71-231-32-234.hsd1.wa.comcast.net) | |
| 05:25.04 | maths22 | I just redid the header at http://beta.brlcad.org/wp/ |
| 05:25.08 | maths22 | What do we think? |
| 05:42.28 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9366 /wiki/User:Vasco.costa/GSoC15/logs: /* Week 12 : 10 Aug-16 Aug */ |
| 05:43.25 | Notify | 03BRL-CAD Wiki:Vasco.costa * 0 /wiki/File:Rt_ehyn.png: |
| 05:44.24 | Notify | 03BRL-CAD Wiki:Vasco.costa * 0 /wiki/File:Cl_ehyn.png: |
| 05:44.36 | Notify | 03BRL-CAD Wiki:Vasco.costa * 0 /wiki/File:Diff_ehyn.png: |
| 05:45.31 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9370 /wiki/User:Vasco.costa/GSoC15/logs: /* Week 12 : 10 Aug-16 Aug */ |
| 05:45.53 | *** join/#brlcad packrat (~packrator@c-71-231-32-234.hsd1.wa.comcast.net) | |
| 05:54.05 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9371 /wiki/User:Vasco.costa/GSoC15/logs: /* Week 13 : 17 Aug-23 Aug */ |
| 05:54.47 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9372 /wiki/User:Vasco.costa/GSoC15/logs: /* Week 13 : 17 Aug-23 Aug */ |
| 05:55.40 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9373 /wiki/User:Vasco.costa/GSoC15/logs: /* Week 13 : 17 Aug-23 Aug */ |
| 05:56.36 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9374 /wiki/User:Vasco.costa/GSoC15/logs: /* Week 13 : 17 Aug-23 Aug */ |
| 05:57.32 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9375 /wiki/User:Vasco.costa/GSoC15/logs: /* Week 13 : 17 Aug-23 Aug */ |
| 05:57.52 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9376 /wiki/User:Vasco.costa/GSoC15/logs: /* Week 13 : 17 Aug-23 Aug */ |
| 05:58.42 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9377 /wiki/User:Vasco.costa/GSoC15/logs: /* Week 13 : 17 Aug-23 Aug */ |
| 05:59.31 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9378 /wiki/User:Vasco.costa/GSoC15/logs: /* Week 13 : 17 Aug-23 Aug */ |
| 06:03.33 | *** join/#brlcad shaina (~shaina@61.0.201.53) | |
| 06:07.48 | *** join/#brlcad packrat (~packrator@c-71-231-32-234.hsd1.wa.comcast.net) | |
| 06:21.35 | *** join/#brlcad packrat (~packrator@c-71-231-32-234.hsd1.wa.comcast.net) | |
| 06:26.18 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9379 /wiki/User:Vasco.costa/GSoC15/logs: /* Week 13 : 17 Aug-23 Aug */ |
| 06:26.51 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9380 /wiki/User:Vasco.costa/GSoC15/logs: /* Week 13 : 17 Aug-23 Aug */ |
| 06:34.39 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9381 /wiki/User:Vasco.costa/GSoC15/logs: /* Development Status */ |
| 06:35.24 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9382 /wiki/User:Vasco.costa/GSoC15/logs: /* Development Status */ |
| 06:35.47 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9383 /wiki/User:Vasco.costa/GSoC15/logs: /* Development Status */ |
| 06:37.01 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9384 /wiki/User:Vasco.costa/GSoC15/logs: /* Development Status */ |
| 06:38.40 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9385 /wiki/User:Vasco.costa/GSoC15/logs: /* Development Status */ |
| 06:39.19 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9386 /wiki/User:Vasco.costa/GSoC15/logs: /* Development Status */ |
| 06:41.44 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9387 /wiki/User:Vasco.costa/GSoC15/logs: /* Development Status */ |
| 06:45.14 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9388 /wiki/User:Vasco.costa/GSoC15/logs: /* Development Status */ |
| 07:41.34 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9389 /wiki/User:Vasco.costa/GSoC15/logs: /* Week 12 : 10 Aug-16 Aug */ |
| 07:44.35 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9390 /wiki/User:Vasco.costa/GSoC15/logs: /* Week 13 : 17 Aug-23 Aug */ |
| 07:49.53 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9391 /wiki/User:Vasco.costa/GSoC15/logs: /* Week 13 : 17 Aug-23 Aug */ |
| 07:51.27 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9392 /wiki/User:Vasco.costa/GSoC15/logs: /* Week 13 : 17 Aug-23 Aug */ |
| 07:52.00 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9393 /wiki/User:Vasco.costa/GSoC15/logs: /* Week 13 : 17 Aug-23 Aug */ |
| 07:52.46 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9394 /wiki/User:Vasco.costa/GSoC15/logs: /* Week 13 : 17 Aug-23 Aug */ |
| 08:01.56 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9395 /wiki/User:Vasco.costa/GSoC15/logs: /* Week 13 : 17 Aug-23 Aug */ |
| 08:04.11 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) | |
| 08:26.30 | *** join/#brlcad merzo (~merzo@user-94-45-58-141.skif.com.ua) | |
| 08:33.48 | *** join/#brlcad merzo (~merzo@92.60.189.225) | |
| 08:40.10 | *** join/#brlcad merzo_ (~merzo@user-94-45-58-141.skif.com.ua) | |
| 08:52.27 | *** join/#brlcad packrat (~packrator@c-71-231-32-234.hsd1.wa.comcast.net) | |
| 09:33.47 | *** join/#brlcad merzo (~merzo@user-94-45-58-141.skif.com.ua) | |
| 09:45.24 | *** join/#brlcad Izakey (~Izakey@41.205.22.39) | |
| 10:19.45 | *** join/#brlcad merzo (~merzo@92.60.189.225) | |
| 10:25.12 | *** join/#brlcad konrado (~konro@41.205.22.57) | |
| 10:27.39 | *** join/#brlcad merzo (~merzo@user-94-45-58-141.skif.com.ua) | |
| 10:44.35 | *** join/#brlcad merzo (~merzo@user-94-45-58-141.skif.com.ua) | |
| 10:49.03 | *** join/#brlcad merzo (~merzo@92.60.189.225) | |
| 10:52.27 | *** join/#brlcad dracarys983 (dracarys98@nat/iiit/x-vkdwwonozhuytpsc) | |
| 11:01.09 | *** join/#brlcad packrat (~packrator@c-71-231-32-234.hsd1.wa.comcast.net) | |
| 11:31.15 | *** join/#brlcad packrat (~packrator@c-71-231-32-234.hsd1.wa.comcast.net) | |
| 11:50.57 | *** join/#brlcad sofat (~androirc@202.164.45.212) | |
| 11:52.41 | *** join/#brlcad vasc (~VASC@bl13-118-251.dsl.telepac.pt) | |
| 11:53.55 | *** join/#brlcad shaina (~shaina@59.89.46.162) | |
| 12:33.32 | *** join/#brlcad merzo (~merzo@92.60.189.225) | |
| 12:59.03 | Notify | 03BRL-CAD Wiki:Shaina7837 * 9396 /wiki/User:Shainasabarwal/GSoC15/logs: /* 8 August */ |
| 12:59.13 | *** join/#brlcad sofat (~androirc@202.164.45.204) | |
| 13:13.56 | *** join/#brlcad merzo (~merzo@user-94-45-58-141.skif.com.ua) | |
| 13:22.07 | *** join/#brlcad merzo_ (~merzo@user-94-45-58-141.skif.com.ua) | |
| 13:27.07 | Notify | 03BRL-CAD:starseeker * 65966 brlcad/trunk/src/other/openNURBS/opennurbs_array_defs.h: Clear compiler warning about assuming signed overflow does not occur when assuming that (X + c) < X is always false |
| 13:37.03 | Notify | 03BRL-CAD:starseeker * 65967 brlcad/trunk/src/libged/shape_recognition.cpp: Initialize curr_union |
| 13:40.13 | Notify | 03BRL-CAD:starseeker * 65968 brlcad/trunk/src/libgcv/facetize.c: clear another longjmp warning |
| 13:44.37 | Notify | 03BRL-CAD:starseeker * 65969 brlcad/trunk/src/libgcv/CMakeLists.txt: Need the includes for the static target as well. |
| 13:51.59 | Notify | 03BRL-CAD:starseeker * 65970 brlcad/trunk/src/libgcv/soup.h: Try to add some GCV_EXPORT logic for the test program - untested, needed for Windows. |
| 14:08.37 | Notify | 03BRL-CAD:carlmoore * 65971 (brlcad/trunk/doc/docbook/presentations/en/Introduction_brlcad-app-devel.xml brlcad/trunk/src/libgcv/bot_solidity.h and 5 others): fix spelling of 'determining', and remove trailing white space |
| 14:18.06 | Notify | 03BRL-CAD:starseeker * 65972 (brlcad/trunk/misc/CMake/BRLCAD_Targets.cmake brlcad/trunk/src/libgcv/CMakeLists.txt): And the rabbit hole gets deeper. Shared and static targets are separate targets, so they'll need separate generated sources as well for parallel safety. |
| 14:24.03 | Notify | 03BRL-CAD:d_rossberg * 65973 (brlcad/trunk/src/librt/primitives/arb8/arb8.c brlcad/trunk/src/librt/primitives/table.c): applied patch http://sourceforge.net/p/brlcad/patches/327/ provided by Kalpit Thakkar: Added surface area function for arb8 |
| 14:27.29 | Notify | 03BRL-CAD:starseeker * 65974 (brlcad/trunk/misc/CMake/BRLCAD_Targets.cmake brlcad/trunk/src/other/stepcode/cmake/SC_Utils.cmake brlcad/trunk/src/other/stepcode/src/express/CMakeLists.txt): remove debug printouts |
| 14:30.05 | ``Erik | gsoc soft deadline today, weeeee |
| 14:37.22 | *** join/#brlcad sofat_ (~androirc@202.164.45.212) | |
| 14:53.27 | *** join/#brlcad smile__ (~smile@202.164.45.212) | |
| 15:15.51 | *** join/#brlcad sofat (~smile@202.164.45.212) | |
| 15:16.05 | *** join/#brlcad merzo (~merzo@user-94-45-58-141.skif.com.ua) | |
| 15:25.14 | Notify | 03BRL-CAD:starseeker * 65975 (brlcad/trunk/src/other/stepcode/cmake/SC_Utils.cmake brlcad/trunk/src/other/stepcode/src/express/CMakeLists.txt): Committed too many files - backout so messages will be clearer |
| 15:26.08 | Notify | 03BRL-CAD:starseeker * 65976 (brlcad/trunk/src/other/stepcode/cmake/SC_Utils.cmake brlcad/trunk/src/other/stepcode/src/express/CMakeLists.txt): Update stepcode build logic for static/shared individual file generation |
| 15:49.40 | *** join/#brlcad gurwinder (~chatzilla@59.91.112.3) | |
| 15:52.19 | *** join/#brlcad sofat_ (~androirc@202.164.45.212) | |
| 15:58.26 | *** join/#brlcad sofat (~smile@202.164.45.212) | |
| 16:00.53 | *** join/#brlcad shaina (~shaina@117.214.241.50) | |
| 16:17.14 | *** join/#brlcad smile (~smile@202.164.45.212) | |
| 16:29.04 | *** join/#brlcad merzo (~merzo@user-94-45-58-141.skif.com.ua) | |
| 16:41.39 | *** join/#brlcad Guest74157 (~smile@202.164.45.212) | |
| 16:51.33 | *** join/#brlcad sofat (~smile@202.164.45.212) | |
| 17:12.50 | Notify | 03BRL-CAD:starseeker * 65977 brlcad/trunk/src/libgcv/soup.h: Missed one |
| 17:14.22 | *** join/#brlcad vasc (~VASC@bl13-118-251.dsl.telepac.pt) | |
| 17:16.11 | Notify | 03BRL-CAD:starseeker * 65978 (brlcad/trunk/src/libbu/brlcad_path.c brlcad/trunk/src/libbu/temp.c): Don't conditionalize the log messages on WIN32. Also, go ahead and try the Windows temp paths - they should simply fail and fall through to the correct paths. |
| 17:23.44 | *** join/#brlcad smile_ (~smile@202.164.45.212) | |
| 17:24.02 | *** join/#brlcad sofat (~smile@202.164.45.212) | |
| 17:36.53 | *** join/#brlcad merzo (~merzo@user-94-45-58-141.skif.com.ua) | |
| 17:37.15 | *** join/#brlcad ih8sum3r (~ih8sum3r@122.173.214.247) | |
| 17:42.25 | *** join/#brlcad sofat (~smile@202.164.45.212) | |
| 17:45.01 | *** join/#brlcad smile_ (~smile@202.164.45.212) | |
| 17:47.32 | Notify | 03BRL-CAD Wiki:Deekaysharma * 9397 /wiki/User:Deekaysharma/logs: |
| 17:50.31 | *** join/#brlcad AndroUser2 (~androirc@202.164.45.212) | |
| 18:04.25 | starseeker | alright, 65800 broke solids regression, which was me. now, why.... |
| 18:08.40 | sofat | starseeker, hello |
| 18:09.12 | sofat | I have submit one patch please accept this ticket no:407 |
| 18:11.02 | Notify | 03BRL-CAD:starseeker * 65979 (brlcad/trunk/src/librt/librt_private.h brlcad/trunk/src/librt/primitives/arbn/arbn.c and 8 others): 65800 somehow breaks regress-solids - rename was mostly for convenience, just revert. |
| 18:30.46 | Notify | 03BRL-CAD:starseeker * 65980 (brlcad/trunk/src/librt/librt_private.h brlcad/trunk/src/librt/primitives/arbn/arbn.c and 8 others): ah - was a name conflict. just prefix with an underscore |
| 18:40.55 | *** join/#brlcad ih8sum3r (~ih8sum3r@122.173.214.247) | |
| 18:47.10 | Notify | 03BRL-CAD:vasco_costa * 65981 (brlcad/trunk/include/rt/shoot.h brlcad/trunk/src/librt/primitives/primitive_util.c and 2 others): * show -z opencl command line option in -h when running rt.* renable table.cl to rt.cl.* replace branches in pixel writing with conditional moves.* refactor sub buffer code.* write depth buffer in network byte order. |
| 18:54.15 | Notify | 03BRL-CAD:vasco_costa * 65982 (brlcad/branches/opencl/include/rt/shoot.h brlcad/branches/opencl/src/librt/primitives/primitive_util.c and 2 others): merge changes from trunk. |
| 19:01.14 | *** join/#brlcad konrado (~konro@41.205.22.23) | |
| 19:12.58 | Notify | 03BRL-CAD:vasco_costa * 65983 brlcad/trunk/src/librt/primitives/rt.cl: remove unnecessary constant. |
| 19:13.16 | Notify | 03BRL-CAD:vasco_costa * 65984 brlcad/branches/opencl/src/librt/primitives/rt.cl: merge changes from trunk. |
| 19:14.30 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9398 /wiki/User:Vasco.costa/GSoC15/logs: /* Week 13 : 17 Aug-23 Aug */ |
| 19:29.35 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9399 /wiki/User:Vasco.costa/GSoC15/logs: /* Week 13 : 17 Aug-23 Aug */ |
| 19:30.34 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9400 /wiki/User:Vasco.costa/GSoC15/logs: /* Development Status */ |
| 19:30.53 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9401 /wiki/User:Vasco.costa/GSoC15/logs: /* Development Status */ |
| 19:33.51 | Notify | 03BRL-CAD:dhoward * 65985 (brlcad/trunk/src/librt/screened_poisson.cpp brlcad/trunk/src/other/PoissonRecon/LICENSE and 49 others): Updated Kazhdan code to version 7.0. |
| 20:08.14 | Notify | 03BRL-CAD Wiki:Rawley1515 * 0 /wiki/User:Rawley1515: |
| 20:53.48 | Notify | 03BRL-CAD:starseeker * 65986 (brlcad/trunk/CMakeLists.txt brlcad/trunk/src/libged/facetize.c and 3 others): Screened Poisson code isn't building at the moment - make a configure option to enable/disable this feature and set it to off by default. |
| 20:54.40 | *** join/#brlcad vasc (~vasc@bl13-118-251.dsl.telepac.pt) | |
| 20:57.04 | Notify | 03BRL-CAD:vasco_costa * 65987 (brlcad/branches/opencl/CMakeLists.txt brlcad/branches/opencl/src/librt/cut.c): Parallel OpenMP HLBVH construction. |
| 20:58.29 | starseeker | vasc: the file scan.cl is under Apache license, which is currently problematic for us as a direct source inclusion in our libraries... I don't know if this makes sense in opencl terms, but could that be built as a separate library? |
| 21:00.20 | Stragus | If that's just a parallel prefix sum, rewrite it from scratch, it's very little code |
| 21:01.52 | starseeker | Stragus: not sure about what it is - just spotted the license header |
| 21:02.05 | starseeker | hopefully can be rewritten, yes |
| 21:02.20 | starseeker | or maybe an MIT/BSD variant is available... |
| 21:02.46 | starseeker | sighs - it's a shame Apache 2 isn't compatible with GPL/LGPL v2 |
| 21:07.44 | vasc | well i'm not using it at this point in time so you can just remove it |
| 21:07.50 | vasc | but wait a bit |
| 21:08.14 | vasc | i think i got the code from pyopencl but it's an opencl translation of nvidia code |
| 21:08.18 | vasc | and they usually use MIT license |
| 21:08.46 | starseeker | probably derived from an NVIDIA example that was Apache 2 originally |
| 21:09.24 | starseeker | hmm: https://code.google.com/p/clpp/ |
| 21:09.52 | vasc | yeah its apache license 2 |
| 21:10.06 | vasc | it's not being used right now |
| 21:10.24 | vasc | you would have to remove the ANSI C code that calls it as well though |
| 21:10.40 | vasc | eventually it should be useful |
| 21:10.52 | starseeker | vasc: can it be reimplemented or another implementation used? |
| 21:11.08 | vasc | i thought the newest apache license was GNU GPL compatible? |
| 21:11.28 | starseeker | GPL v3 |
| 21:11.37 | vasc | http://www.apache.org/licenses/GPL-compatibility.html |
| 21:11.41 | vasc | oh ok |
| 21:12.04 | vasc | well the hlbvh code at least is like MIT or simplified BSD or whatever |
| 21:12.10 | starseeker | that's fine :-) |
| 21:12.13 | vasc | replacing that code won't be easy |
| 21:12.25 | starseeker | the clpp implementation won't do? |
| 21:12.39 | starseeker | MIT and 2/3 clause BSD are good |
| 21:12.49 | vasc | a lot of those libraries, opencl libraries, you see in the web are *crap* |
| 21:12.54 | starseeker | ah |
| 21:13.08 | vasc | they don't support arrays of non-power of two size for example |
| 21:13.59 | vasc | swell |
| 21:14.08 | vasc | CUB is New BSD licensed |
| 21:14.14 | vasc | and its faster than thrust |
| 21:14.21 | vasc | so we could port it from that. but CUB is really complicated. |
| 21:14.29 | vasc | porting that CUDA to OpenCL... |
| 21:14.30 | starseeker | link? |
| 21:14.37 | vasc | http://nvlabs.github.io/cub/ |
| 21:14.46 | vasc | it's CUDA not OpenCL |
| 21:14.48 | vasc | would need to port it |
| 21:14.51 | starseeker | ah |
| 21:15.17 | vasc | it's the faster library there is to use on GPUs basically |
| 21:15.21 | vasc | fastest |
| 21:15.36 | vasc | better than thrust. it's just that thrust comes bundled with CUDA |
| 21:15.41 | starseeker | well, another option would be to contact NVIDIA and the other copyright holder on the current scan.cl file and see if they'd be OK relicensing it to the same license as CUB |
| 21:15.45 | vasc | so i guess the pyopencl guys ported that |
| 21:16.09 | vasc | we could try that |
| 21:16.15 | starseeker | can't hurt to ask - worst they'd say is no |
| 21:16.29 | vasc | PyOpenCL is MIT licensed already |
| 21:16.45 | vasc | http://documen.tician.de/pyopencl/misc.html#license |
| 21:16.50 | starseeker | nods - but the file in question has two copyright holders listed, so they'd both have to OK it |
| 21:16.51 | vasc | so the problem is with NVIDIA |
| 21:17.12 | starseeker | very likely, but for something like this you need an OK from both |
| 21:17.19 | vasc | i know some guys i can ask. but i don't think they are the proper people to ask |
| 21:17.29 | starseeker | they can probably point you in the right direction :-) |
| 21:17.52 | Stragus | Guys guys, just rewrite the parallel prefix sum if needed :p |
| 21:18.19 | starseeker | Stragus: "< vasc> replacing that code won't be easy" |
| 21:18.58 | vasc | it's easy to write your own. writing an *efficient* one that handles all cases is *not* easy. |
| 21:19.26 | vasc | that code handles exclusive and inclusive prefix sums including segmented ones. |
| 21:19.37 | vasc | for any sized lists |
| 21:20.08 | vasc | but like i said it isn't actually used anywhere right now. |
| 21:20.11 | vasc | we can just remove it. |
| 21:20.16 | vasc | i'll make a patch. |
| 21:20.28 | starseeker | nods - worth asking the question though if you think it might come in handy later |
| 21:21.01 | vasc | public opencl libraries are kinda crap. all of them. |
| 21:21.11 | vasc | CUDA has a lot better libraries than we do. |
| 21:21.33 | starseeker | is it even possible to port CUB to OpenCL? |
| 21:21.48 | vasc | basically any piece of CUDA code can be ported to OpenCL. |
| 21:21.58 | vasc | it's like asking if you can port from C++ to C. |
| 21:22.05 | starseeker | ah :-) |
| 21:22.44 | vasc | CUDA supports templates and CUB uses them extensively for e.g. |
| 21:22.58 | vasc | OpenCL programmers usually use C like OpenGL programmers. |
| 21:23.52 | vasc | CUDA C++ actually |
| 21:23.58 | starseeker | well, if we don't need it right now it's moot - if/when the time comes we can weigh the options |
| 21:24.18 | vasc | that's the thing with CUDA. it's kinda like Java. it's an architecture, a platform, and C/C++ languages. |
| 21:24.26 | vasc | ok |
| 21:24.42 | vasc | that was a good catch i assume because it was in pyopencl it was safe. |
| 21:24.46 | vasc | assumed |
| 21:24.52 | Stragus | Some stuff using CUDA-specific features will be difficult to port, but otherwise it's a good assumption |
| 21:26.16 | Stragus | A parallel prefix sum will probably use CUDA lane shuffles, but you can put that in shared memory |
| 21:27.48 | vasc | you can actually use PTX assembly to use that i think i was reading the PTX ISA the other day. |
| 21:28.00 | vasc | the problem is the code won't work in other platforms. |
| 21:28.02 | Stragus | I think they want portable OpenCL, otherwise they would have used CUDA ;) |
| 21:28.08 | vasc | right. |
| 21:28.22 | vasc | maybe in OpenCL 3.0. |
| 21:28.25 | vasc | or 4.0 |
| 21:28.46 | vasc | i actually considered porting thrust or CUB to OpenCL once |
| 21:28.59 | vasc | but its premature without OpenCL 2.0. |
| 21:29.06 | vasc | being widespread. |
| 21:29.35 | starseeker | when did it come out? |
| 21:29.42 | vasc | i dunno maybe 2009. |
| 21:29.57 | vasc | oh 2.0. |
| 21:30.05 | vasc | maybe 2-3 years? |
| 21:30.12 | vasc | ago |
| 21:30.39 | starseeker | vasc: probably enough for a start - by the time we've got everything shipshape and ready to roll, it'll probably be widespread ;-) |
| 21:30.54 | vasc | heh |
| 21:31.15 | vasc | well i'm busy with other stuff. that's the problem with us opencl guys. always too much crap to do. |
| 21:31.16 | starseeker | for example, we'll not be worrying about Qt4 for user interface compatibility |
| 21:31.21 | starseeker | heh |
| 21:31.27 | vasc | it's not like CUDA which has whole teams of programmers working on libraries |
| 21:31.30 | vasc | from NVIDIA |
| 21:31.47 | vasc | oh that |
| 21:32.02 | vasc | i didn't check the qt interface to see how the interface would be |
| 21:32.14 | starseeker | no need - it's not functional yet |
| 21:32.27 | starseeker | mged, archer, and rtwizard are our three primary GUI tools |
| 21:32.33 | vasc | it's actually the first time i programmer in tcl/tk |
| 21:32.39 | vasc | programmed |
| 21:32.49 | vasc | svn doesn't compile |
| 21:32.50 | starseeker | then there are the framebuffers (the windows rt and pix-fb throw up) |
| 21:32.57 | vasc | /home/vasco/brlcad/trunk/src/libged/facetize.c: In function ged_facetize: |
| 21:32.57 | vasc | /home/vasco/brlcad/trunk/src/libged/facetize.c:93:9: error: variable sp_fidelity set but not used [-Werror=unused-but-set-variable] |
| 21:32.57 | vasc | <PROTECTED> |
| 21:33.15 | starseeker | vasc: one sec... |
| 21:35.05 | Notify | 03BRL-CAD:starseeker * 65988 brlcad/trunk/src/libged/facetize.c: avoid set but unused |
| 21:35.10 | starseeker | vasc: give that a go |
| 21:36.13 | vasc | ok thanks it compiles now |
| 21:36.36 | vasc | i'll remove it now |
| 21:36.42 | starseeker | vasc: cool - thanks! |
| 21:37.19 | vasc | ok it ain't in trunk anymore |
| 21:37.24 | Notify | 03BRL-CAD:vasco_costa * 65989 (brlcad/trunk/src/librt/librt_private.h brlcad/trunk/src/librt/primitives/primitive_util.c): remove opencl scan code because of license issues. |
| 21:37.51 | vasc | oh right the .cl file |
| 21:38.17 | starseeker | vasc: worth asking the relevant parties if we need it in the future (if they don't have any strong attachment to Apache it could be quite simple) |
| 21:38.56 | vasc | nah i would rather port CUB which is three-clause BSD |
| 21:39.04 | vasc | but its gonna be a lot more tricky |
| 21:39.40 | starseeker | vasc: what about the "busy with other stuff" thing? :-P Although I suppose a port of CUB might be of much wider OpenCL interest... |
| 21:39.53 | vasc | like brl-cad for one |
| 21:40.00 | Notify | 03BRL-CAD:vasco_costa * 65990 (brlcad/trunk/src/librt/primitives/scan.cl =================================================================== and 584 others): forgot to remove the .cl file on the last commit. |
| 21:40.08 | vasc | if i write libraries i won't be writing application code. |
| 21:40.20 | starseeker | vasc: fair enough |
| 21:40.47 | starseeker | vasc: on the other hand, I'm guessing there's a chance we might end up needing a fair bit of stuff in CUB down the road? |
| 21:41.01 | vasc | i'm also suppose to start working on molecular visualization next year |
| 21:41.16 | starseeker | ah - yeah, that's a job |
| 21:41.21 | vasc | but i dunno |
| 21:41.32 | vasc | well it isn't funded yet |
| 21:41.35 | vasc | so i dunno |
| 21:41.51 | vasc | CUB is *very* useful |
| 21:41.56 | vasc | it has sorting and prefix sum routines |
| 21:42.00 | vasc | and run length encoding |
| 21:42.02 | vasc | all kinds of things |
| 21:42.27 | vasc | using those algorithms as basic blocks you can do all sorts of highly efficient higher level code on top |
| 21:44.21 | starseeker | thinks back to his ROTMOVIE days in undergrad... |
| 21:45.30 | starseeker | heh http://product11.com/tech/oldvissoft_files/snapshot3.png |
| 21:45.44 | starseeker | and that was the modern verson - iirc I was working with an even older one |
| 21:45.59 | vasc | right. that's balls and sticks model. |
| 21:46.11 | vasc | i also am going to work on molecular surface visualization. that's the tricky bit. |
| 21:46.50 | starseeker | also recalls fiddeling with pymol, rasmol and VMD... |
| 21:47.02 | vasc | it says isosurfaces in there. so it also supports molecular surface visualization i guess. |
| 21:47.45 | starseeker | http://product11.com/tech/oldvissoft_files/snapshot4.png |
| 21:47.48 | starseeker | sort of |
| 21:48.06 | vasc | yeah i've seen better. |
| 21:48.22 | Stragus | Must be old, with a 4:3 screen ratio |
| 21:48.33 | starseeker | circa 2001 |
| 21:48.44 | starseeker | likes his 4:3 screen ratio, thank you very much |
| 21:48.58 | starseeker | one of my biggest gripes with modern hardware |
| 21:49.32 | starseeker | winces - I see VMD is still using that funky weird custom license |
| 21:49.41 | vasc | anyway that's *if* we get funding for that project. |
| 21:49.48 | vasc | if we don't i'll have to find something else to do. |
| 21:50.23 | starseeker | nods |
| 21:50.48 | starseeker | well, regardless it sounds like porting CUB would benefit a wide variety of projects |
| 21:51.22 | starseeker | yeah, pymol's license is a lot saner |
| 21:52.37 | starseeker | vasc: this the sort of thing you'd be looking at? https://www.pymol.org/sites/all/themes/basic/images/el1.png |
| 21:53.57 | vasc | yeah that's more like it. |
| 21:56.55 | starseeker | is rather bemused to see that pymol's interface does not appear to have evolved much - it's not just BRL-CAD ;-) |
| 21:57.34 | vasc | well if it works it works |
| 21:58.05 | vasc | but the thing is the render time with the ray trace engine is so fast now it makes you wonder about some of the UI design choices... |
| 21:58.18 | starseeker | for us you mean? |
| 21:58.24 | vasc | yeah |
| 21:58.38 | starseeker | nods - when you were running on a PDP11, it didn't matter so much |
| 21:59.07 | starseeker | our benchmark test reports in units based on one of the original machines |
| 21:59.24 | vasc | like to raytrace an image in mged i have to use a drop-down menu and it spawns an rt process thread. |
| 21:59.42 | vasc | i don't quite know the details of how the image sharing is done though |
| 21:59.57 | vasc | but i assume it reloads the object database over and over and over. |
| 22:00.01 | starseeker | that's a cheap way to get asyncronus updating - it pipes the data through an inter-process pipe |
| 22:00.21 | vasc | i dunno |
| 22:00.26 | Stragus | At some point, it should be designed for real-time raytracing with direct interaction |
| 22:00.28 | vasc | that's how the fb works? |
| 22:00.46 | vasc | yeah that's the thing |
| 22:00.51 | starseeker | mged fires a separate rt, which uses libpkg to send/recieve the pixels - the framebuffer in MGED then "listens" for them and display them |
| 22:00.58 | starseeker | it's a bit funky |
| 22:01.06 | Stragus | That's very inefficient if you want 60 frames per second |
| 22:01.13 | vasc | i get like tens or hundreds of mpixels/sec on the scenes i've tested with |
| 22:01.13 | starseeker | on Windows we go through Tcl communication mechanisms |
| 22:01.44 | starseeker | large chunck of our ifdef WIN32s in the code revolve around that, actually |
| 22:01.45 | vasc | we should never move the framebuffer from the gpu if we can. |
| 22:01.54 | Stragus | ^ What vasc said |
| 22:02.22 | starseeker | nods - our architecture needs a rethink. The notion of "on the GPU" isn't really captured at all |
| 22:02.33 | starseeker | one of our display backends is raw X11 |
| 22:02.45 | Stragus | Or, minimally, just copy the data directly and not over a pipe or a socket |
| 22:03.01 | starseeker | we need a properly multithreaded GUI for that to be viable |
| 22:03.38 | vasc | man i saw the code of the fb some time ago and it even did memory copies inside |
| 22:03.43 | starseeker | mged is too much work in that regard, and Archer probably is too - the Qt based interface will be keeping such things in mind, but it's a long ways out yet I'm afraid |
| 22:04.58 | vasc | so i render an image on the gpu, pass it to the cpu, it is deep copied around and around in buffers in several libraries, and then it gets pushed back onto the gpu |
| 22:05.16 | starseeker | nods - no argument that sucks |
| 22:05.44 | Stragus | Why is it copied multiple times on the CPU? I can see one copy to send/receive the pixels through the pipe/socket/whatever... |
| 22:06.07 | vasc | well the data in the client is stored in this format... |
| 22:06.22 | vasc | it's like RGB{depth} |
| 22:06.44 | vasc | 3 unsigned chars and 1 (optional) double in network precision |
| 22:06.50 | Stragus | o.O |
| 22:06.59 | vasc | the fb driver doesn't use the double precision depth |
| 22:07.04 | Stragus | That depth is a completely separate buffer I hope? |
| 22:07.11 | vasc | so it has this c code to manually rearrange the array |
| 22:07.24 | vasc | before passing it to whatever draws |
| 22:07.31 | vasc | nope it ain't |
| 22:07.35 | Stragus | WTF. |
| 22:07.55 | Stragus | This makes no sense whatsoever |
| 22:08.20 | Stragus | There's even a ton of wasted memory due to padding the pixel struct to 8 bytes |
| 22:08.27 | vasc | yes. |
| 22:08.31 | vasc | the rgbs take 3 |
| 22:08.54 | vasc | you would have to change the image processing, and fb code to fix that |
| 22:09.19 | Stragus | That's completely messed up |
| 22:09.30 | vasc | src/libicv and src/fb |
| 22:09.38 | vasc | and all the code that uses them |
| 22:09.48 | vasc | which can be quite a bit |
| 22:16.15 | starseeker | ok, original benchmark machine that we're comparing to was a VAX 11/780 |
| 22:16.53 | starseeker | at a guess, most desktops today would probably be five to ten thousand times faster, maybe more |
| 22:17.04 | starseeker | even without the OpenCL pipeline |
| 22:17.30 | starseeker | so that's why the original framebuffer architecture feels a little odd today ;-) |
| 22:19.15 | Stragus | But why would it waste 31% of the framebuffer memory? |
| 22:19.32 | Stragus | Memory was precious back then, 5 bytes of that pixel struct are wasted in padding alignment |
| 22:20.30 | starseeker | not sure about that - maybe a dedicated hardware console that expected data in a particular format? |
| 22:23.24 | Notify | 03BRL-CAD:starseeker * 65991 brlcad/trunk/src/conv/step/CMakeLists.txt: Remove the ineffective MD5SUM verification attempt - didn't address the actual problem. |
| 22:40.54 | vasc | asctually you're wrong. it isn't wasting 31% of framebuffer memory |
| 22:41.01 | vasc | in that case |
| 22:41.15 | Stragus | It's wasting 5 or 16 bytes? |
| 22:41.20 | Stragus | 5 of* 16 |
| 22:41.43 | vasc | it's wasting 72% |
| 22:41.54 | vasc | its 8 bytes depth buffer, 1 byte per r, g,b |
| 22:42.06 | vasc | the fb buffer for glx discards the depth data |
| 22:42.14 | vasc | i think |
| 22:42.23 | Stragus | Right, I was only counting the padding |
| 22:42.49 | Stragus | 31% lost in padding, 50% lost in data it doesn't care about, 18% of useful data |
| 22:42.50 | vasc | i think the image outputs can use the depth data. at least they accept it |
| 22:43.36 | vasc | wonders if they ignore the depth data too |
| 22:43.51 | vasc | haven't read icv that deep yet |
| 22:44.11 | vasc | the FILE* writer writes the depth data out. that i do know. |
| 22:44.31 | vasc | the raw output |
| 22:44.47 | vasc | the data can be stored in a number of ways |
| 22:45.07 | vasc | the most common it 3 unsigned chars for r,g,b and 1 network order double for depth |
| 22:45.07 | Notify | 03BRL-CAD:starseeker * 65992 (brlcad/trunk/src/conv/step/g-step/CMakeLists.txt brlcad/trunk/src/conv/step/step-g/CMakeLists.txt): not using explicit targets now. |
| 22:45.21 | vasc | there are also 4 double formats r,g,b, depth |
| 22:45.26 | vasc | depth is always optional |
| 22:45.37 | vasc | then there is this monster format |
| 22:46.51 | vasc | it's like uint8 r,g,b; double dist; float hitp[3]; has some region_ptr, short a_x,a_y |
| 22:46.52 | vasc | i think |
| 22:46.58 | vasc | or was the color doubles |
| 22:47.06 | vasc | its the FULLFLOAT format |
| 22:47.36 | vasc | i think its used to combine results of images from different rt instances. i dunno if its threads or cluster node processes or whatever. |
| 22:47.46 | vasc | currently i don't support that format |
| 22:48.21 | vasc | its used to store intermediates i bet. |
| 22:48.34 | vasc | like you stop ray generation midway and continue elsewhere. |
| 22:49.49 | vasc | then there's the fact that the framebuffer and raw file outputs allow writing with passing a buffer with a size |
| 22:50.18 | vasc | while the icv image file format writer only buffered line output |
| 22:51.07 | vasc | i got to see more of the brl-cad internals than i would be have preferred to know |
| 22:51.35 | vasc | the high level code is great. its like picture perfect code. |
| 22:51.41 | vasc | even its a bit oldstyle. |
| 22:51.52 | vasc | the interface and glue bits.... yikes. |
| 22:52.01 | vasc | with the outputs |
| 22:52.26 | vasc | they seem to have been written in a process of accretion. |
| 22:55.10 | Stragus | I'm sure that's a correct assessment :) |
| 22:55.20 | Stragus | Incremental little steps over a few decades |
| 23:00.30 | vasc | i was looking at openhub.net the other day |
| 23:00.54 | vasc | it said that BRL-CAD had like 330 man-years of coding in it in that model they use based on lines of code and dates and crap |
| 23:01.26 | vasc | hugely impressive |
| 23:03.06 | Stragus | Mmhm... I don't know the metric used, but it wouldn't take a single programmer 330 years to write a copy |
| 23:03.32 | vasc | no but maybe 5 years wouldn't be surprising |
| 23:03.49 | vasc | if not a lot more |
| 23:04.05 | vasc | its not just the librt i'm touching in |
| 23:04.13 | vasc | its everything else too |
| 23:04.34 | vasc | hugely impressive. massive even. |
| 23:04.38 | Stragus | Sure |
| 23:07.06 | vasc | https://www.openhub.net/p/brlcad |
| 23:07.24 | vasc | 1.2 MLOC |
| 23:08.53 | vasc | i hope it ain't counting the 3rd party libs though |
| 23:10.42 | vasc | the branch i made is diverging a lot. i don't think svn is the best choice for this parallel concurrent development work |
| 23:11.17 | vasc | perhaps git-svn would have been better |
| 23:20.37 | Notify | 03BRL-CAD:vasco_costa * 65993 (brlcad/branches/opencl/src/librt/cut.c brlcad/branches/opencl/src/librt/librt_private.h brlcad/branches/opencl/src/librt/primitives/primitive_util.c): merge changes from trunk. |
| 23:58.08 | Notify | 03BRL-CAD Wiki:202.164.45.212 * 9402 /wiki/User:Hiteshsofat/GSoc15/log_developmen: |
