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’ll probably be
> able to publish a paper on it when you’re done! :)
>
> 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->traverseScene->evalHits->weaveBooleans->colorizePixel
> that iterates over all pixels depth-first pipeline style. You’d
> restructure it into something like phase1:
> forAllPixels->shootOneRay->traverseScene->evalHits then phase2:
> CLweaveAllBooleans->CLcolorizePixels.
>
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 so I am
interested in seeing how you do the weaving. If there are any specific
optimizations, etc.
> If you got it working, you’d speed up ray tracing somewhere between 25-50%
> (as that is about how much time Boolean weaving takes) for all geometry,
> not just ellipsoids and it could go into immediate production use. It’d be
> in users hands. More on this later.
>
Yeah this seems to be a good idea. I wanted to do something that would
leave an actual performance improvement for users in the end. If this is
the critical compute intensive task then it is what needs to be addressed.
> With time-permitting, you could then work on the rest of the pipeline like
> implementing the top-level bundled dispatch and scene traversal
> acceleration, and primitive shot() routines.
>
...
> Sounds good, but know that we don’t actually use Nugrid. It’s faster for
> some scenes, slower for others — overall a wash. I think there’s also a
> bug somewhere in there. We use a custom BSP traversal for production work
> that is much more thoroughly tested and robust. Grids generally do much
> better on the GPU than they do on the CPU.
>
That is news to me. When i glanced at librt/shoot.c I saw a lot of
references to 'nugrid'. There's only one match for 'nubsp' and it is in a
comment. I guess I need to start peeling this and see what is actually
being called.
> - Cleanups, bugfixes, final tests, docs. (2.5 weeks)
>
>
> So the only planning concern is that this isn’t an incremental plan. It’s
> always a big red flag when a proposal has a big “test and document” at the
> end. If anything goes wrong or takes a couple weeks longer than planned
> with one of your early steps, we usually end up with something incomplete
> that cannot be shipped to users.
>
I'm used to doing incremental development with continuous integration. I
don't know how to do it any other way. I always test every step in order to
not break the code. But in my experience something always needs fine tuning
or debugging in the end. Also the docs always lag behind everything. Not
dedicating time specifically in the plan for docs usually means next to no
docs will be produced.
> Assume something will go wrong, that it will take longer, or your computer
> will explode next week. How would you change your approach so that users
> still get something? If you had to immediately stop working, there should
> be something usable (without requiring additional work by you or others to
> make it usable). This is an aspect of “coding complete” mentioned on
> http://brlcad.org/wiki/Google_Summer_of_Code/Acceptance#Write_complete_code
>
I was an OSS project maintainer (Freeciv) for close to 4 years. You never
ever break the code with a commit. BTW what's your process for patch code
reviews? You discuss patches on the mailing-list?
> Basically, this means thinking through how you can incrementally break up
> the task into phases where each phase gets tested and could be put into
> production use without detriment. It not only means you’re continually
> cleaning up, testing, and updating docs, it means you’re continually
> focused on the user and their benefit instead of your development comfort.
> If that means getting a little less done, that’s okay. Users will love you
> for it.
>
> My other concern was that your objective doesn’t result in a feature that
> affects users. Yay, devs can raytrace ellipsoids MUCH faster … and users
> see nothing. That’s why I’d suggest either focusing only on boolean
> weaving, or on bundled ray dispatch+traversal, or hit+result gathering, etc
> — something that could be put into immediate use, even if it’s not going to
> give the 10x speedup until the rest of the pipeline is converted. Changing
> BRL-CAD’s render pipeline to support this style of evaluation is going to
> be a lot of work.
>
I basically wanted to have a whole (optional) accelerated rendering path
from end to end so we could then work on the primitives afterwards when
this thing ends. But if weaving is that compute intensive in BRL-CAD you
are correct that it may make more sense to initially focus on just that. I
have not profiled BRL-CAD librt to know where the perf bottlenecks are but
you guys have actual experience with this.
p.s. Some technical libraries to consider in lieu of directly binding to
OpenCL:
>
> http://viennacl.sourceforge.net
> http://ddemidov.github.io/vexcl/
>
Nah. Don't want to add more build dependencies and I have experience with
OpenCL. :-)
OpenACC might be an alternative though.
Thx for the comments!
--
Vasco Alexandre da Silva Costa
PhD Student at Department of Information Systems and Computer Science
Instituto Superior Técnico/University of Lisbon, Portugal
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
