On Thu, Mar 26, 2015 at 6:49 PM, Vasco Alexandre da Silva Costa <
vasco.co...@gmail.com> wrote:
> Ok. The boolean weaving seems more interesting. Besides being possible to
> store similarly to a kd-tree with ropes, like you said, it's also possible
> that we can do some sort of static optimization
Ok. The boolean weaving seems more interesting. Besides being possible to
store similarly to a kd-tree with ropes, like you said, it's also possible
that we can do some sort of static optimization on the logic expressions
here. For example if we have an intersection operation and we miss one of
the
On Mar 21, 2015, at 12:55 PM, Vasco Alexandre da Silva Costa
wrote:
> I looked some more at the code and yeah the weave booleans step is branch
> heavy and has gotos in it. So this is most likely a bad candidate for GPU
> acceleration since a GPU will have like a quarter of the clockspeed and
On Sat, Mar 21, 2015 at 12:30 AM, Christopher Sean Morrison
...
> Something to consider, you could even propose *only* focusing on this
> aspect for GSoC. What I mean is that you could spend time restructuring
> the rt dispatch logic, which is something like
> forAllPixels->shootOneRay->traverse
On Mar 21, 2015, at 10:11 AM, Vasco Alexandre da Silva Costa
wrote:
> On Sat, Mar 21, 2015 at 7:19 AM, Christopher Sean Morrison
> wrote:
>
> If a callout is warranted in the schedule, there should be several instances
> of “test, debug, document” throughout your timeline, but still not one
On Sat, Mar 21, 2015 at 7:19 AM, Christopher Sean Morrison
wrote:
>
> If a callout is warranted in the schedule, there should be several
> instances of “test, debug, document” throughout your timeline, but still
> not one big 2.5 week one at the end. That’d be breadth-first
> waterfall-style cle
On Mar 20, 2015, at 11:29 PM, Vasco Alexandre da Silva Costa
wrote:
> I see. Then I need to examine this part better and propose a plan focused on
> this. I only have CS grad student like knowledge of CSG since most of my
> experience in RT is with acceleration structures and ray processing s
On Sat, Mar 21, 2015 at 12:30 AM, Christopher Sean Morrison
wrote:
...
> This may be a large task, possibly the bulk of your timeframe, as boolean
> weaving is one of the most complex aspects in BRL-CAD. Understanding it is
> almost certainly going to take you some time. However, you’ll probabl
On Mar 20, 2015, at 7:17 PM, Vasco Alexandre da Silva Costa
wrote:
> I came up with this tentative work plan for improving the OpenCL (CL) RT code
> on BRL-CAD:
Excellent!
> - Hook into shot and db load routines (hooks disabled by default) in order to
> capture ellipsoid primitives and shot
Hello,
I came up with this tentative work plan for improving the OpenCL (CL) RT
code on BRL-CAD:
- Hook into shot and db load routines (hooks disabled by default) in order
to capture ellipsoid primitives and shots into the CL side. Get familiar
with these top level interfaces of the code. (2 week
On Mar 6, 2015, at 12:58 PM, Vasco Alexandre da Silva Costa
wrote:
> You seem to be assuming BRL-CAD triangulates the NURBS surfaces before the
> ray-tracing step but I am not sure that is what they are doing.
That is most definitely not what we do.
> If you want to work on that check out th
On Mar 6, 2015, at 12:03 PM, benson chepkwony wrote:
> Since this subject talks about "Performance" I was going to ask:
> 1. First do you have/carry BrlCad with Manual Guide or a Guide book?
Unclear question… try these:
http://en.flossmanuals.net/contributors-guide-to-brl-cad/
Also, our HACKIN
On Fri, Mar 6, 2015 at 5:03 PM, benson chepkwony wrote:
> 3. Can we Modify/Edit these libraries such as: OpenCL, Opennurbs and
> Rhino3D folks or should we write a ray tracer from scratch, let say if we
> need to optimize it?
> 4. Is NURBS used to find ray intersection on objects? and what about
You mentioned that:
"There is some OpenCL prototype code in there for testing intersections with
ellipsoids. But this kind of architecture is not going to work performance
wise. It is allocating buffers and sending geometry data to the device (GPU or
whatever) on every single ray/primitive inter
On Mar 5, 2015, at 9:27 AM, Vasco Alexandre da Silva Costa
wrote:
> I see. But double precision floating point math is a lot slower than single
> precision on certain architectures like the lower end NVIDIA cards. e.g. the
> GeForce GTX 780 Ti has 5048 SP GFLOPS but only 210 DP GFLOPS. Even o
On Thu, Mar 5, 2015 at 6:24 AM, Christopher Sean Morrison
wrote:
>
> Astute observations. The OpenCL code was intentionally structured that
> way, not at all for performance obviously, but so we could perform a 1-1
> comparison to validate that the implementation behavior was correct. Our
> lib
On Mar 4, 2015, at 6:06 PM, Vasco Alexandre da Silva Costa
wrote:
> I have been reading the 'librt' source code.
Excellent!
> There is some OpenCL prototype code in there for testing intersections with
> ellipsoids. But this kind of architecture is not going to work performance
> wise. It i
Hello,
I have been reading the 'librt' source code.
There is some OpenCL prototype code in there for testing intersections with
ellipsoids. But this kind of architecture is not going to work performance
wise. It is allocating buffers and sending geometry data to the device (GPU
or whatever) on eve
On Feb 19, 2015, at 12:14 AM, Vasco Alexandre da Silva Costa
wrote:
> I was reading your mailing-list archives and noticed you guys are interested
> in a real-time RT visualization mode. I am currently doing my PhD on that
> topic and it just so happens that I ended up bumping into BRL-CAD. I
Hello,
I was reading your mailing-list archives and noticed you guys are
interested in a real-time RT visualization mode. I am currently doing my
PhD on that topic and it just so happens that I ended up bumping into
BRL-CAD. I have not made a code review to see what needs to be done.
AFAIK BRL-CAD
20 matches
Mail list logo
