IRC log for #brlcad on 20160504

00:36.59 *** join/#brlcad fgmwbcwkyxfdqobw (~armin@dslb-088-064-046-039.088.064.pools.vodafone-ip.de)
01:35.44 starseeker huh, interesting: https://github.com/arrayfire/arrayfire
01:59.06 *** join/#brlcad amarjeet (~Amarjeet@101.216.63.182)
02:13.06 *** join/#brlcad kintel (~kintel@unaffiliated/kintel)
02:56.30 brlcad starseeker: Nice! arrayfire looks really interesting actually, definitely something to try on the cl branch
02:56.54 brlcad would allow some nice cl vs cuda vs cpu comparisons/debugging
02:59.53 Stragus brlcad, for the mesh decimation, it seems the only extra check still missing would be to make sure that no two triangles share the same edge in the same direction
03:00.00 Stragus (unless that's included somewhere in that last)
03:00.03 Stragus that list*
03:00.37 brlcad sync does that
03:01.03 Stragus And CUDA is only significantly faster than CL if you use the extra CUDA-only capabilities, like warp shuffles
03:01.12 brlcad it just doesn't know if it's inverted the whole thing or not, and of course only works if the geometry is actually syncable with no degenerate faces
03:04.00 Stragus And I believe any "framework" to run code on both CPUs and GPUs can't be usable, optimization for one is totally different from the other...
03:05.37 Stragus And proper code makes a huge difference on GPUs (like 10x), such as pulling "work" coherently into the on-chip shared memory
03:05.45 brlcad looks like they provide their own library of operations you perform on the data containers, which they also define
03:06.08 brlcad how to pack and process the data is still up to you
03:06.46 brlcad looks like you can compile lock your code to a particular backend, or you can make it bind at runtime to one of the three
03:07.42 Stragus So it's still bound and targeted to a backend, if you want performance. Can't really see the advantage
03:08.06 brlcad it can be bound, doesn't have to be
03:08.58 Stragus Well, if it's 10 times slower because it doesn't use shared memory, that's not really usable
03:10.00 brlcad who said it's 10x slower? they actually claim to be faster than most people's gpu code
03:10.36 brlcad looks like they make that claim based on their specific function kernels they provide for specific common operations
03:10.54 brlcad which they presumably have tailored for each backend
03:11.05 Stragus Depends on the problem, obviously. But I know very well that if you don't target GPU specifically and write CPU-style code, it can easily be 20 times slower than it could be
03:11.23 brlcad sure
03:23.13 *** join/#brlcad kintel (~kintel@unaffiliated/kintel)
06:45.45 *** join/#brlcad teepee (~teepee@unaffiliated/teepee)
07:50.44 *** join/#brlcad sniok (~sniok@89.252.2.135)
08:57.25 *** join/#brlcad teepee` (bc5c2134@gateway/web/freenode/ip.188.92.33.52)
11:21.57 *** join/#brlcad Notify (~notify@66-118-151-70.static.sagonet.net)
11:23.13 Notify 03BRL-CAD:brlcad * 67823 brlcad/trunk/src/nirt/parse_fmt.c: plug a tiny leak. we're done with the filename.
11:23.15 Notify 03BRL-CAD:brlcad * 67824 brlcad/trunk/src/nirt/nirt.c: make nirt report the current output style as well as a listing of the available output formats, with hints on what command line options change the setting or give more info. this is implemented specifically in response to user requests (e.g., ajem scr 1942) where several people have asked to have gaps or exit hitpoints reported, which are features of the other
11:23.17 Notify output formats.
11:23.19 Notify ...
11:23.28 Notify 03BRL-CAD:brlcad * 67825 brlcad/trunk/NEWS: nirt now reports the current output format setting, itemizes the available formats, and provides parenthetical help for what options pertain to output formatting. this was implemented in regards to prior mailing list discussion and ajem scr 1942 requesting gaps be reported (which is already one of the available output formats.
12:11.21 *** join/#brlcad kintel (~kintel@unaffiliated/kintel)
12:25.55 *** join/#brlcad kintel (~kintel@unaffiliated/kintel)
12:46.14 *** join/#brlcad yorik (~yorik@177.189.140.33)
13:46.14 Notify 03BRL-CAD:starseeker * 67826 brlcad/trunk/src/tclscripts/rtwizard/CMakeLists.txt: remove rtwizard.bat
13:54.54 Notify 03BRL-CAD:starseeker * 67827 brlcad/trunk/misc/CMake/NSIS.template.in: Tell NSIS to go for the .exe files, not the bat files - MGED is the only bat launcher left.
15:09.20 ``Erik is it wwdc yet? O.o
15:29.27 *** join/#brlcad Mathnerd314 (~quassel@supertux/Mathnerd314)
15:56.37 Notify 03BRL-CAD:n_reed * 67828 brlcad/branches/brep-debug/doc/docbook/system/implementation/en/bool_eval_development.xml: add descriptions of remaining dplot subcommands
16:37.14 *** join/#brlcad sniok (~sniok@89.252.2.135)
17:01.35 *** join/#brlcad kintel (~kintel@unaffiliated/kintel)
17:06.37 *** join/#brlcad kintel (~kintel@unaffiliated/kintel)
19:02.32 *** join/#brlcad amarjeet (~Amarjeet@101.216.73.71)
19:07.13 *** join/#brlcad amarjeet (~amarjeet@101.216.73.71)
19:15.18 Notify 03BRL-CAD:n_reed * 67829 brlcad/branches/brep-debug/doc/docbook/system/implementation/en/bool_eval_development.xml: document how to plot evaluation curves not automatically recorded by dplot
19:22.07 *** join/#brlcad yorik (~yorik@177.189.140.33)
19:48.37 *** join/#brlcad amarjeet (~Amarjeet@101.216.73.71)
20:05.43 *** join/#brlcad ickby (~stefan@HSI-KBW-046-005-253-113.hsi8.kabel-badenwuerttemberg.de)
20:27.30 *** join/#brlcad ickby (~stefan@HSI-KBW-046-005-253-113.hsi8.kabel-badenwuerttemberg.de)
20:38.30 *** join/#brlcad ickby (~stefan@HSI-KBW-046-005-253-113.hsi8.kabel-badenwuerttemberg.de)
20:41.15 *** join/#brlcad kintel (~kintel@unaffiliated/kintel)
23:26.05 *** join/#brlcad kintel (~kintel@unaffiliated/kintel)
23:58.58 *** join/#brlcad kintel (~kintel@unaffiliated/kintel)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.