Hi,
I've made the detailed report of my work here:
https://github.com/sreyanshjainrkl/GSoC-18. I've also submitted OpenCL code
for VOL primitive apart from the others mentioned earlier in the project
plan. Do let me know your reviews on the report so that I can submit it for
my final evaluation.
Warm Regards,
*Sreyansh *
On Fri, Aug 10, 2018 at 10:54 AM Sreyansh Jain <sreyanshjai...@gmail.com>
wrote:
> Hi,
>
> In the rt_brep_shot patch, do I have to include the glue code which packs
> and unpacks it like it was done in case of primitives? If yes, will
> functions in this C++ snippet be similar to the one in C?
>
> On Fri, Aug 3, 2018, 1:07 AM Sreyansh Jain <sreyanshjai...@gmail.com>
> wrote:
>
>> How do I check which Domain() and Dimension() function to use? These are
>> defined in many opennurbs_*.cop but not in the ones they're referenced.
>> (For example, Domain() is used in On_Curve::EvTangent(..) but not defined
>> in opennurbs_curve.cpp).
>>
>> On Thu, Jul 26, 2018, 1:56 AM Vasco Alexandre da Silva Costa <
>> vasco.co...@gmail.com> wrote:
>>
>>> Basically make your own duplicates of the data in those structures that
>>> you actually use to perform the ray tracing evaluation for the shots.
>>> Similar to what is already done in the clt_*_pack functions.
>>> Since the BREP is a complex datastructure, looking at the BoT (bag of
>>> triangles) pack function should be a decent guide (it's a triangle list
>>> with a spatial triangle tree).
>>>
>>> So you need to convert the C++ BREP functions and methods called in the
>>> _shot function into C. You also want to serialize the C++ data structure
>>> into a memory buffer that will be passed over to the OpenCL side prior to
>>> that. It's likely you won't need to transfer all the data in the structure
>>> (this also happens with the intersection of other primitives). I typically
>>> convert first the _shot code and then the _prep code as typically a lot of
>>> the data computed on _prep isn't used on _shot. This way you only copy into
>>> the buffer the data that actually is need for it. This reduces the amount
>>> of OpenCL code you need to write.
>>>
>>> You can basically start by manually inlining any C++ function calls and
>>> methods invoked on _shot(). This will probably take you several steps of
>>> manually inlining and merging code. You can start with breaking down the
>>> invoked C++ classes into C++ functions and C++ structs with the data.
>>>
>>> Then you need to convert the C++ functions and C++ structs into C
>>> functions and C structs.
>>>
>>> To do that you'll need to eliminate any templates and replace uses of
>>> C++ standard library data structures with your own ANSI C code. Like I said
>>> the BoT code is a good example of a similarly complex data structure since
>>> it also features a list and a BVH tree.
>>>
>>> The BREP specific code in C++ should also be in:
>>> https://svn.code.sf.net/p/brlcad/code/brlcad/trunk/src/libbrep/
>>> https://svn.code.sf.net/p/brlcad/code/brlcad/trunk/include/libbrep/
>>> https://svn.code.sf.net/p/brlcad/code/brlcad/trunk/src/other/openNURBS/
>>>
>>> For example this is where BBNode and ON_Surface are declared:
>>> https://svn.code.sf.net/p/brlcad/code/brlcad/trunk/include/brep/bbnode.h
>>>
>>> https://svn.code.sf.net/p/brlcad/code/brlcad/trunk/src/other/openNURBS/opennurbs_surface.h
>>>
>>> The 'ON' prefix means something is from the openNURBS library.
>>>
>>> I suggest you use a C/C++ code browser to help you with this process.
>>> This way you can follow functions and methods or declarations across the
>>> code tree. For example I used Netbeans, in C/C++ mode, to code the hairier
>>> to port bits.
>>>
>>> Regards,
>>>
>>> On Wed, Jul 25, 2018 at 10:59 AM, Sreyansh Jain <
>>> sreyanshjai...@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> How do I go about using BBNode (details in BBNode.cpp) and ON_Surface
>>>> in this OpenCL code?
>>>>
>>>> On Thu, Jul 12, 2018, 11:32 PM Sreyansh Jain <sreyanshjai...@gmail.com>
>>>> wrote:
>>>>
>>>>> Okay. Google only needs the final documentation, I need not submit any
>>>>> code to them right now for second evaluation. I'm attaching the code here
>>>>> for your reference.
>>>>>
>>>>> On Sun, Jul 8, 2018 at 10:56 AM Vasco Alexandre da Silva Costa <
>>>>> vasco.co...@gmail.com> wrote:
>>>>>
>>>>>> Show me what you have, by posting it to the list here, then submit
>>>>>> the finished version.
>>>>>> If Google demands that you send them something, also send them the
>>>>>> code, AFAIK they only want the code in the final submission. But check.
>>>>>>
>>>>>> On Sun, Jul 8, 2018 at 6:44 AM, Sreyansh Jain <
>>>>>> sreyanshjai...@gmail.com> wrote:
>>>>>>
>>>>>>> The code is simply walking the list. It ignores the nodes with
>>>>>>> 'deleted' mode on.
>>>>>>> Also, for the second evaluation, do I submit an incomplete patch or
>>>>>>> submit later after completing?
>>>>>>>
>>>>>>> On Thu, Jul 5, 2018 at 8:23 PM Vasco Alexandre da Silva Costa <
>>>>>>> vasco.co...@gmail.com> wrote:
>>>>>>>
>>>>>>>> PS: Does the BREP code do indexed accesses to the data structure or
>>>>>>>> does it simply walk the list?
>>>>>>>>
>>>>>>>> On Thu, Jul 5, 2018 at 3:40 PM, Vasco Alexandre da Silva Costa <
>>>>>>>> vasco.co...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Instead of deleting items with 'delete' or 'free' simply add a
>>>>>>>>> 'deleted' bit to the nodes and set or reset it depending if the node
>>>>>>>>> is
>>>>>>>>> used or not.
>>>>>>>>> Then when walking the list, add an 'if' check to ignore the nodes
>>>>>>>>> with the 'deleted' bit on. Or you can move the 'deleted' nodes into a
>>>>>>>>> free
>>>>>>>>> nodes list.
>>>>>>>>>
>>>>>>>>> This is a technique often used on lazy memory
>>>>>>>>> allocation/de-allocation algorithms and with node memory pools.
>>>>>>>>>
>>>>>>>>> On Wed, Jul 4, 2018 at 5:45 PM, Sreyansh Jain <
>>>>>>>>> sreyanshjai...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I've converted most of the 'rt_brep_shot' code to C and some of
>>>>>>>>>> it to OpenCL already.
>>>>>>>>>>
>>>>>>>>>> I wanted to know the best way to implement the *erase* function.
>>>>>>>>>> I've taken 'hits' as pointer to array (*struct brep_hit *hits;*).
>>>>>>>>>> While *begin* and *end* are easily implemented, I'm stuck at
>>>>>>>>>> direct implementation of *erase*.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Warm Regards,
>>>>>>>>>>
>>>>>>>>>> Sreyansh
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Jun 21, 2018 at 9:19 PM Vasco Alexandre da Silva Costa <
>>>>>>>>>> vasco.co...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Basically the game plan to tackle NURBS I can think of is the
>>>>>>>>>>> one I sent to the list on March 20th:
>>>>>>>>>>>
>>>>>>>>>>> "With regards to BREP support, that should be more complex,
>>>>>>>>>>> since, for one, that is coded in C++ and also uses an auxiliary
>>>>>>>>>>> library
>>>>>>>>>>> also in C++.
>>>>>>>>>>> In order to run that on OpenCL 1.2 you would likely need to port
>>>>>>>>>>> C++ parts of the library to OpenCL/C, including the generic ray-BREP
>>>>>>>>>>> intersection code, and the primitive-BREP conversion functions for
>>>>>>>>>>> any
>>>>>>>>>>> primitives you need to support.
>>>>>>>>>>>
>>>>>>>>>>> It should also be possible, as a first step, to basically just
>>>>>>>>>>> make a function that serializes the NURBS surfaces, etc, of the
>>>>>>>>>>> BREP form of the primitive, pass that serialized form to the GPU,
>>>>>>>>>>> and then
>>>>>>>>>>> port just the generic ray-BREP intersection code, rather than doing
>>>>>>>>>>> the
>>>>>>>>>>> whole BREP conversion on the OpenCL side as well. i.e. serialize
>>>>>>>>>>> just the
>>>>>>>>>>> 'ON_Brep *' of the primitives, then pass that to the OpenCL side
>>>>>>>>>>> which then
>>>>>>>>>>> performs the actual intersections.
>>>>>>>>>>>
>>>>>>>>>>> For example, this is the Ellipsoid->BREP conversion function:
>>>>>>>>>>> (you need to serialize and send to OpenCL the output of this)
>>>>>>>>>>>
>>>>>>>>>>> https://svn.code.sf.net/p/brlcad/code/brlcad/trunk/src/librt/primitives/ell/ell_brep.cpp
>>>>>>>>>>>
>>>>>>>>>>> It outputs the 'ON_Brep *' for that primitive.
>>>>>>>>>>>
>>>>>>>>>>> This contains the generic ray-BREP intersection function
>>>>>>>>>>> 'rt_brep_shot': (what you need to convert to OpenCL)
>>>>>>>>>>>
>>>>>>>>>>> https://svn.code.sf.net/p/brlcad/code/brlcad/trunk/src/librt/primitives/brep/brep.cpp
>>>>>>>>>>>
>>>>>>>>>>> In case you decide to tackle this, it is probably best to first
>>>>>>>>>>> make a simplified ANSI C version of 'rt_brep_shot' since that
>>>>>>>>>>> should be
>>>>>>>>>>> easier to port to OpenCL/C."
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Jun 21, 2018 at 2:35 PM, Christopher Sean Morrison <
>>>>>>>>>>> brl...@mac.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Sreyansh,
>>>>>>>>>>>>
>>>>>>>>>>>> rt_brep_prep() and rt_brep_shot() are the entry points for
>>>>>>>>>>>> BREP/NURBS ray tracing. They use the openNURBS toolkit for data
>>>>>>>>>>>> structures
>>>>>>>>>>>> and our libbrep library for surface evaluation. That’s currently
>>>>>>>>>>>> a very
>>>>>>>>>>>> complicated C/C++ interaction between librt, libbrep, and
>>>>>>>>>>>> openNURBS.
>>>>>>>>>>>>
>>>>>>>>>>>> Vasco may have a better idea, but what may make sense is to
>>>>>>>>>>>> extract all of the evaluation functions in openNURBS used by
>>>>>>>>>>>> rt_brep_shot()
>>>>>>>>>>>> into libbrep. Then you'll only have to concern yourself with
>>>>>>>>>>>> OpenCL code
>>>>>>>>>>>> in one place and not worry about openNURBS for ray tracing — it
>>>>>>>>>>>> would only
>>>>>>>>>>>> be used for import/export (reading from and writing to disk).
>>>>>>>>>>>>
>>>>>>>>>>>> As for examples, openNURBS is the 3DM file format. So that
>>>>>>>>>>>> means you can import a 3DM model (e.g., from GrabCAD or Google
>>>>>>>>>>>> searches).
>>>>>>>>>>>> You could also just use our db/nist examples.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers!
>>>>>>>>>>>> Sean
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Jun 21, 2018, at 4:55 AM, Sreyansh Jain <
>>>>>>>>>>>> sreyanshjai...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> Can you give me a detailed procedure with examples on what
>>>>>>>>>>>> exactly to do for BREP support? Right now, I'm converting the
>>>>>>>>>>>> rt_brep_shot() function from C++ to C since that would be easy to
>>>>>>>>>>>> port to
>>>>>>>>>>>> OpenCL/C.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Sat, Jun 16, 2018 at 3:07 AM Sreyansh Jain <
>>>>>>>>>>>> sreyanshjai...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Also, I've worked it out that after installing Ubuntu 16.04,
>>>>>>>>>>>>> apart from the dependencies mentioned in
>>>>>>>>>>>>> https://brlcad.org/wiki/Compiling, you need to install package*
>>>>>>>>>>>>> libgl1-mesa-dev *for opengl support. It's working for me now
>>>>>>>>>>>>> in Ubuntu 16.04 as well. Can you check once and update?
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sat, Jun 16, 2018 at 2:16 AM Sreyansh Jain <
>>>>>>>>>>>>> sreyanshjai...@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> @Vasco: Thank you for the first evaluation results and
>>>>>>>>>>>>>> feedback. I'm done with both the METABALL and PIPE shot
>>>>>>>>>>>>>> routines. I'm
>>>>>>>>>>>>>> unable to do do OpenCL kernels for memory size computation for
>>>>>>>>>>>>>> bu_lists/arrays and allocation. Any previous example which I can
>>>>>>>>>>>>>> refer to?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> @Sean: I deployed the superell patch in my local system, but
>>>>>>>>>>>>>> results were not showing up. I'm sure they don't have any
>>>>>>>>>>>>>> unintended
>>>>>>>>>>>>>> changes. I've checked my code thoroughly. It should be my local
>>>>>>>>>>>>>> installation problem. Can you check and let me know if it's
>>>>>>>>>>>>>> working?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Jun 8, 2018 at 1:14 AM Christopher Sean Morrison <
>>>>>>>>>>>>>> brl...@mac.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sorry to hear your system crashed. Good job backing up your
>>>>>>>>>>>>>>> data. We need to get you set up so you are able to directly
>>>>>>>>>>>>>>> save changes
>>>>>>>>>>>>>>> as you go.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Have you made sure your changes still apply to trunk? You
>>>>>>>>>>>>>>> should manually inspect it also to make sure it doesn’t have
>>>>>>>>>>>>>>> unintended
>>>>>>>>>>>>>>> changes. If you have, I may be able to test it later today.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thank you for letting us know!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Cheers!
>>>>>>>>>>>>>>> Sean
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Jun 6, 2018, at 5:54 PM, Sreyansh Jain <
>>>>>>>>>>>>>>> sreyanshjai...@gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hey,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> My system crashed. While I've had the backup of most of the
>>>>>>>>>>>>>>> files, the very recent ones got lost. I wanted to inform that
>>>>>>>>>>>>>>> my work will
>>>>>>>>>>>>>>> be a bit slowed for few days while I'll be working on my
>>>>>>>>>>>>>>> friend's laptop
>>>>>>>>>>>>>>> and get mine fixed.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Also, did you check whether there's problem with my superell
>>>>>>>>>>>>>>> patch or did I not properly apply it in my system?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Tue, Jun 5, 2018, 9:11 PM Vasco Alexandre da Silva Costa <
>>>>>>>>>>>>>>> vasco.co...@gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Tue, Jun 5, 2018 at 7:29 AM, Sreyansh Jain <
>>>>>>>>>>>>>>>> sreyanshjai...@gmail.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Okay, let me look into it.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I've started with METABALL primitive, although it is
>>>>>>>>>>>>>>>>> incomplete I believe (metaball method). Should I retain both
>>>>>>>>>>>>>>>>> new and old
>>>>>>>>>>>>>>>>> code (shootalgo=2 and shootalgo=3) or just one in OpenCL?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> For starters just pick one of those. You can start with the
>>>>>>>>>>>>>>>> default (new) code.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Also, how do I take input/define *ap->a_onehit *,
>>>>>>>>>>>>>>>>> *rp->r_min* and *rp->r_max *in OpenCL?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You can start by just assuming that ap->a_onehit is TRUE.
>>>>>>>>>>>>>>>> If you do need that in the rendering phase, you can pass it as
>>>>>>>>>>>>>>>> a parameter
>>>>>>>>>>>>>>>> to the respective kernels in
>>>>>>>>>>>>>>>> https://svn.code.sf.net/p/brlcad/code/brlcad/trunk/src/librt/primitives/primitive_util.c:clt_frame()
>>>>>>>>>>>>>>>> which is called in
>>>>>>>>>>>>>>>> https://svn.code.sf.net/p/brlcad/code/brlcad/trunk/src/rt/do.c:clt_run()
>>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> As for rp->r_min, and rp->r_max IIRC those are the
>>>>>>>>>>>>>>>> rmin,rmax bounds determined in rt_in_rpp() in rt.cl. You
>>>>>>>>>>>>>>>> can get their values from bounds->p_min,bounds->p_max in
>>>>>>>>>>>>>>>> rt.cl:shootray().
>>>>>>>>>>>>>>>> You'll have to pass those to the shot() function and then the
>>>>>>>>>>>>>>>> respective
>>>>>>>>>>>>>>>> METABALL shot function.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>> -vasc
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>> --
>>> Vasco Alexandre da Silva Costa
>>> PhD in Computer Engineering (Computer Graphics)
>>> Instituto Superior Técnico/University of Lisbon, Portugal
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> BRL-CAD Developer mailing list
>>> brlcad-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>>
>>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
