Vasco Alexandre da Silva Costa
2016-08-23 18:18:29 UTC
Hello,
I tried to look at this from another approach. To check if we were missing
a step in the reimplementation I simplified ANSI C rt_shootray without
breaking rendering (patch attached).
I did the tests with operators.g. As you can see (0.png, 1.png) if gives me
the same output in both the original (0.png) and simplified (1.png) code.
However it breaks when I remove these lines:
s2->seg_in.hit_dist += ss.dist_corr;
s2->seg_out.hit_dist += ss.dist_corr;
It seems this is initialized in rt_advance_to_next_cell and without it it
breaks. Now this shouldn't be an issue with our code because I assume the
original ANSI C code is moving the ray origin along the ray direction as it
traverses the cells and this sum is just to give the total distance
relative to the eye origin in the end. The OpenCL code always uses eye
distance.
I also removed most of the partition creation code and the rendering still
works... I don't know if this is specific to this scene or if isn't
necessary in general to produce viable output.
I think a good next step to understand where the issue really is would be
to save all the inputs that go into rt_boolweave and rt_boolfinal in the
ANSI C and OpenCL versions into an ASCII text file and compare the results
for differences. Not just the partitions, the intersections, and the
bitvectors as well. It will probably be a lot of information, so this could
be checked on a line by line basis (e.g. pick significant single lines with
boolean operations in them).
There also might be some hidden state stored in 'ap' that we forgot to
consider here. I'll talk about your latest patch in a separate e-mail.
Regards,
I tried to look at this from another approach. To check if we were missing
a step in the reimplementation I simplified ANSI C rt_shootray without
breaking rendering (patch attached).
I did the tests with operators.g. As you can see (0.png, 1.png) if gives me
the same output in both the original (0.png) and simplified (1.png) code.
However it breaks when I remove these lines:
s2->seg_in.hit_dist += ss.dist_corr;
s2->seg_out.hit_dist += ss.dist_corr;
It seems this is initialized in rt_advance_to_next_cell and without it it
breaks. Now this shouldn't be an issue with our code because I assume the
original ANSI C code is moving the ray origin along the ray direction as it
traverses the cells and this sum is just to give the total distance
relative to the eye origin in the end. The OpenCL code always uses eye
distance.
I also removed most of the partition creation code and the rendering still
works... I don't know if this is specific to this scene or if isn't
necessary in general to produce viable output.
I think a good next step to understand where the issue really is would be
to save all the inputs that go into rt_boolweave and rt_boolfinal in the
ANSI C and OpenCL versions into an ASCII text file and compare the results
for differences. Not just the partitions, the intersections, and the
bitvectors as well. It will probably be a lot of information, so this could
be checked on a line by line basis (e.g. pick significant single lines with
boolean operations in them).
There also might be some hidden state stored in 'ap' that we forgot to
consider here. I'll talk about your latest patch in a separate e-mail.
Regards,
Hi,
The GSoC period is coming to a close and its time to wrap things up.
Unfortunately I haven't been able to finish everything that I had initially
planned. Your constant inputs have been of great help throughout the GSoC
period and I'm glad you agreed to mentor my project.
I hope to complete kernel boolean weaving at the very least. I've been
working on this lately and I'll attach a patch. I'm afraid the rest of the
boolean evaluation will have to wait till after GSoC.
For now, I'd be grateful if you help me get weaving up and running as soon
as possible. Let me know if you need anything clarified.
Thanks,
Param
The GSoC period is coming to a close and its time to wrap things up.
Unfortunately I haven't been able to finish everything that I had initially
planned. Your constant inputs have been of great help throughout the GSoC
period and I'm glad you agreed to mentor my project.
I hope to complete kernel boolean weaving at the very least. I've been
working on this lately and I'll attach a patch. I'm afraid the rest of the
boolean evaluation will have to wait till after GSoC.
For now, I'd be grateful if you help me get weaving up and running as soon
as possible. Let me know if you need anything clarified.
Thanks,
Param
--
Vasco Alexandre da Silva Costa
PhD in Computer Engineering (Computer Graphics)
Instituto Superior Técnico/University of Lisbon, Portugal
Vasco Alexandre da Silva Costa
PhD in Computer Engineering (Computer Graphics)
Instituto Superior Técnico/University of Lisbon, Portugal