It doesn't compile. It seems you forgot a function declaration in a header
file:
.../brlcad/trunk/src/librt/primitives/primitive_util.c: In function
‘clt_solid_pack’:
.../brlcad/trunk/src/librt/primitives/primitive_util.c:648:25: error:
implicit declaration of function ‘clt_epa_pack’
[-Werror=implicit-function-declaration]
case ID_EPA: size = clt_epa_pack(pool, stp); break;
^
On Sat, Mar 19, 2016 at 1:03 PM, Param Hanji <param.catchch...@gmail.com>
wrote:
> Here's the new patch.
>
>
> On Sat, Mar 19, 2016 at 6:32 PM Param Hanji <param.catchch...@gmail.com>
> wrote:
>
>> Oops I did manually edit the patch. I ran diff again and uploaded the
>> patch without changes. I also changed the ID used to 19.
>>
>> On Sat 19 Mar, 2016, 2:51 AM Vasco Alexandre da Silva Costa, <
>> vasco.co...@gmail.com> wrote:
>>
>>> On Fri, Mar 18, 2016 at 9:14 PM, Vasco Alexandre da Silva Costa <
>>> vasco.co...@gmail.com> wrote:
>>>
>>>> On Fri, Mar 18, 2016 at 1:17 PM, Param Hanji <
>>>> param.catchch...@gmail.com> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> On Thu, Mar 17, 2016 at 4:57 AM Vasco Alexandre da Silva Costa <
>>>>> vasco.co...@gmail.com> wrote:
>>>>>
>>>>>> On Wed, Mar 16, 2016 at 9:44 PM, Param Hanji <
>>>>>> param.catchch...@gmail.com> wrote:
>>>>>>
>>>>>> You will need a lot of time to port bool.c so you need to schedule
>>>>>> appropriately. That code is rife with gotos, structs with pointers, and
>>>>>> dynamic memory allocation. We don't want any of that in OpenCL. The
>>>>>> sooner
>>>>>> you start looking into that code the better. I did some patches last
>>>>>> summer
>>>>>> to remove many gotos from the existing code but there are still several
>>>>>> left.
>>>>>>
>>>>>> I suggest you read the presentation Sean linked to so you can get an
>>>>>> idea for what boolean operations and CSG are:
>>>>>> http://web.iitd.ac.in/~hegde/cad/lecture/L30_solidmod_basics.pdf
>>>>>>
>>>>>> The main functions of interest in bool.c are rt_bool_eval,
>>>>>> rt_boolweave, and rt_boolfinal. rt_boolweave and rt_bool_final do dynamic
>>>>>> memory allocations with linked lists but, if you read their code
>>>>>> carefully,
>>>>>> the maximum output size is bounded as a function of the input size. The
>>>>>> input is the list of intersection points. The size of the list of
>>>>>> intersection points is already being computed by rt.cl:count_hits().
>>>>>> So you can pre allocate a chunk of memory with the maximum possible
>>>>>> output
>>>>>> size and pass that array to your functions.
>>>>>> As for rt_bool_eval the boolean ops tree is stored as a tree of
>>>>>> pointers to structs. Can't have that. The rt_bool_eval function uses
>>>>>> gotos.
>>>>>> Can't have those either.
>>>>>>
>>>>>
>>>>> I'll start looking into the code as soon as i can. Is there any
>>>>> resource I can refer to get a brief high level understanding of how ray
>>>>> tracing occurs. I have no knowledge of computer graphics and even
>>>>> theoretical resources pertaining to the specific functions(eval, weave)
>>>>> would be helpful. I'll look out for some on my own too.
>>>>>
>>>>
>>>> If you want a brief idea of how the ray-tracing algorithm works you can
>>>> look at the relevant Wikipedia page. Wikipedia is a decent resource for
>>>> basic computer graphics knowledge:
>>>> https://en.wikipedia.org/wiki/Ray_tracing_%28graphics%29
>>>>
>>>> For knowing how CSG works, including the boolean ops, that lecture PDF
>>>> is a good resource.
>>>>
>>>>
>>>>> I started a patch in ANSI C to reimplement rt_bool_eval without gotos
>>>>> with a linearized tree, stored in an array, which can be easily copied to
>>>>> the compute device. You can find that patch here:
>>>>> https://sourceforge.net/p/brlcad/patches/417/
>>>>>
>>>>>> The rt_bool_eval patch #417 is functional but it still has some warts
>>>>>> in it.
>>>>>>
>>>>>>
>>>>> I noticed that you had proposed to design a new implementation of the
>>>>> boolean weave function in this pdf last year.
>>>>>
>>>>> https://drive.google.com/file/d/0B85Rkmt7rnCTZV9HNVIyZTRUMWM/view
>>>>>
>>>>> Was this discarded entirely? If not, does it make sense to change the
>>>>> way weave is performed currently to facilitate easy portability to OpenCL?
>>>>> Or should I just go about porting the existing code?
>>>>>
>>>>
>>>> That PDF you linked to is from a pre-proposal which was later changed
>>>> with output from Sean and the others. Eventually it was decided that we
>>>> would start with a first hit ray tracer and later on work on the boolean
>>>> evaluation proper to get working CSG. It just turns out that there was too
>>>> much effort involved in getting the object partitioning and the rendering
>>>> pipeline up to speed. Not to mention all those primitives... So I couldn't
>>>> finish work on boolean evaluation before the GSoC period ended. I just did
>>>> some cleanups (e.g. goto removal) on bool.c.
>>>>
>>>> Which is a good thing too or there would be little left to work on for
>>>> this GSoC. :-)
>>>>
>>>> Just ignore that PDF you got from Google Drive, which is something I
>>>> wrote before the GSoC 2015 period started, and read the advice I gave you
>>>> about how to tackle bool.c in this maling-list which includes the knowledge
>>>> I have now. I described a possible approach in detail here. I also said
>>>> which functions were most important (rt_bool_eval, rt_boolweave,
>>>> rt_bool_final)
>>>>
>>>
>>> PS: That project timeline in the PDF was shot down and I had to revise
>>> it. There was too much time doing research in it and not enough time
>>> actually coding. At the time I was unsure if the current bool weave
>>> algorithm BRL-CAD uses would make sense on a GPU or not. It turns out it
>>> does make sense but its like I said: you have to remove all the gotos,
>>> remove all pointers inside data structures, figure out the bounds of the
>>> memory you need a priori, and rethink the algorithm from those dynamic
>>> linked lists to a priori bounded arrays.
>>>
>>> --
>>> Vasco Alexandre da Silva Costa
>>> PhD in Computer Engineering (Computer Graphics)
>>> Instituto Superior Técnico/University of Lisbon, Portugal
>>>
>>> ------------------------------------------------------------------------------
>>> Transform Data into Opportunity.
>>> Accelerate data analysis in your applications with
>>> Intel Data Analytics Acceleration Library.
>>> Click to learn more.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
>>> _______________________________________________
>>> BRL-CAD Developer mailing list
>>> brlcad-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>>
>>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>
--
Vasco Alexandre da Silva Costa
PhD in Computer Engineering (Computer Graphics)
Instituto Superior Técnico/University of Lisbon, Portugal
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
