On Mar 21, 2015, at 12:55 PM, Vasco Alexandre da Silva Costa
vasco.co...@gmail.com 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
On Mar 20, 2015, at 11:29 PM, Vasco Alexandre da Silva Costa
vasco.co...@gmail.com 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
On Mar 21, 2015, at 10:11 AM, Vasco Alexandre da Silva Costa
vasco.co...@gmail.com wrote:
On Sat, Mar 21, 2015 at 7:19 AM, Christopher Sean Morrison brl...@mac.com
wrote:
If a callout is warranted in the schedule, there should be several instances
of “test, debug, document” throughout
On Sat, Mar 21, 2015 at 12:30 AM, Christopher Sean Morrison brl...@mac.com
...
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
On Sat, Mar 21, 2015 at 7:19 AM, Christopher Sean Morrison brl...@mac.com
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
On Mar 20, 2015, at 7:17 PM, Vasco Alexandre da Silva Costa
vasco.co...@gmail.com 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
On Sat, Mar 21, 2015 at 12:30 AM, Christopher Sean Morrison brl...@mac.com
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 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
On Fri, Mar 6, 2015 at 5:03 PM, benson chepkwony bchepk...@att.net 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?
On Mar 6, 2015, at 12:58 PM, Vasco Alexandre da Silva Costa
vasco.co...@gmail.com 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 Mar 5, 2015, at 9:27 AM, Vasco Alexandre da Silva Costa
vasco.co...@gmail.com 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
On Thu, Mar 5, 2015 at 6:24 AM, Christopher Sean Morrison brl...@mac.com
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.
On Mar 4, 2015, at 6:06 PM, Vasco Alexandre da Silva Costa
vasco.co...@gmail.com 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
On Feb 19, 2015, at 12:14 AM, Vasco Alexandre da Silva Costa
vasco.co...@gmail.com 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
14 matches
Mail list logo
