On Wed, Mar 16, 2016 at 9:44 PM, Param Hanji <param.catchch...@gmail.com>
wrote:
> Yeah sending the output to the file fixed it. I'll add in my
> implementation for epa and submit a patch soon.
>
Oh ok. If you don't define an output that will happen. Now I can reproduce
that issue here as well.
I updated to the latest BRL-CAD SVN trunk here and found a couple of
compilation issues which didn't happen in Aug 31 2015. Those should be
fixed now.
When you make your patch also get a screenshot of the output and post a
link to it. This is graphics rendering after all. :-)
> Also, I was wondering if my GSOC proposal could include accelerating some
> more primitives(perhaps even all). This will buy me time to get use to the
> BRL-CAD codebase and also enable me to learn up about CSG and how the
> boolean evaluation is implemented. Parallelizing bool.c could happen later.
>
I agree that you should implement a couple of primitives in your proposal
but no more than 2-3. e.g. ETO and PART.
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 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.
Don't implement all the primitives since some are so complex you won't have
the time to do the boolean evaluation in GSoC which has higher priority.
e.g. porting PIPE alone could be half a GSoC project... Also don't
underestimate the effort it will take to implement boolean evaluation. The
code is not particularly long but its non-trivial to port to the OpenCL
programming model.
I also suggest you ignore the parts about FASTGEN support in bool.c, at
least to begin with, as it seems to be a legacy mode.
Still you should have the opinion from someone who's been here for longer
than me, like Sean, or Erik, or one of the other guys.
Regards,
-Vasco Costa
Just a thought. Thank you again.
>
> Best,
> Param
>
> On Thu, Mar 17, 2016 at 3:04 AM Vasco Alexandre da Silva Costa <
> vasco.co...@gmail.com> wrote:
>
>> On Wed, Mar 16, 2016 at 9:32 PM, Vasco Alexandre da Silva Costa <
>> vasco.co...@gmail.com> wrote:
>>
>>> On Wed, Mar 16, 2016 at 9:12 PM, Param Hanji <param.catchch...@gmail.com
>>> > wrote:
>>>
>>>> Yes, there was an error message on the terminal. Manually copying
>>>> everything to my current directory worked. Compilation starts but throws a
>>>> "pixel fb_write error". I think this is from rt/do.c from clt_run().
>>>>
>>> That's weird. If you are outputting to a file it shouldn't try to use
>>> the frame buffer. The frame buffer is used to render to the screen inside
>>> the MGED interface. Did you use something like:
>>>
>>> make tgc tgc
>>> e tgc ; rt -z 1 -o rt_tgc.pix
>>>
>>> I think Sean said you could use .png instead of .pix as well.
>>>
>>> Or did you use the MGED interface instead of choosing an output file?
>>> Try both approaches.
>>>
>>> I'm really unfamiliar with this bit of code. Any idea how to fix this?
>>>>
>>>
>>> I can't reproduce your issue here. Try the workarounds I suggested.
>>> fb_write is a wrapper around a bunch of possible backends so its
>>> possible you are hiting some poorly tested code path. I would need at least
>>> a GDB stack trace to start looking into it.
>>>
>>
>> i.e. it sounds like it rendered the image with OpenCL fine the problem is
>> with the output.
>>
>> --
>> 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
