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) |