00:36.53 |
*** join/#brlcad
utkcamyrjeftpzyh
(~armin@dslb-188-098-168-213.188.098.pools.vodafone-ip.de) |
01:00.44 |
*** join/#brlcad http_GK1wmSU
(~deep-book@119.81.230.146) |
01:02.13 |
*** part/#brlcad http_GK1wmSU
(~deep-book@119.81.230.146) |
01:35.59 |
*** part/#brlcad mdtwenty[m]
(mdtwentyma@gateway/shell/matrix.org/x-zzjodrxmmmvwtbhh) |
03:46.40 |
*** join/#brlcad gabbar1947
(uid205515@gateway/web/irccloud.com/x-jzxieabhewzifbdm) |
05:39.58 |
*** join/#brlcad ``Erik
(~erik@pool-100-16-35-136.bltmmd.fios.verizon.net) |
05:46.13 |
*** join/#brlcad ``Erik
(~erik@pool-100-16-35-136.bltmmd.fios.verizon.net) |
07:15.23 |
*** join/#brlcad teepee
(~teepee@unaffiliated/teepee) |
07:25.54 |
*** join/#brlcad teepee
(~teepee@unaffiliated/teepee) |
07:59.48 |
*** join/#brlcad ``Erik
(~erik@pool-100-16-20-94.bltmmd.fios.verizon.net) |
08:13.58 |
*** join/#brlcad teepee
(~teepee@unaffiliated/teepee) |
08:55.40 |
*** join/#brlcad KimK
(~Kim__@2600:8803:7a81:7400:70ff:33e:29ad:41ff) |
09:00.21 |
*** join/#brlcad merzo
(~merzo@user-94-45-58-139.skif.com.ua) |
09:57.38 |
*** join/#brlcad merzo
(~merzo@94.45.58.139) |
10:10.08 |
*** join/#brlcad teepee
(~teepee@unaffiliated/teepee) |
10:30.24 |
*** join/#brlcad Caterpillar
(~caterpill@unaffiliated/caterpillar) |
11:13.28 |
*** join/#brlcad vasc
(~vasc@bl4-144-217.dsl.telepac.pt) |
13:16.53 |
*** join/#brlcad teepee
(~teepee@unaffiliated/teepee) |
13:34.26 |
*** join/#brlcad DaRock1
(~Thunderbi@mail.unitedinsong.com.au) |
13:43.01 |
*** join/#brlcad yorik
(~yorik@2804:431:f721:ff6:290:f5ff:fedc:3bb2) |
14:50.07 |
*** join/#brlcad Stragus
(~alexis@modemcable131.0-202-24.mc.videotron.ca) |
14:52.31 |
*** join/#brlcad teepee
(~teepee@unaffiliated/teepee) |
15:24.26 |
Notify |
03BRL-CAD Wiki:Mariomeissner * 10158
/wiki/User:Mariomeissner/logs: |
15:50.28 |
*** join/#brlcad mdtwenty[m]
(mdtwentyma@gateway/shell/matrix.org/x-zzjodrxmmmvwtbhh) |
16:32.44 |
vasc |
hey mdtwenty[m] |
16:33.25 |
mdtwenty[m] |
hi! |
16:33.57 |
vasc |
so let's look at the pbrt code |
16:37.15 |
vasc |
so you say it doesn't work? |
16:38.39 |
mdtwenty[m] |
it worked for a small example ( 0 + 1) but
when I run it with a bigger example it doens't make much
sense |
16:39.37 |
vasc |
hmm |
16:39.42 |
vasc |
what's with the loop? |
16:39.51 |
vasc |
that loop in buildtree() shouldn't be
there. |
16:40.22 |
vasc |
its like, it's a binary tree. |
16:40.39 |
vasc |
and buildtree() or a node is like add this
node and do buildtree() on the descendants. |
16:40.40 |
vasc |
no loops. |
16:40.52 |
mdtwenty[m] |
oh |
16:41.35 |
mdtwenty[m] |
yeah the loop isn't supposed to be there.. its
only one instruction inside the pbrt example! I missed
that |
16:42.44 |
vasc |
i dunno why you need rt_flat_tree()
either. |
16:43.14 |
vasc |
hmm... |
16:43.40 |
mdtwenty[m] |
yes I was about to ask you that |
16:44.13 |
vasc |
its just like... |
16:44.23 |
vasc |
you start at the node and build_tree left and
right. |
16:44.47 |
vasc |
the problem is how to know where to store
nodes and how to set the rchild index properly. |
16:45.38 |
vasc |
also |
16:45.49 |
vasc |
+ if (start + 1 == end) { |
16:45.49 |
vasc |
+ rtp[pos].has_lchild = 0; |
16:45.49 |
vasc |
+ rtp[pos].tr_d.tr_l.st_bit =
tp[pos].st_bit; |
16:45.49 |
vasc |
+ } |
16:45.49 |
vasc |
+ |
16:45.56 |
vasc |
it's support to have a return there. |
16:46.03 |
vasc |
this is the case where it's a leaf. |
16:46.09 |
vasc |
its just like... |
16:46.29 |
vasc |
if (leaf) { leafstuff; return; } |
16:47.54 |
vasc |
+ rtp[pos].tr_d.tr_b.uop =
tp[pos].uop; |
16:47.57 |
vasc |
this is before the ifs. |
16:48.13 |
vasc |
because it happens forall branches
(non-leafs) |
16:49.20 |
vasc |
s/support/supposed/g. |
16:49.33 |
Notify |
03BRL-CAD:starseeker * 70036
brlcad/trunk/src/other/libpng/CMakeLists.txt: Not using WDIR after
all |
16:50.00 |
mdtwenty[m] |
hmm okay I will fix these issues with the
function! thank you for the help |
16:50.31 |
vasc |
well |
16:50.35 |
vasc |
no problem. |
16:50.46 |
vasc |
just remember. write the code based on the
union tree. |
16:50.51 |
vasc |
and you don't need that flat
function. |
16:51.06 |
vasc |
its just like... |
16:51.17 |
vasc |
buildtree() if leaf() {} else {} |
16:51.40 |
vasc |
in the else { buildtree(); /*left*/
buildtree(); /*right*/ } |
16:52.25 |
vasc |
i only gave that pbrt code so you could look
at how it updates the nextfreenode and things like that. |
16:52.43 |
vasc |
did you get to remove those fields in the
partitions? |
16:53.06 |
vasc |
like the prev index and the next valid
partition index? |
16:53.28 |
vasc |
hm |
16:53.34 |
mdtwenty[m] |
no, not yet |
16:53.45 |
vasc |
ok |
16:53.46 |
mdtwenty[m] |
also |
16:54.03 |
mdtwenty[m] |
yesterday i run the command that Sean
suggested |
16:54.19 |
mdtwenty[m] |
"mdtwenty[m]: goliath is not really a good
test case for patch 473 -- run this instead on before and after:
"TIMEFRAME=60 DEVIATION=1 benchmark run"" |
16:54.53 |
mdtwenty[m] |
i run benchmarks for the version in the trunk,
the version in the trunk with the patch 473 applied and with the
version on the opencl branch |
16:55.42 |
mdtwenty[m] |
but i am not sure about what number in the
benchmark results I should use to compare things |
16:55.55 |
vasc |
what is the output? |
16:56.33 |
mdtwenty[m] |
posted a file:
run-12576-benchmark_trunk.log (19KB) <https://matrix.org/_matrix/media/v1/download/matrix.org/SrGHIpeiNVUrbivZMlBvpGCG> |
16:56.50 |
mdtwenty[m] |
this is the output for the version in the
trunk |
16:57.16 |
mdtwenty[m] |
i suppose I should compare with the "total
testing time elapsed"? |
16:57.39 |
mdtwenty[m] |
or with the VGR number? |
16:57.42 |
vasc |
ok, it loads a bunch of scenes and animates
them. |
16:59.15 |
vasc |
the VGR is some benchmark stat. |
17:00.10 |
vasc |
you can either compare VGRs or the
RTFMs. |
17:00.17 |
vasc |
the total time ellapsed is also a possibility
yes. |
17:00.24 |
mdtwenty[m] |
posted a file:
run-14785-benchmark_opencl.log (19KB) <https://matrix.org/_matrix/media/v1/download/matrix.org/LOESCkSFvUMKSNDYIPAIKzTZ> |
17:00.25 |
mdtwenty[m] |
posted a file:
run-8110-benchmark_p473.log (19KB) <https://matrix.org/_matrix/media/v1/download/matrix.org/tKDSSIgJaaoOqVEgmxrddnCl> |
17:00.40 |
mdtwenty[m] |
those are the other results |
17:02.10 |
vasc |
uh... |
17:03.10 |
vasc |
all the VGRs are the same. |
17:03.42 |
vasc |
ah no |
17:04.08 |
vasc |
its better with the patch? oh
whatever. |
17:04.22 |
vasc |
that doesn't make a lot of sense. |
17:04.34 |
mdtwenty[m] |
the version currently in the trunk has a
smaller total time elapsed, but also has smaller vgr |
17:04.35 |
vasc |
it should be exactly the same not
faster. |
17:05.07 |
vasc |
well. i don't know what to say about these
numbers since the number of rays traced isn't the same in all
benchmark runs. |
17:07.14 |
vasc |
so you probably need to compare just the
performance metric VGR number. |
17:07.19 |
vasc |
the higher the number the better. |
17:07.36 |
vasc |
whatever. |
17:07.54 |
vasc |
you ran the tests with the test scenes and it
took the same time with the patch if i remember
correctly. |
17:08.21 |
mdtwenty[m] |
yeah thats correct |
17:09.04 |
vasc |
it's better that you pass those run results to
Sean so he can look at them. perhaps he has more
insights. |
17:11.09 |
mdtwenty[m] |
will do that! |
17:11.57 |
mdtwenty[m] |
also, can you take a look on the struct tree
definition that i wrote? when I run sizeof I got 8 bytes instead of
4 .. |
17:12.28 |
vasc |
of course you do. what i wrote was
pseudo-code. |
17:12.33 |
vasc |
:-) |
17:13.00 |
vasc |
you declare an uint, and then a
struct. |
17:13.32 |
vasc |
anyway, that isn't too important right now
since we'll have to replace it with shifts later. |
17:14.32 |
vasc |
so |
17:14.35 |
vasc |
you just use uints |
17:14.59 |
mdtwenty[m] |
okay! it was my first time working with bit
fields so I wasn't sure if I did things correctle there |
17:15.26 |
vasc |
and then it's like init_leaf(st_bit) |
17:15.34 |
vasc |
and init_node(uop, rchild) |
17:15.43 |
vasc |
and |
17:15.47 |
vasc |
init_leaf(): |
17:16.25 |
vasc |
<PROTECTED> |
17:16.30 |
vasc |
init_node(): |
17:16.51 |
vasc |
actually |
17:16.54 |
vasc |
<PROTECTED> |
17:16.58 |
vasc |
in init_leaf |
17:16.59 |
vasc |
and |
17:17.27 |
vasc |
oh no |
17:17.30 |
vasc |
it's just |
17:17.33 |
vasc |
<PROTECTED> |
17:17.35 |
vasc |
the other is |
17:17.54 |
vasc |
<PROTECTED> |
17:17.56 |
vasc |
i think |
17:18.12 |
vasc |
and then to check if it's a leaf: |
17:18.26 |
vasc |
is_leaf() : return !(val & 1); |
17:18.35 |
vasc |
things like that. |
17:18.47 |
vasc |
if you want i can write it. |
17:19.07 |
vasc |
it's not that complicated though. |
17:20.18 |
vasc |
thing is |
17:20.27 |
vasc |
you need to use the UOP macros i
defined |
17:20.40 |
vasc |
where UOPs are renumbered 0..7 or
something |
17:20.59 |
vasc |
the regular UOP numbers in include/ won't fit
in 3 bits. |
17:21.23 |
vasc |
2^8 = 8 |
17:21.31 |
vasc |
so only numbers 0..7 will fit. |
17:21.39 |
vasc |
2^3 |
17:21.40 |
vasc |
i mean |
17:21.42 |
vasc |
.. |
17:21.45 |
mdtwenty[m] |
yeah |
17:21.52 |
mdtwenty[m] |
sent a long message:
mdtwenty[m]_2017-08-03_17:21:52.txt <https://matrix.org/_matrix/media/v1/download/matrix.org/zPUWrgyNDQBBaCTStyAyYZRo> |
17:22.03 |
vasc |
yes those. |
17:22.21 |
vasc |
the one for OP_SOLID and OP_NOP are
unused. |
17:22.27 |
vasc |
those are for leafs. |
17:22.39 |
vasc |
i assume there are no OP_NOP and that all
leafs are OP_SOLID |
17:23.20 |
vasc |
so better assert() that there are no
OP_NOP |
17:23.21 |
vasc |
s |
17:24.15 |
mdtwenty[m] |
what are exaclty OP_NOPs? |
17:25.29 |
vasc |
NOP = no-op |
17:25.45 |
vasc |
it does... nothing |
17:26.05 |
vasc |
https://en.wikipedia.org/wiki/NOP |
17:26.05 |
i5o |
[ NOP - Wikipedia ] |
17:26.32 |
vasc |
i assume it's used in the code for things
like... |
17:26.48 |
vasc |
when it optimizes the tree one of the branches
is eliminated. |
17:26.56 |
vasc |
and that branch is replaced with NOP |
17:27.01 |
vasc |
and later the NOPs are removed. |
17:27.20 |
vasc |
but i'm not sure. |
17:27.31 |
mdtwenty[m] |
ah yes that makes sense |
17:29.04 |
vasc |
so OP_NOP is an empty volume
basically. |
17:29.27 |
vasc |
and OP_SOLID has the volume of the
primitive. |
17:30.36 |
*** join/#brlcad gabbar1947
(uid205515@gateway/web/irccloud.com/x-fybstnoxzvwtuibd) |
17:31.35 |
vasc |
the code for the kdtree in pbrt is more
complicated with the splitpos because it needs to partition the
tree at variable intervals according to space. |
17:31.42 |
vasc |
our binary tree doesn't need that. |
17:36.50 |
mdtwenty[m] |
okay! I think i am understanding it better
now |
18:47.56 |
vasc |
mdtwenty[m], send me an e-mail with the code
you have once you finish for the day, i'll then give you feedback
at worst by tomorrow. |
18:53.04 |
mdtwenty[m] |
https://pastebin.com/5Fi6u6AW |
18:53.05 |
i5o |
[ [C] void buildtree(struct otree *rtp, const
union tree *tp, size_t *len, size_t *n - Pastebin.com ] |
18:53.09 |
mdtwenty[m] |
does it look better? |
18:54.02 |
mdtwenty[m] |
i haven't tested it yet, so I will test it and
make some changes if necessary and will send you the email so you
can review it :) |
18:59.40 |
mdtwenty[m] |
thanks for the help today! |
19:12.43 |
Notify |
03BRL-CAD Wiki:Mariomeissner * 10159
/wiki/User:Mariomeissner/logs: |
19:18.01 |
vasc |
close |
19:18.15 |
vasc |
you don't need has_lchild anymore because
that's the first bit |
19:18.21 |
vasc |
also |
19:18.33 |
vasc |
https://github.com/mmp/pbrt-v1/blob/master/core/kdtree.h |
19:18.34 |
i5o |
[ pbrt-v1/kdtree.h at master · mmp/pbrt-v1 ·
GitHub ] |
19:19.07 |
vasc |
the rest needs to be tested |
19:19.20 |
vasc |
but it's getting there |
19:19.27 |
vasc |
see you tomrrow then |
19:36.04 |
Notify |
03BRL-CAD Wiki:Mariomeissner * 10160
/wiki/User:Mariomeissner/logs: |
20:02.26 |
*** join/#brlcad merzo
(~merzo@70-24-133-95.pool.ukrtel.net) |
20:32.33 |
Notify |
03BRL-CAD:brlcad * 70037
brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: use the warning message
type |
21:57.40 |
Notify |
03BRL-CAD:starseeker * 70038
brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: actually this is a
function now... |
22:00.01 |
Notify |
03BRL-CAD:starseeker * 70039
brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: ws |
22:04.03 |
Notify |
03BRL-CAD:starseeker * 70040
brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: We can't use FILTER yet,
but add a reminder to do so once we can require a sufficiently new
CMake. |
22:04.33 |
Notify |
03BRL-CAD:starseeker * 70041
brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: spelling |
22:07.34 |
Notify |
03BRL-CAD:starseeker * 70042
brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: more comment
tweakage |
22:22.21 |
Notify |
03BRL-CAD:starseeker * 70043
brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: more comment
tweaks |
22:58.00 |
Notify |
03BRL-CAD:starseeker * 70044
brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: macros to
functions |
23:07.36 |
Notify |
03BRL-CAD:starseeker * 70045
(brlcad/trunk/CMakeLists.txt
brlcad/trunk/misc/CMake/BRLCAD_Summary.cmake): Turn the whole
BRL-CAD summary printout into a function. |
23:31.14 |
Notify |
03BRL-CAD:starseeker * 70046
(brlcad/trunk/misc/CMake/BRLCAD_Targets.cmake
brlcad/trunk/misc/CMake/BRLCAD_Util.cmake): Turn
NORMALIZE_FILE_LIST into a function. |
23:34.16 |
Notify |
03BRL-CAD:starseeker * 70047
brlcad/trunk/src/CMakeLists.txt: We have an option for this,
actually - use it |