Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

Your EPA patch works well on my system and the code looks fine so I applied
it to SVN.
I also commented out all writes to vpriv in the normal computation code
from all primitives to prevent normal computation errors. In case this is
causing any rendering issues.

Please check to see if you get the expected rendering output on your system
now.

On Tue, Mar 22, 2016 at 10:41 PM, Vasco Alexandre da Silva Costa <
vasco.co...@gmail.com> wrote:

> On Tue, Mar 22, 2016 at 7:32 AM, Param Hanji 
> wrote:
>
>> Hi
>>
>> Currently the blank screen issue happens only with EPA. The others work
>> fine.
>>
>
> So it doesn't happen with EHY anymore? It's kind of weird because this
> should have been fixed with the patch I made to invoke the normal
> generation function only once per hit point.
>
> This is the offending line from ehy_shot.cl:ehy_norm() which caused the
> issue:
>
>   hitp->hit_vpriv.x = scale;
>
>
> Because it modifies vpriv if you do a second normal computation you get
> bogus results.
>
>
>> On Tue 22 Mar, 2016, 9:28 AM Vasco Alexandre da Silva Costa, <
>> vasco.co...@gmail.com> wrote:
>>
>>> On Tue, Mar 22, 2016 at 3:17 AM, Param Hanji >> > wrote:
>>>
 I updated my svn repo to revision 67420. However, rt.cl wasn't changed
 and I still can't get a preview.
 Also, here's the patch.

>>>
>>> I made the change in  [r67361]
>>> 
>>> Please check (e.g. with diff if you are using that version of rt.cl).
>>>
>>> Does the no output issue in OpenCL mode (i.e. -z1) happen with all
>>> primitives, or just with specific primitives?
>>>
>>> As for your patch, it seems to be good at a cursory glance (I don't have
>>> access to Linux right now). So please submit the patch to the BRL-CAD
>>> ticketing system here:
>>> https://sourceforge.net/p/brlcad/patches/
>>>
>>> So we can process it in the standard way.
>>>
>>> --
>>> 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=278785351=/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=278785351=/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
>



-- 
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=278785351=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

On Tue, Mar 22, 2016 at 7:32 AM, Param Hanji 
wrote:

> Hi
>
> Currently the blank screen issue happens only with EPA. The others work
> fine.
>

So it doesn't happen with EHY anymore? It's kind of weird because this
should have been fixed with the patch I made to invoke the normal
generation function only once per hit point.

This is the offending line from ehy_shot.cl:ehy_norm() which caused the
issue:

hitp->hit_vpriv.x = scale;


Because it modifies vpriv if you do a second normal computation you get
bogus results.


> On Tue 22 Mar, 2016, 9:28 AM Vasco Alexandre da Silva Costa, <
> vasco.co...@gmail.com> wrote:
>
>> On Tue, Mar 22, 2016 at 3:17 AM, Param Hanji 
>> wrote:
>>
>>> I updated my svn repo to revision 67420. However, rt.cl wasn't changed
>>> and I still can't get a preview.
>>> Also, here's the patch.
>>>
>>
>> I made the change in  [r67361]
>> 
>> Please check (e.g. with diff if you are using that version of rt.cl).
>>
>> Does the no output issue in OpenCL mode (i.e. -z1) happen with all
>> primitives, or just with specific primitives?
>>
>> As for your patch, it seems to be good at a cursory glance (I don't have
>> access to Linux right now). So please submit the patch to the BRL-CAD
>> ticketing system here:
>> https://sourceforge.net/p/brlcad/patches/
>>
>> So we can process it in the standard way.
>>
>> --
>> 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=278785351=/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=278785351=/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=278785351=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

On Tue, Mar 22, 2016 at 6:12 AM, Christopher Sean Morrison 
wrote:

>
> > Right. But I think it's also necessary to change the CMakefiles in order
> to install the .cl files somewhere. I'm unsure where to place them.
>
> Probably best will be to just put them in some subdir of our data dir for
> now.  We’ll probably eventually want to set things up in the
> offline-compilation manner where binary kernels are loaded like regular
> libs,


Offline-compilation in OpenCL 1.2 and 2.0 is kind of problematic. IIRC SPIR
is an OpenCL extension (i.e. may or may not be provided by an
implementation). If you don't have SPIR then the binary compiled output is
some architecture dependent file which may not work on your compute device.
OpenCL 2.1 is supposed to come with mandatory SPIR-V support, i.e. a kind
of bytecode, in the core spec but there aren't many implementations of the
spec right now. In fact I don't know of any vendor implementation of the
2.1 spec right now.


> but JIT compiles with sources in the install tree will work fine too.
>

Yes. I think this is the most viable option right now. Until SPIR-V support
is widespread.


> A line like this in the CMakeFiles.txt should do the trick:
>
> set(CL_FILES
>   file1.cl
>   file2.cl
> )
> BRLCAD_ADDDATA(CL_FILES OpenCL)
>
> This should install the files into DATA_DIR/OpenCL, which on a default
> install will be something like /usr/brlcad/dev-7.25.0/share/OpenCL/.
>
> In the C loading code, you can get the path to the file like this:
>
> const char *clfile1 = bu_brlcad_data(“OpenCL/file1.cl”, 0);
>
> You can also just look up the OpenCL dir and manually append / search for
> files, e.g., with bu_file_exists().
>

Thanks! I'll look at this when I get some time available to work on it.

-- 
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=278785351=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Param Hanji]

Hi

Currently the blank screen issue happens only with EPA. The others work
fine.

On Tue 22 Mar, 2016, 9:28 AM Vasco Alexandre da Silva Costa, <
vasco.co...@gmail.com> wrote:

> On Tue, Mar 22, 2016 at 3:17 AM, Param Hanji 
> wrote:
>
>> I updated my svn repo to revision 67420. However, rt.cl wasn't changed
>> and I still can't get a preview.
>> Also, here's the patch.
>>
>
> I made the change in  [r67361]
> 
> Please check (e.g. with diff if you are using that version of rt.cl).
>
> Does the no output issue in OpenCL mode (i.e. -z1) happen with all
> primitives, or just with specific primitives?
>
> As for your patch, it seems to be good at a cursory glance (I don't have
> access to Linux right now). So please submit the patch to the BRL-CAD
> ticketing system here:
> https://sourceforge.net/p/brlcad/patches/
>
> So we can process it in the standard way.
>
> --
> 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=278785351=/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=278785351=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Christopher Sean Morrison]

> Right. But I think it's also necessary to change the CMakefiles in order to 
> install the .cl files somewhere. I'm unsure where to place them.

Probably best will be to just put them in some subdir of our data dir for now.  
We’ll probably eventually want to set things up in the offline-compilation 
manner where binary kernels are loaded like regular libs, but JIT compiles with 
sources in the install tree will work fine too.

A line like this in the CMakeFiles.txt should do the trick:

set(CL_FILES
  file1.cl
  file2.cl
)
BRLCAD_ADDDATA(CL_FILES OpenCL)

This should install the files into DATA_DIR/OpenCL, which on a default install 
will be something like /usr/brlcad/dev-7.25.0/share/OpenCL/.

In the C loading code, you can get the path to the file like this:

const char *clfile1 = bu_brlcad_data(“OpenCL/file1.cl”, 0);

You can also just look up the OpenCL dir and manually append / search for 
files, e.g., with bu_file_exists().

Cheers!
Sean



--
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=278785351=/4140
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

On Tue, Mar 22, 2016 at 3:17 AM, Param Hanji 
wrote:

> I updated my svn repo to revision 67420. However, rt.cl wasn't changed
> and I still can't get a preview.
> Also, here's the patch.
>

I made the change in  [r67361]

Please check (e.g. with diff if you are using that version of rt.cl).

Does the no output issue in OpenCL mode (i.e. -z1) happen with all
primitives, or just with specific primitives?

As for your patch, it seems to be good at a cursory glance (I don't have
access to Linux right now). So please submit the patch to the BRL-CAD
ticketing system here:
https://sourceforge.net/p/brlcad/patches/

So we can process it in the standard way.

-- 
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=278785351=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Param Hanji]

I updated my svn repo to revision 67420. However, rt.cl wasn't changed and
I still can't get a preview.
Also, here's the patch.

On Tue, Mar 22, 2016 at 1:27 AM Vasco Alexandre da Silva Costa <
vasco.co...@gmail.com> wrote:

> On Mon, Mar 21, 2016 at 4:58 AM, Christopher Sean Morrison  > wrote:
>
>>
>> Still no image preview?
>>
>>
>> > PS: This should be improved with some kind of smart way to find the
>> directory where the files are in, or at least by looking the directory up
>> in an environment variable, but the current clt_init and clt_read_code
>> aren't that smart. You should have got some output error message like
>> "failed to read OpenCL code file (solver.c)”.
>>
>> BRL-CAD’s libbu library provides API for doing that, bu_brlcad_dir()
>> and/or bu_brlcad_data().  See include/bu/file.h for details and examples
>> throughout the codebase.
>>
>
> Right. But I think it's also necessary to change the CMakefiles in order
> to install the .cl files somewhere. I'm unsure where to place them.
>
> --
> 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=278785351=/4140
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
diff -Nurd brlcad-master/src/librt/librt_private.h brlcad-branch/src/librt/librt_private.h
--- brlcad-master/src/librt/librt_private.h	2016-03-19 08:29:47.574128546 +0530
+++ brlcad-branch/src/librt/librt_private.h	2016-03-19 18:04:13.440772786 +0530
@@ -194,6 +194,7 @@
 CLT_DECLARE_INTERFACE(sph);
 CLT_DECLARE_INTERFACE(ehy);
 CLT_DECLARE_INTERFACE(bot);
+CLT_DECLARE_INTERFACE(epa);
 
 extern size_t clt_bot_pack(struct bu_pool *pool, struct soltab *stp);
 #endif
diff -Nurd brlcad-master/src/librt/primitives/common.cl brlcad-branch/src/librt/primitives/common.cl
--- brlcad-master/src/librt/primitives/common.cl	2016-03-19 08:29:46.034128528 +0530
+++ brlcad-branch/src/librt/primitives/common.cl	2016-03-19 17:50:37.532763138 +0530
@@ -114,6 +114,7 @@
 struct arb_specific;
 struct ehy_specific;
 struct ell_specific;
+struct epa_specific;
 struct rec_specific;
 struct sph_specific;
 struct tgc_specific;
@@ -123,6 +124,7 @@
 extern int bot_shot(RESULT_TYPE *res, const double3 r_pt, double3 r_dir, const uint idx, global const uchar *args);
 extern int ehy_shot(RESULT_TYPE *res, const double3 r_pt, const double3 r_dir, const uint idx, global const struct ehy_specific *ehy);
 extern int ell_shot(RESULT_TYPE *res, const double3 r_pt, const double3 r_dir, const uint idx, global const struct ell_specific *ell);
+extern int epa_shot(RESULT_TYPE *res, const double3 r_pt, const double3 r_dir, const uint idx, global const struct epa_specific *epa);
 extern int rec_shot(RESULT_TYPE *res, const double3 r_pt, const double3 r_dir, const uint idx, global const struct rec_specific *rec);
 extern int sph_shot(RESULT_TYPE *res, const double3 r_pt, const double3 r_dir, const uint idx, global const struct sph_specific *sph);
 extern int tgc_shot(RESULT_TYPE *res, const double3 r_pt, const double3 r_dir, const uint idx, global const struct tgc_specific *tgc);
@@ -132,6 +134,7 @@
 extern void bot_norm(struct hit *hitp, const double3 r_pt, const double3 r_dir, global const uchar *args);
 extern void ehy_norm(struct hit *hitp, const double3 r_pt, const double3 r_dir, global const struct ehy_specific *ehy);
 extern void ell_norm(struct hit *hitp, const double3 r_pt, const double3 r_dir, global const struct ell_specific *ell);
+extern void epa_norm(struct hit *hitp, const double3 r_pt, const double3 r_dir, global const struct epa_specific *epa);
 extern void rec_norm(struct hit *hitp, const double3 r_pt, const double3 r_dir, global const struct rec_specific *rec);
 extern void sph_norm(struct hit *hitp, const double3 r_pt, const double3 r_dir, global const struct sph_specific *sph);
 extern void tgc_norm(struct hit *hitp, const double3 r_pt, const double3 r_dir, global const struct tgc_specific *tgc);
diff -Nurd brlcad-master/src/librt/primitives/epa/epa.c brlcad-branch/src/librt/primitives/epa/epa.c
--- brlcad-master/src/librt/primitives/epa/epa.c	2016-03-19 08:29:47.454128545 +0530
+++ brlcad-branch/src/librt/primitives/epa/epa.c	2016-03-22 08:36:15.434247123 +0530
@@ -184,6 +184,37 @@
 { {'\0', '\0', '\0', '\0'}, 0, (char *)NULL, 0, BU_STRUCTPARSE_FUNC_NULL, NULL, NULL }
 };
 
+
+#ifdef USE_OPENCL
+/* largest data members first */
+struct clt_epa_specific {
+cl_double epa_V[3]; /* vector to epa origin */
+cl_double epa_Hunit[3]; /* unit H vector */
+cl_double epa_SoR[16];  /* 

Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

On Mon, Mar 21, 2016 at 4:58 AM, Christopher Sean Morrison 
wrote:

>
> Still no image preview?
>
>
> > PS: This should be improved with some kind of smart way to find the
> directory where the files are in, or at least by looking the directory up
> in an environment variable, but the current clt_init and clt_read_code
> aren't that smart. You should have got some output error message like
> "failed to read OpenCL code file (solver.c)”.
>
> BRL-CAD’s libbu library provides API for doing that, bu_brlcad_dir()
> and/or bu_brlcad_data().  See include/bu/file.h for details and examples
> throughout the codebase.
>

Right. But I think it's also necessary to change the CMakefiles in order to
install the .cl files somewhere. I'm unsure where to place them.

-- 
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=278785351=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

On Mon, Mar 21, 2016 at 12:21 PM, Param Hanji 
wrote:

>
>
> On Mon, Mar 21, 2016 at 10:28 AM Christopher Sean Morrison 
> wrote:
>
>>
>> Still no image preview?
>>
>>
>>
> Nope. I still get a blank image. I tried generating the png with the -l2
> option as well as the -W as suggested. Still no luck
>

Did you do an SVN update? Everything is working here and I'm also using the
AMD APP SDK.
If you copied the .cl files over to your current directory instead of just
linking to them, I did some changes to rt.cl.

-- 
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=278785351=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

On Mon, Mar 21, 2016 at 7:42 AM, Param Hanji 
wrote:

> Hello,
>
> Ok, now the code compiles! I checked the code and functionally it looks
>> good. But you need to indent the code according to the BRL-CAD coding
>> style. e.g. indent the code with 4 spaces and use regular tabs with 8
>> spaces. This is particularly noticeable in the .cl file.
>>
>> The style rules are under "CODING STYLE & STANDARDS" in the HACKING file
>> of BRL-CAD SVN trunk.
>>
>>
> Okay I updated the preferences in my editor. Would you like me to generate
> another patch?
>

Yes.

-- 
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=278785351=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Christopher Sean Morrison]

Still no image preview? 


> PS: This should be improved with some kind of smart way to find the directory 
> where the files are in, or at least by looking the directory up in an 
> environment variable, but the current clt_init and clt_read_code aren't that 
> smart. You should have got some output error message like "failed to read 
> OpenCL code file (solver.c)”.

BRL-CAD’s libbu library provides API for doing that, bu_brlcad_dir() and/or 
bu_brlcad_data().  See include/bu/file.h for details and examples throughout 
the codebase.

Cheers!
Sean


--
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=278785351=/4140
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

On Sun, Mar 20, 2016 at 7:32 PM, Vasco Alexandre da Silva Costa <
vasco.co...@gmail.com> wrote:

> Ok, now the code compiles! I checked the code and functionally it looks
> good. But you need to indent the code according to the BRL-CAD coding
> style. e.g. indent the code with 4 spaces and use regular tabs with 8
> spaces. This is particularly noticeable in the .cl file.
>
> The style rules are under "CODING STYLE & STANDARDS" in the HACKING file
> of BRL-CAD SVN trunk.
>

PS: Any decent text editor should be able to be configured to automatically
indent the code appropriately. All files in BRL-CAD comes with Emacs
indentation directives. I use Vim but there are plenty of other text
editors around.


> On Sun, Mar 20, 2016 at 2:58 AM, Param Hanji 
> wrote:
>
>> Fixed it
>>
>>
>> On Sun, Mar 20, 2016 at 6:47 AM Vasco Alexandre da Silva Costa <
>> vasco.co...@gmail.com> wrote:
>>
>>> 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 >> > wrote:
>>>
 Here's the new patch.


 On Sat, Mar 19, 2016 at 6:32 PM Param Hanji 
 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:
 

Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

Ok, now the code compiles! I checked the code and functionally it looks
good. But you need to indent the code according to the BRL-CAD coding
style. e.g. indent the code with 4 spaces and use regular tabs with 8
spaces. This is particularly noticeable in the .cl file.

The style rules are under "CODING STYLE & STANDARDS" in the HACKING file of
BRL-CAD SVN trunk.

On Sun, Mar 20, 2016 at 2:58 AM, Param Hanji 
wrote:

> Fixed it
>
>
> On Sun, Mar 20, 2016 at 6:47 AM Vasco Alexandre da Silva Costa <
> vasco.co...@gmail.com> wrote:
>
>> 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 
>> wrote:
>>
>>> Here's the new patch.
>>>
>>>
>>> On Sat, Mar 19, 2016 at 6:32 PM Param Hanji 
>>> 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 

Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

On Thu, Mar 17, 2016 at 7:54 PM, Vasco Alexandre da Silva Costa <
vasco.co...@gmail.com> wrote:

> On Thu, Mar 17, 2016 at 7:47 PM, Christopher Sean Morrison  > wrote:
>
>>
>>
>> On Mar 17, 2016, at 05:33 AM, Param Hanji 
>> wrote:
>>
>> Great. I'm happy to help!
>> Also is ehy running fine in OpenCL mode? My generated PNG is just a blank
>> black screen with no figure. The terminal logs don't seem to indicate
>> anything wrong. Maybe ehy_shot.cl has a bug?
>>
>>
>> 1) Does that exact same ehy render correctly in non-OpenCL mode?
>> 2) Does another primitive (e.g., an ell via mged> make ell ell) render
>> correctly in OpenCL mode
>>
>
> The problem is the material lighting code. The results are not the same.
> In OpenCL mode it renders that ehy in a really dark color and you nearly
> miss it. If you render the ehy in surface normals lighting mode (i.e. rt
> -z1 -l2) the output is as expected here.
>

The problem was more complicated that I thought. It turns out the OpenCL
code was calling the ehy normal computation routine more than once. It
turns out that routine (ehy_norm) both depends on hit_vpriv to compute the
proper normal, and clobbers hit_vpriv after normal computation to store
some temporary value for later computation of curvatures.
It just so happens that this only happened in the Full lighting mode.

I put a fix for this on SVN trunk.

-- 
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=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

On Thu, Mar 17, 2016 at 7:47 PM, Christopher Sean Morrison 
wrote:

>
>
> On Mar 17, 2016, at 05:33 AM, Param Hanji 
> wrote:
>
> Great. I'm happy to help!
> Also is ehy running fine in OpenCL mode? My generated PNG is just a blank
> black screen with no figure. The terminal logs don't seem to indicate
> anything wrong. Maybe ehy_shot.cl has a bug?
>
>
> 1) Does that exact same ehy render correctly in non-OpenCL mode?
> 2) Does another primitive (e.g., an ell via mged> make ell ell) render
> correctly in OpenCL mode
>

The problem is the material lighting code. The results are not the same. In
OpenCL mode it renders that ehy in a really dark color and you nearly miss
it. If you render the ehy in surface normals lighting mode (i.e. rt -z1
-l2) the output is as expected here.

>
> Cheers!
> Sean
>
>
>
> --
> 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=/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=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

On Wed, Mar 16, 2016 at 8:15 PM, Param Hanji 
wrote:

> Hi Vasco Costa,
>
> Yes -z 1 did it. :)
>
> Now fopen() throws an error! Function clt_read_code() in primitiive_util.c
> fopen() returns a NULL. I included  and printed the error as
> described here
>
>
> http://stackoverflow.com/questions/8633909/what-is-the-reason-for-fopens-failure-to-open-a-file
>
> The error is 2 which means "No such file or directory" according to
>
> http://www.thegeekstuff.com/2010/10/linux-error-codes/
>
> This is rather puzzling because I can see solver.cl present in the same
> directory as primitive_util.c. Moreover, fopen() is a function that I've
> used time and time again and I haven't this kind of error before. I also
> verified that the file has read access.
>
> Thank you for your patience! I'm just running into issue after issue. I
> really appreciate your guidance.
>

Yeah the OpenCL support is kind of experimental. More than half of the
trouble is getting OpenCL itself to be properly configured on your system.
I expect the distros to eventually get that right but it's sure taking a
while.

I know what's the problem here. It's searching for the .cl files to compile
at run-time. The .cl files are supposed to be installed to some directory
in the current path.

Just manually copy or link the .cl files to your current directory '.'. The
list of .cl files you need to copy or link to is:

solver.cl
arb8_shot.clbot_shot.clehy_shot.clell_shot.clsph_shot.clrec_shot.cltgc_shot.cltor_shot.cl
rt.cl

The current paths should be something like librt/primitives/*.cl ,
librt/primitives/*/*_shot.cl
You should just place them all in the current directory.


> Best,
> Param
>
> On Thu, Mar 17, 2016 at 1:15 AM Vasco Alexandre da Silva Costa <
> vasco.co...@gmail.com> wrote:
>
>> On Wed, Mar 16, 2016 at 7:36 PM, Vasco Alexandre da Silva Costa <
>> vasco.co...@gmail.com> wrote:
>>
>>> On Wed, Mar 16, 2016 at 7:28 PM, Param Hanji >> > wrote:
>>>
 Hi,

 Installing the AMD SDK gave me OpenCL 1.2 support. I managed to
 configure cmake using cmake-gui and built successfully. But raytrace still
 doesn't happen on my GPU. By adding fprintf statements, I found out that
 execution does indeed enter the #ifdef USE_OPENCL block at rt/main.c.
 However the if following block (if (opencl_mode)) is not entered.

 opencl_mode is set at opt.c at case: 'z'. I still don't know why its
 value doesn't change even if use -z option.

>>>
>>> I think it is '-z 1'. The '-z' option currently requires a numeric
>>> argument.
>>> '1' to enable OpenCL mode and '0' to disable it.
>>>
>>
>> The code is like this (opt.c):
>>
>>  case 'z':
>>  opencl_mode = atoi( bu_optarg );
>>  break;
>>
>> I did it this way because I added a toggle button in the MGED File ->
>> Raytrace panel where you can enable or disable OpenCL mode. The toggle is
>> either '0' or '1' depending on its status.
>>
>> --
>> 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=/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=/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=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Param Hanji]

Fixed it

On Sun, Mar 20, 2016 at 6:47 AM Vasco Alexandre da Silva Costa <
vasco.co...@gmail.com> wrote:

> 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 
> wrote:
>
>> Here's the new patch.
>>
>>
>> On Sat, Mar 19, 2016 at 6:32 PM Param Hanji 
>> 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 

Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

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 
wrote:

> Here's the new patch.
>
>
> On Sat, Mar 19, 2016 at 6:32 PM Param Hanji 
> 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. :-)

Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

On Wed, Mar 16, 2016 at 7:36 PM, Vasco Alexandre da Silva Costa <
vasco.co...@gmail.com> wrote:

> On Wed, Mar 16, 2016 at 7:28 PM, Param Hanji 
> wrote:
>
>> Hi,
>>
>> Installing the AMD SDK gave me OpenCL 1.2 support. I managed to configure
>> cmake using cmake-gui and built successfully. But raytrace still doesn't
>> happen on my GPU. By adding fprintf statements, I found out that execution
>> does indeed enter the #ifdef USE_OPENCL block at rt/main.c. However the if
>> following block (if (opencl_mode)) is not entered.
>>
>> opencl_mode is set at opt.c at case: 'z'. I still don't know why its
>> value doesn't change even if use -z option.
>>
>
> I think it is '-z 1'. The '-z' option currently requires a numeric
> argument.
> '1' to enable OpenCL mode and '0' to disable it.
>

The code is like this (opt.c):

case 'z':
opencl_mode = atoi( bu_optarg );
break;

I did it this way because I added a toggle button in the MGED File ->
Raytrace panel where you can enable or disable OpenCL mode. The toggle is
either '0' or '1' depending on its status.

-- 
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=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

On Wed, Mar 16, 2016 at 8:26 PM, Vasco Alexandre da Silva Costa <
vasco.co...@gmail.com> wrote:

> On Wed, Mar 16, 2016 at 8:15 PM, Param Hanji 
> wrote:
>
>> Hi Vasco Costa,
>>
>> Yes -z 1 did it. :)
>>
>> Now fopen() throws an error! Function clt_read_code() in
>> primitiive_util.c fopen() returns a NULL. I included  and printed
>> the error as described here
>>
>>
>> http://stackoverflow.com/questions/8633909/what-is-the-reason-for-fopens-failure-to-open-a-file
>>
>> The error is 2 which means "No such file or directory" according to
>>
>> http://www.thegeekstuff.com/2010/10/linux-error-codes/
>>
>> This is rather puzzling because I can see solver.cl present in the same
>> directory as primitive_util.c. Moreover, fopen() is a function that I've
>> used time and time again and I haven't this kind of error before. I also
>> verified that the file has read access.
>>
>> Thank you for your patience! I'm just running into issue after issue. I
>> really appreciate your guidance.
>>
>
> Yeah the OpenCL support is kind of experimental. More than half of the
> trouble is getting OpenCL itself to be properly configured on your system.
> I expect the distros to eventually get that right but it's sure taking a
> while.
>
> I know what's the problem here. It's searching for the .cl files to
> compile at run-time. The .cl files are supposed to be installed to some
> directory in the current path.
>
> Just manually copy or link the .cl files to your current directory '.'.
> The list of .cl files you need to copy or link to is:
> solver.cl
>
> arb8_shot.cl
> bot_shot.cl
> ehy_shot.cl
> ell_shot.cl
> sph_shot.cl
> rec_shot.cl
> tgc_shot.cl
> tor_shot.cl
>
> rt.cl
>


> The current paths should be something like librt/primitives/*.cl ,
> librt/primitives/*/*_shot.cl
> You should just place them all in the current directory.
>

PS: This should be improved with some kind of smart way to find the
directory where the files are in, or at least by looking the directory up
in an environment variable, but the current clt_init and clt_read_code
aren't that smart. You should have got some output error message like
"failed to read OpenCL code file (solver.c)".


>
>
>> Best,
>> Param
>>
>> On Thu, Mar 17, 2016 at 1:15 AM Vasco Alexandre da Silva Costa <
>> vasco.co...@gmail.com> wrote:
>>
>>> On Wed, Mar 16, 2016 at 7:36 PM, Vasco Alexandre da Silva Costa <
>>> vasco.co...@gmail.com> wrote:
>>>
 On Wed, Mar 16, 2016 at 7:28 PM, Param Hanji <
 param.catchch...@gmail.com> wrote:

> Hi,
>
> Installing the AMD SDK gave me OpenCL 1.2 support. I managed to
> configure cmake using cmake-gui and built successfully. But raytrace still
> doesn't happen on my GPU. By adding fprintf statements, I found out that
> execution does indeed enter the #ifdef USE_OPENCL block at rt/main.c.
> However the if following block (if (opencl_mode)) is not entered.
>
> opencl_mode is set at opt.c at case: 'z'. I still don't know why its
> value doesn't change even if use -z option.
>

 I think it is '-z 1'. The '-z' option currently requires a numeric
 argument.
 '1' to enable OpenCL mode and '0' to disable it.

>>>
>>> The code is like this (opt.c):
>>>
>>> case 'z':
>>> opencl_mode = atoi( bu_optarg );
>>> break;
>>>
>>> I did it this way because I added a toggle button in the MGED File ->
>>> Raytrace panel where you can enable or disable OpenCL mode. The toggle is
>>> either '0' or '1' depending on its status.
>>>
>>> --
>>> 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=/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=/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
>



-- 
Vasco Alexandre da Silva Costa
PhD in Computer Engineering (Computer Graphics)
Instituto Superior 

Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

On Wed, Mar 16, 2016 at 9:12 PM, Param Hanji 
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.

-- 
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=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Param Hanji]

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 
> 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.

>
> 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?

Best,
Param
--
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=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Param Hanji]

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 
>> 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 

Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

On Wed, Mar 16, 2016 at 9:44 PM, Param Hanji 
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 >> > 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.
>> 

Re: [brlcad-devel] Help understanding code

[Christopher Sean Morrison]

 --
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=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Param Hanji]

Hi,

My parallel epa still shows up a black screen. Is there anything wrong with
my code? I looked hard for errors but couldn't find anything.I'll send you
my patch.

Thanks!


On Fri, Mar 18, 2016 at 3:06 AM Vasco Alexandre da Silva Costa <
vasco.co...@gmail.com> wrote:

> On Thu, Mar 17, 2016 at 7:54 PM, Vasco Alexandre da Silva Costa <
> vasco.co...@gmail.com> wrote:
>
>> On Thu, Mar 17, 2016 at 7:47 PM, Christopher Sean Morrison <
>> brl...@mac.com> wrote:
>>
>>>
>>>
>>> On Mar 17, 2016, at 05:33 AM, Param Hanji 
>>> wrote:
>>>
>>> Great. I'm happy to help!
>>> Also is ehy running fine in OpenCL mode? My generated PNG is just a
>>> blank black screen with no figure. The terminal logs don't seem to indicate
>>> anything wrong. Maybe ehy_shot.cl has a bug?
>>>
>>>
>>> 1) Does that exact same ehy render correctly in non-OpenCL mode?
>>> 2) Does another primitive (e.g., an ell via mged> make ell ell) render
>>> correctly in OpenCL mode
>>>
>>
>> The problem is the material lighting code. The results are not the same.
>> In OpenCL mode it renders that ehy in a really dark color and you nearly
>> miss it. If you render the ehy in surface normals lighting mode (i.e. rt
>> -z1 -l2) the output is as expected here.
>>
>
> The problem was more complicated that I thought. It turns out the OpenCL
> code was calling the ehy normal computation routine more than once. It
> turns out that routine (ehy_norm) both depends on hit_vpriv to compute the
> proper normal, and clobbers hit_vpriv after normal computation to store
> some temporary value for later computation of curvatures.
> It just so happens that this only happened in the Full lighting mode.
>
> I put a fix for this on SVN trunk.
>
> --
> 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=/4140
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
--- src/librt/librt_private.h	2016-03-15 13:28:31.225331492 +0530
+++ src/librt/librt_private.h	2016-03-15 14:14:31.773364136 +0530
@@ -194,7 +194,6 @@
 CLT_DECLARE_INTERFACE(sph);
 CLT_DECLARE_INTERFACE(ehy);
 CLT_DECLARE_INTERFACE(bot);
+CLT_DECLARE_INTERFACE(epa);
 
 extern size_t clt_bot_pack(struct bu_pool *pool, struct soltab *stp);
 #endif
--- src/librt/primitives/epa/epa.c	2016-03-07 09:20:47.247217894 +0530
+++ src/librt/primitives/epa/epa.c	2016-03-13 15:55:46.0 +0530
@@ -184,36 +184,6 @@
 { {'\0', '\0', '\0', '\0'}, 0, (char *)NULL, 0, BU_STRUCTPARSE_FUNC_NULL, NULL, NULL }
 };

+
+#ifdef USE_OPENCL
+/* largest data members first */
+struct clt_epa_specific {
+	cl_double epa_V[3]; /* vector to epa origin */
+	cl_double epa_Hunit[3]; /* unit H vector */
+	cl_double epa_SoR[16];  /* Scale(Rot(vect)) */
+	cl_double epa_invRoS[16];   /* invRot(Scale(vect)) */
+};
+
+size_t
+clt_epa_pack(struct bu_pool *pool, struct soltab *stp)
+{
+	struct epa_specific *epa =
+		(struct epa_specific *)stp->st_specific;
+	struct clt_epa_specific *args;
+
+	const size_t size = sizeof(*args);
+	args = (struct clt_epa_specific*)bu_pool_alloc(pool, 1, size);
+
+	VMOVE(args->epa_V, epa->epa_V);
+	VMOVE(args->epa_Hunit, epa->epa_Hunit);
+	MAT_COPY(args->epa_SoR, epa->epa_SoR);
+	MAT_COPY(args->epa_invRoS, epa->epa_invRoS);
+	return size;
+}
+
+#endif /* USE_OPENCL */
+
+
 /**
  * Create a bounding RPP for an epa
  */
--- src/librt/primitives/epa/epa_shot.cl	1970-01-01 05:30:00.0 +0530
+++ src/librt/primitives/epa/epa_shot.cl	2016-03-07 15:50:24.033081000 +0530
@@ -0,0 +1,139 @@
+#include "common.cl"
+
+
+/* hit_surfno is set to one of these */
+#define EPA_NORM_BODY	(1)		/* compute normal */
+#define EPA_NORM_TOP	(2)		/* copy epa_N */
+
+
+struct epa_specific {
+	double epa_V[3];		// vector to epa origin
+	double epa_Hunit[3];	// unit H vector
+	double epa_SoR[16];		// Scale(Rot(vect))
+	double epa_invRoS[16];	// invRot(Scale(vect))
+};
+
+int epa_shot(RESULT_TYPE *res, const double3 r_pt, const double3 r_dir, const uint idx, global const struct epa_specific *epa)
+{
+	double3 dp;			// D'
+	double3 pp;			// P'
+	double k1, k2;		// distance constants of solution
+	double3 xlated;		// translated vector
+	struct hit hits[3];	// 2 potential hit points
+	struct hit *hitp;	// pointer to hit point
+
+	hitp = [0];
+
+	dp = MAT4X3VEC(epa->epa_SoR, r_dir);
+	xlated = r_pt - vload3(0, epa->epa_V);
+	pp = MAT4X3VEC(epa->epa_SoR, xlated);
+
+	// Find roots of the equation
+	double a, b, c;		//coeffs of polynomial
+	double disc;		// disc of radical
+
+	a = dp.x * dp.x + dp.y * dp.y;
+	b = 2 

Re: [brlcad-devel] Help understanding code

[Param Hanji]

Yeah sending the output to the file fixed it. I'll add in my implementation
for epa and submit a patch soon.

 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.

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 
>> 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=/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=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Param Hanji]

On Fri, Mar 18, 2016 at 6:47 PM Param Hanji 
wrote:

>
> 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.
>

Ignore the bit about ray tracing. I just want to know about the specific
functions.

Thanks!
--
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=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

On Thu, Mar 17, 2016 at 8:49 PM, Christopher Sean Morrison 
wrote:

>
>
> On Mar 17, 2016, at 03:55 PM, Vasco Alexandre da Silva Costa <
> vasco.co...@gmail.com> wrote:
>
> The problem is the material lighting code. The results are not the same.
> In OpenCL mode it renders that ehy in a really dark color and you nearly
> miss it. If you render the ehy in surface normals lighting mode (i.e. rt
> -z1 -l2) the output is as expected here.
>
>
> Ah, very good.  The -W command line option is good in a pinch for seeing
> dark objects vs black window -- makes the background white.
>

Neat! That clearly shows that there is a black solid in the render. Thanks!

-- 
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=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

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 
> 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=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Christopher Sean Morrison]

 --
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=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

On Wed, Mar 16, 2016 at 7:28 PM, Param Hanji 
wrote:

> Hi,
>
> Installing the AMD SDK gave me OpenCL 1.2 support. I managed to configure
> cmake using cmake-gui and built successfully. But raytrace still doesn't
> happen on my GPU. By adding fprintf statements, I found out that execution
> does indeed enter the #ifdef USE_OPENCL block at rt/main.c. However the if
> following block (if (opencl_mode)) is not entered.
>
> opencl_mode is set at opt.c at case: 'z'. I still don't know why its value
> doesn't change even if use -z option.
>

I think it is '-z 1'. The '-z' option currently requires a numeric argument.
'1' to enable OpenCL mode and '0' to disable it.

-- 
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=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Param Hanji]

Hi Vasco Costa,

Yes -z 1 did it. :)

Now fopen() throws an error! Function clt_read_code() in primitiive_util.c
fopen() returns a NULL. I included  and printed the error as
described here

http://stackoverflow.com/questions/8633909/what-is-the-reason-for-fopens-failure-to-open-a-file

The error is 2 which means "No such file or directory" according to

http://www.thegeekstuff.com/2010/10/linux-error-codes/

This is rather puzzling because I can see solver.cl present in the same
directory as primitive_util.c. Moreover, fopen() is a function that I've
used time and time again and I haven't this kind of error before. I also
verified that the file has read access.

Thank you for your patience! I'm just running into issue after issue. I
really appreciate your guidance.

Best,
Param

On Thu, Mar 17, 2016 at 1:15 AM Vasco Alexandre da Silva Costa <
vasco.co...@gmail.com> wrote:

> On Wed, Mar 16, 2016 at 7:36 PM, Vasco Alexandre da Silva Costa <
> vasco.co...@gmail.com> wrote:
>
>> On Wed, Mar 16, 2016 at 7:28 PM, Param Hanji 
>> wrote:
>>
>>> Hi,
>>>
>>> Installing the AMD SDK gave me OpenCL 1.2 support. I managed to
>>> configure cmake using cmake-gui and built successfully. But raytrace still
>>> doesn't happen on my GPU. By adding fprintf statements, I found out that
>>> execution does indeed enter the #ifdef USE_OPENCL block at rt/main.c.
>>> However the if following block (if (opencl_mode)) is not entered.
>>>
>>> opencl_mode is set at opt.c at case: 'z'. I still don't know why its
>>> value doesn't change even if use -z option.
>>>
>>
>> I think it is '-z 1'. The '-z' option currently requires a numeric
>> argument.
>> '1' to enable OpenCL mode and '0' to disable it.
>>
>
> The code is like this (opt.c):
>
>   case 'z':
>   opencl_mode = atoi( bu_optarg );
>   break;
>
> I did it this way because I added a toggle button in the MGED File ->
> Raytrace panel where you can enable or disable OpenCL mode. The toggle is
> either '0' or '1' depending on its status.
>
> --
> 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=/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=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

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 
> 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 >> > 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

Re: [brlcad-devel] Help understanding code

[Param Hanji]

Hello,

Yup I did run the OpenCL programs. I still can run them. I tried clinfo on
root as well. Still no luck. Everyone seems to have issues with Nvidia
OpenCL support.

I'll first try the AMD SDK which should hopefully work. Otherwise I could
use my desktop at home which has an AMD card and OpenCL working. But I
can't access it till the end of April during vacations.

Cheers,
Param

On Wed 16 Mar, 2016, 2:00 AM Vasco Alexandre da Silva Costa, <
vasco.co...@gmail.com> wrote:

> On Tue, Mar 15, 2016 at 8:05 PM, Vasco Alexandre da Silva Costa <
> vasco.co...@gmail.com> wrote:
>
>> On Tue, Mar 15, 2016 at 11:52 AM, Param Hanji > > wrote:
>>
>>> Further reading hinted at the lack of OpenCL 1.2 on Nvidia graphics
>>> cards. The clinfo package for Ubuntu doesn't recognize my GPU for the same
>>> reason.
>>>
>>> I checked their official website at
>>>
>>>
>>> http://www.geforce.com/hardware/notebook-gpus/geforce-gt-730m/specifications
>>>
>>> Sure enough only OpenCL 1.1 is listed. How do I move forward?
>>>
>>
>> Yeah it seems your GPU only supports OpenCL 1.1. In that case you can use
>> the AMD APP SDK which should run on any modern x86 CPU:
>>
>> http://developer.amd.com/tools-and-sdks/opencl-zone/amd-accelerated-parallel-processing-app-sdk/
>>
>
> PS: It's kind of weird though. The GeForce GT 730M is based on the Kepler
> architecture which should support OpenCL 1.2 fine as long as you have
> recent NVIDIA drivers with CUDA 7.0 SDK or later.
>
> --
> 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=/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=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

On Tue, Mar 15, 2016 at 8:05 PM, Vasco Alexandre da Silva Costa <
vasco.co...@gmail.com> wrote:

> On Tue, Mar 15, 2016 at 11:52 AM, Param Hanji 
> wrote:
>
>> Further reading hinted at the lack of OpenCL 1.2 on Nvidia graphics
>> cards. The clinfo package for Ubuntu doesn't recognize my GPU for the same
>> reason.
>>
>> I checked their official website at
>>
>>
>> http://www.geforce.com/hardware/notebook-gpus/geforce-gt-730m/specifications
>>
>> Sure enough only OpenCL 1.1 is listed. How do I move forward?
>>
>
> Yeah it seems your GPU only supports OpenCL 1.1. In that case you can use
> the AMD APP SDK which should run on any modern x86 CPU:
>
> http://developer.amd.com/tools-and-sdks/opencl-zone/amd-accelerated-parallel-processing-app-sdk/
>

PS: It's kind of weird though. The GeForce GT 730M is based on the Kepler
architecture which should support OpenCL 1.2 fine as long as you have
recent NVIDIA drivers with CUDA 7.0 SDK or later.

-- 
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=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

On Mon, Mar 14, 2016 at 6:32 PM, Param Hanji 
wrote:

> Hello,
>
> I got the -z working. However only CPU parallelization is done. In my
> build/CmakeCache.txt, the boolean BRLCAD_ENABLE_OPENCL is OFF.
>

I guess Cmake isn't detecting OpenCL on your system. You might have to run
'cmake-gui' in order to point to the place where the OpenCL include files
(e.g. CL/cl.h) and libraries (libOpenCL.so) are located in your system.
Did you do basic tests to see if OpenCL is correctly installed? You can
check that out with the 'clinfo' command (there's a Debian package for it
and if you don't have a package its easy to compile).

Unless BRLCAD_ENABLE_OPENCL is ON the OpenCL host code will be #ifdefd out
and won't be compiled at all.

> I'm guessing that's why my OpenCL files don't compile. How do I change
> this?
>
OpenCL 1.2 loads the .cl device code source files at runtime and compiles
them at runtime. This is often done by the driver kind of like compiling
GLSL shaders.


>
> --
> 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=/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=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Param Hanji]

Hi everyone,

Sorry for the brief period of absence. I did a fresh build and got the GUI
working. A build with .cl file for accelerating epa also completes
successfully. I've generated the .patch file as well.

However, parallel ray trace fails on every primitive(including ell, ehy,
sph etc). I get a message on the terminal saying '-z doesn't exist',
generated by function db_lookup(). A quick grep takes my to the function in
librt. The option is checked here using RT_DBHASH().

I tried couldn't find the definition of this. Can someone tell me why -z is
not being recognized? Right now, lookup of -z fails and the ray trace
continues serially.

Best,
Param

On Wed, Mar 9, 2016 at 12:41 PM Christopher Sean Morrison 
wrote:

> I had run just cmake .. (which was described as the default). After
> re-making, I can run mged and produce the .pix files on the command line. I
> then used the pix-png tool to view the shapes and they are accurate. The
> GUI still doesn't open up.
>
>
> Note you can render directly to png from most of our tools (e.g., rt -o
> file.png).  If mged won’t run in GUI mode, then the summary provided at the
> end of cmake probably says why.  Most common, compiling against X11 may be
> disabled because you do not have requisite developer headers installed.
> See README (and by extension doc/README.Linux) for details.
>
> Also, I can't get a GUI to work. 'mged' starts and offers to attach either
>>> a text file or a null. But that's not an issue as I'm fine working with the
>>> command line. Just want to know how I can view the trace.
>>>
>>
> Everyone should really be able to get graphical MGED working, even
> unassisted.  That doesn’t mean avoid asking for help if people are stuck
> and you’ve genuinely been trying for an hour.  It just means everyone
> should try.  You're may be overlooking informative messages from either
> make or (more likely) cmake in this particular instance.
>
> Cheers!
> Sean
>
>
> --
> 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=278785111=/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=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Christopher Sean Morrison]

> I had run just cmake .. (which was described as the default). After 
> re-making, I can run mged and produce the .pix files on the command line. I 
> then used the pix-png tool to view the shapes and they are accurate. The GUI 
> still doesn't open up.

Note you can render directly to png from most of our tools (e.g., rt -o 
file.png).  If mged won’t run in GUI mode, then the summary provided at the end 
of cmake probably says why.  Most common, compiling against X11 may be disabled 
because you do not have requisite developer headers installed.  See README (and 
by extension doc/README.Linux) for details.

> Also, I can't get a GUI to work. 'mged' starts and offers to attach either a 
> text file or a null. But that's not an issue as I'm fine working with the 
> command line. Just want to know how I can view the trace.

Everyone should really be able to get graphical MGED working, even unassisted.  
That doesn’t mean avoid asking for help if people are stuck and you’ve 
genuinely been trying for an hour.  It just means everyone should try.  You're 
may be overlooking informative messages from either make or (more likely) cmake 
in this particular instance.

Cheers!
Sean

--
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=278785111=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

On Tue, Mar 8, 2016 at 3:14 PM, Param Hanji 
wrote:

> I had run just cmake .. (which was described as the default). After
> re-making, I can run mged and produce the .pix files on the command line. I
> then used the pix-png tool to view the shapes and they are accurate. The
> GUI still doesn't open up.
>
> Also, how do I render with OpenCl? I'm assuming what I did now was the
> default rendering without OpenCL.
>
>
Use the 'rt -z' flag to render with OpenCL. You can see the list of rt
command line options by doing 'rt -h'.
Still I would expect you to be able to use the mged Tcl/Tk interface...
Please send a screenshot once you can.

Regards,
-Vasco Costa


> Cheers
>
> On Tue, Mar 8, 2016 at 9:07 AM Vasco Alexandre da Silva Costa <
> vasco.co...@gmail.com> wrote:
>
>> Are you using the Tcl/Tk version of mged? BRL-CAD comes with the
>> libraries. To use the included libraries compile after:
>>
>> cmake .. -DBRLCAD_BUNDLED_LIBS=ON
>>
>> This was explained in the SVN page I originally linked:
>> http://brlcad.org/wiki/Building_from_SVN
>>
>> Once you get mged working in Tcl/Tk you can do something like this:
>> make tgc tgc
>> e tgc
>> rt -o tgc.pix
>>
>> Or use the raytrace command from the mged menus.
>>
>> On Tue, Mar 8, 2016 at 2:31 AM, Param Hanji 
>> wrote:
>>
>>> Um running 'rt' gives me a message "view does not exist". The same
>>> message is displayed if I try any other primitive(like ell, sph as well).
>>> So maybe, it's an installation issue? However 'make check' gave me no
>>> errors.
>>>
>>> Also, I can't get a GUI to work. 'mged' starts and offers to attach
>>> either a text file or a null. But that's not an issue as I'm fine working
>>> with the command line. Just want to know how I can view the trace.
>>>
>>> Best,
>>> Param Hanji
>>>
>>> On Tue, Mar 8, 2016 at 1:08 AM Vasco Alexandre da Silva Costa <
>>> vasco.co...@gmail.com> wrote:
>>>
 PS: I originally suggested the 'eto' primitive because it is useful to
 design vehicle wheels. But other people who have been around here longer
 than I have can better suggest you which primitives are most useful to
 implement. Sean and Erik were my GSoC mentors last year. They should know
 that better.

 Regards,
 -Vasco Costa

 On Mon, Mar 7, 2016 at 7:30 PM, Vasco Alexandre da Silva Costa <
 vasco.co...@gmail.com> wrote:

> On Mon, Mar 7, 2016 at 11:28 AM, Param Hanji <
> param.catchch...@gmail.com> wrote:
>
>> Hi,
>>
>> I've managed to accelerate "librt/primitives/epa". I now need to
>> create an ID for it in "primitives/rt.cl". It's okay if I define it
>> with ID 40 right(on line 94)?
>>
>> I've also made changes to "primitives/common.cl",
>> "librt/CMakeLists.txt", "primitives/primitive_util.c" and
>> "primitives/epa/epa.c". Are there any other changes required?
>>
>
> Not that I can think of. Test the code (e.g. inside mged type 'make
> epa epa'; then render it with 'rt' with and without OpenCL acceleration).
> Can you get us a screenshot?
>
> Once everything is working ok you can create a patch in unified diff
> format e.g. with 'diff -Nurd' and then submit it to the BRL-CAD patch
> tracker at:
> https://sourceforge.net/p/brlcad/patches/
>
> All the best,
> -Vasco Costa
>
>
>> And grep really helped. Thank you :)
>>
>> On Sun, Mar 6, 2016 at 5:20 AM Vasco Alexandre da Silva Costa <
>> vasco.co...@gmail.com> wrote:
>>
>>> PS: When I was starting out programming in this project I used the
>>> NetBeans IDE to browse the BRL-CAD source code so I could understand the
>>> code structure better. As a last resort grep is your friend...
>>>
>>> On Sat, Mar 5, 2016 at 10:25 PM, Vasco Alexandre da Silva Costa <
>>> vasco.co...@gmail.com> wrote:
>>>
 The primitives folder has the primitive implementation code. See
 librt/primitives/primitive_util.c for the OpenCL C calls proper.

 On Sat, Mar 5, 2016 at 7:10 AM, Param Hanji <
 param.catchch...@gmail.com> wrote:

> Hello,
>
> I was going through the code in librt/primitives folder. The
> OpenCL specific code seems very unfamiliar to me.
>
> Granted I'm new to OpenCL and large open source projects like this
> one, I still find it harder to understand than what I expected.
>
> "ell.c" nor any of the other files here contain code to create and
> configure the OpenCL data structures(for device, kernel, context etc).
> There no function calls like clCreateContext, clGetPlatformIDs, 
> clGetDeviceIDs.
> The .cl file also doesn't have kernel functions as well. So I just
> don't know where to start.
>
> Is my working of knowledge of OpenCL wrong/outdated? Are there
> resources I can 

Re: [brlcad-devel] Help understanding code

[Param Hanji]

Um running 'rt' gives me a message "view does not exist". The same message
is displayed if I try any other primitive(like ell, sph as well). So maybe,
it's an installation issue? However 'make check' gave me no errors.

Also, I can't get a GUI to work. 'mged' starts and offers to attach either
a text file or a null. But that's not an issue as I'm fine working with the
command line. Just want to know how I can view the trace.

Best,
Param Hanji

On Tue, Mar 8, 2016 at 1:08 AM Vasco Alexandre da Silva Costa <
vasco.co...@gmail.com> wrote:

> PS: I originally suggested the 'eto' primitive because it is useful to
> design vehicle wheels. But other people who have been around here longer
> than I have can better suggest you which primitives are most useful to
> implement. Sean and Erik were my GSoC mentors last year. They should know
> that better.
>
> Regards,
> -Vasco Costa
>
> On Mon, Mar 7, 2016 at 7:30 PM, Vasco Alexandre da Silva Costa <
> vasco.co...@gmail.com> wrote:
>
>> On Mon, Mar 7, 2016 at 11:28 AM, Param Hanji 
>> wrote:
>>
>>> Hi,
>>>
>>> I've managed to accelerate "librt/primitives/epa". I now need to create
>>> an ID for it in "primitives/rt.cl". It's okay if I define it with ID 40
>>> right(on line 94)?
>>>
>>> I've also made changes to "primitives/common.cl",
>>> "librt/CMakeLists.txt", "primitives/primitive_util.c" and
>>> "primitives/epa/epa.c". Are there any other changes required?
>>>
>>
>> Not that I can think of. Test the code (e.g. inside mged type 'make epa
>> epa'; then render it with 'rt' with and without OpenCL acceleration). Can
>> you get us a screenshot?
>>
>> Once everything is working ok you can create a patch in unified diff
>> format e.g. with 'diff -Nurd' and then submit it to the BRL-CAD patch
>> tracker at:
>> https://sourceforge.net/p/brlcad/patches/
>>
>> All the best,
>> -Vasco Costa
>>
>>
>>> And grep really helped. Thank you :)
>>>
>>> On Sun, Mar 6, 2016 at 5:20 AM Vasco Alexandre da Silva Costa <
>>> vasco.co...@gmail.com> wrote:
>>>
 PS: When I was starting out programming in this project I used the
 NetBeans IDE to browse the BRL-CAD source code so I could understand the
 code structure better. As a last resort grep is your friend...

 On Sat, Mar 5, 2016 at 10:25 PM, Vasco Alexandre da Silva Costa <
 vasco.co...@gmail.com> wrote:

> The primitives folder has the primitive implementation code. See
> librt/primitives/primitive_util.c for the OpenCL C calls proper.
>
> On Sat, Mar 5, 2016 at 7:10 AM, Param Hanji <
> param.catchch...@gmail.com> wrote:
>
>> Hello,
>>
>> I was going through the code in librt/primitives folder. The OpenCL
>> specific code seems very unfamiliar to me.
>>
>> Granted I'm new to OpenCL and large open source projects like this
>> one, I still find it harder to understand than what I expected.
>>
>> "ell.c" nor any of the other files here contain code to create and
>> configure the OpenCL data structures(for device, kernel, context etc).
>> There no function calls like clCreateContext, clGetPlatformIDs, 
>> clGetDeviceIDs.
>> The .cl file also doesn't have kernel functions as well. So I just
>> don't know where to start.
>>
>> Is my working of knowledge of OpenCL wrong/outdated? Are there
>> resources I can refer to? Any help would be great. Thank you for your 
>> time!
>>
>> Best,
>> Param Hanji
>>
>
>
>
> --
> Vasco Alexandre da Silva Costa
> PhD in Computer Engineering (Computer Graphics)
> Instituto Superior Técnico/University of Lisbon, Portugal
>



 --
 Vasco Alexandre da Silva Costa
 PhD in Computer Engineering (Computer Graphics)
 Instituto Superior Técnico/University of Lisbon, Portugal

>>>
>>
>>
>> --
>> Vasco Alexandre da Silva Costa
>> PhD in Computer Engineering (Computer Graphics)
>> Instituto Superior Técnico/University of Lisbon, Portugal
>>
>
>
>
> --
> 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://makebettercode.com/inteldaal-eval___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

Are you using the Tcl/Tk version of mged? BRL-CAD comes with the libraries.
To use the included libraries compile after:

cmake .. -DBRLCAD_BUNDLED_LIBS=ON

This was explained in the SVN page I originally linked:
http://brlcad.org/wiki/Building_from_SVN

Once you get mged working in Tcl/Tk you can do something like this:
make tgc tgc
e tgc
rt -o tgc.pix

Or use the raytrace command from the mged menus.

On Tue, Mar 8, 2016 at 2:31 AM, Param Hanji 
wrote:

> Um running 'rt' gives me a message "view does not exist". The same message
> is displayed if I try any other primitive(like ell, sph as well). So maybe,
> it's an installation issue? However 'make check' gave me no errors.
>
> Also, I can't get a GUI to work. 'mged' starts and offers to attach either
> a text file or a null. But that's not an issue as I'm fine working with the
> command line. Just want to know how I can view the trace.
>
> Best,
> Param Hanji
>
> On Tue, Mar 8, 2016 at 1:08 AM Vasco Alexandre da Silva Costa <
> vasco.co...@gmail.com> wrote:
>
>> PS: I originally suggested the 'eto' primitive because it is useful to
>> design vehicle wheels. But other people who have been around here longer
>> than I have can better suggest you which primitives are most useful to
>> implement. Sean and Erik were my GSoC mentors last year. They should know
>> that better.
>>
>> Regards,
>> -Vasco Costa
>>
>> On Mon, Mar 7, 2016 at 7:30 PM, Vasco Alexandre da Silva Costa <
>> vasco.co...@gmail.com> wrote:
>>
>>> On Mon, Mar 7, 2016 at 11:28 AM, Param Hanji >> > wrote:
>>>
 Hi,

 I've managed to accelerate "librt/primitives/epa". I now need to create
 an ID for it in "primitives/rt.cl". It's okay if I define it with ID
 40 right(on line 94)?

 I've also made changes to "primitives/common.cl",
 "librt/CMakeLists.txt", "primitives/primitive_util.c" and
 "primitives/epa/epa.c". Are there any other changes required?

>>>
>>> Not that I can think of. Test the code (e.g. inside mged type 'make epa
>>> epa'; then render it with 'rt' with and without OpenCL acceleration). Can
>>> you get us a screenshot?
>>>
>>> Once everything is working ok you can create a patch in unified diff
>>> format e.g. with 'diff -Nurd' and then submit it to the BRL-CAD patch
>>> tracker at:
>>> https://sourceforge.net/p/brlcad/patches/
>>>
>>> All the best,
>>> -Vasco Costa
>>>
>>>
 And grep really helped. Thank you :)

 On Sun, Mar 6, 2016 at 5:20 AM Vasco Alexandre da Silva Costa <
 vasco.co...@gmail.com> wrote:

> PS: When I was starting out programming in this project I used the
> NetBeans IDE to browse the BRL-CAD source code so I could understand the
> code structure better. As a last resort grep is your friend...
>
> On Sat, Mar 5, 2016 at 10:25 PM, Vasco Alexandre da Silva Costa <
> vasco.co...@gmail.com> wrote:
>
>> The primitives folder has the primitive implementation code. See
>> librt/primitives/primitive_util.c for the OpenCL C calls proper.
>>
>> On Sat, Mar 5, 2016 at 7:10 AM, Param Hanji <
>> param.catchch...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I was going through the code in librt/primitives folder. The OpenCL
>>> specific code seems very unfamiliar to me.
>>>
>>> Granted I'm new to OpenCL and large open source projects like this
>>> one, I still find it harder to understand than what I expected.
>>>
>>> "ell.c" nor any of the other files here contain code to create and
>>> configure the OpenCL data structures(for device, kernel, context etc).
>>> There no function calls like clCreateContext, clGetPlatformIDs, 
>>> clGetDeviceIDs.
>>> The .cl file also doesn't have kernel functions as well. So I just
>>> don't know where to start.
>>>
>>> Is my working of knowledge of OpenCL wrong/outdated? Are there
>>> resources I can refer to? Any help would be great. Thank you for your 
>>> time!
>>>
>>> Best,
>>> Param Hanji
>>>
>>
>>
>>
>> --
>> Vasco Alexandre da Silva Costa
>> PhD in Computer Engineering (Computer Graphics)
>> Instituto Superior Técnico/University of Lisbon, Portugal
>>
>
>
>
> --
> Vasco Alexandre da Silva Costa
> PhD in Computer Engineering (Computer Graphics)
> Instituto Superior Técnico/University of Lisbon, Portugal
>

>>>
>>>
>>> --
>>> Vasco Alexandre da Silva Costa
>>> PhD in Computer Engineering (Computer Graphics)
>>> Instituto Superior Técnico/University of Lisbon, Portugal
>>>
>>
>>
>>
>> --
>> Vasco Alexandre da Silva Costa
>> PhD in Computer Engineering (Computer Graphics)
>> Instituto Superior Técnico/University of Lisbon, Portugal
>>
>


-- 
Vasco Alexandre da Silva Costa
PhD in Computer Engineering (Computer Graphics)
Instituto Superior Técnico/University of Lisbon, Portugal

Re: [brlcad-devel] Help understanding code

[Param Hanji]

PS: I can't seem to get 'brlterm' to run as well(don't know how to). For
now I'm launching 'mged' directly from /usr/brlcad/dev-7.25.0/bin/mged.

Cheers,
Param Hanji

On Tue, Mar 8, 2016 at 8:01 AM Param Hanji 
wrote:

> Um running 'rt' gives me a message "view does not exist". The same message
> is displayed if I try any other primitive(like ell, sph as well). So maybe,
> it's an installation issue? However 'make check' gave me no errors.
>
> Also, I can't get a GUI to work. 'mged' starts and offers to attach either
> a text file or a null. But that's not an issue as I'm fine working with the
> command line. Just want to know how I can view the trace.
>
> Best,
> Param Hanji
>
> On Tue, Mar 8, 2016 at 1:08 AM Vasco Alexandre da Silva Costa <
> vasco.co...@gmail.com> wrote:
>
>> PS: I originally suggested the 'eto' primitive because it is useful to
>> design vehicle wheels. But other people who have been around here longer
>> than I have can better suggest you which primitives are most useful to
>> implement. Sean and Erik were my GSoC mentors last year. They should know
>> that better.
>>
>> Regards,
>> -Vasco Costa
>>
>> On Mon, Mar 7, 2016 at 7:30 PM, Vasco Alexandre da Silva Costa <
>> vasco.co...@gmail.com> wrote:
>>
>>> On Mon, Mar 7, 2016 at 11:28 AM, Param Hanji >> > wrote:
>>>
 Hi,

 I've managed to accelerate "librt/primitives/epa". I now need to create
 an ID for it in "primitives/rt.cl". It's okay if I define it with ID
 40 right(on line 94)?

 I've also made changes to "primitives/common.cl",
 "librt/CMakeLists.txt", "primitives/primitive_util.c" and
 "primitives/epa/epa.c". Are there any other changes required?

>>>
>>> Not that I can think of. Test the code (e.g. inside mged type 'make epa
>>> epa'; then render it with 'rt' with and without OpenCL acceleration). Can
>>> you get us a screenshot?
>>>
>>> Once everything is working ok you can create a patch in unified diff
>>> format e.g. with 'diff -Nurd' and then submit it to the BRL-CAD patch
>>> tracker at:
>>> https://sourceforge.net/p/brlcad/patches/
>>>
>>> All the best,
>>> -Vasco Costa
>>>
>>>
 And grep really helped. Thank you :)

 On Sun, Mar 6, 2016 at 5:20 AM Vasco Alexandre da Silva Costa <
 vasco.co...@gmail.com> wrote:

> PS: When I was starting out programming in this project I used the
> NetBeans IDE to browse the BRL-CAD source code so I could understand the
> code structure better. As a last resort grep is your friend...
>
> On Sat, Mar 5, 2016 at 10:25 PM, Vasco Alexandre da Silva Costa <
> vasco.co...@gmail.com> wrote:
>
>> The primitives folder has the primitive implementation code. See
>> librt/primitives/primitive_util.c for the OpenCL C calls proper.
>>
>> On Sat, Mar 5, 2016 at 7:10 AM, Param Hanji <
>> param.catchch...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I was going through the code in librt/primitives folder. The OpenCL
>>> specific code seems very unfamiliar to me.
>>>
>>> Granted I'm new to OpenCL and large open source projects like this
>>> one, I still find it harder to understand than what I expected.
>>>
>>> "ell.c" nor any of the other files here contain code to create and
>>> configure the OpenCL data structures(for device, kernel, context etc).
>>> There no function calls like clCreateContext, clGetPlatformIDs, 
>>> clGetDeviceIDs.
>>> The .cl file also doesn't have kernel functions as well. So I just
>>> don't know where to start.
>>>
>>> Is my working of knowledge of OpenCL wrong/outdated? Are there
>>> resources I can refer to? Any help would be great. Thank you for your 
>>> time!
>>>
>>> Best,
>>> Param Hanji
>>>
>>
>>
>>
>> --
>> Vasco Alexandre da Silva Costa
>> PhD in Computer Engineering (Computer Graphics)
>> Instituto Superior Técnico/University of Lisbon, Portugal
>>
>
>
>
> --
> Vasco Alexandre da Silva Costa
> PhD in Computer Engineering (Computer Graphics)
> Instituto Superior Técnico/University of Lisbon, Portugal
>

>>>
>>>
>>> --
>>> Vasco Alexandre da Silva Costa
>>> PhD in Computer Engineering (Computer Graphics)
>>> Instituto Superior Técnico/University of Lisbon, Portugal
>>>
>>
>>
>>
>> --
>> 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://makebettercode.com/inteldaal-eval___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net

Re: [brlcad-devel] Help understanding code

[Param Hanji]

I had run just cmake .. (which was described as the default). After
re-making, I can run mged and produce the .pix files on the command line. I
then used the pix-png tool to view the shapes and they are accurate. The
GUI still doesn't open up.

Also, how do I render with OpenCl? I'm assuming what I did now was the
default rendering without OpenCL.

Cheers

On Tue, Mar 8, 2016 at 9:07 AM Vasco Alexandre da Silva Costa <
vasco.co...@gmail.com> wrote:

> Are you using the Tcl/Tk version of mged? BRL-CAD comes with the
> libraries. To use the included libraries compile after:
>
> cmake .. -DBRLCAD_BUNDLED_LIBS=ON
>
> This was explained in the SVN page I originally linked:
> http://brlcad.org/wiki/Building_from_SVN
>
> Once you get mged working in Tcl/Tk you can do something like this:
> make tgc tgc
> e tgc
> rt -o tgc.pix
>
> Or use the raytrace command from the mged menus.
>
> On Tue, Mar 8, 2016 at 2:31 AM, Param Hanji 
> wrote:
>
>> Um running 'rt' gives me a message "view does not exist". The same
>> message is displayed if I try any other primitive(like ell, sph as well).
>> So maybe, it's an installation issue? However 'make check' gave me no
>> errors.
>>
>> Also, I can't get a GUI to work. 'mged' starts and offers to attach
>> either a text file or a null. But that's not an issue as I'm fine working
>> with the command line. Just want to know how I can view the trace.
>>
>> Best,
>> Param Hanji
>>
>> On Tue, Mar 8, 2016 at 1:08 AM Vasco Alexandre da Silva Costa <
>> vasco.co...@gmail.com> wrote:
>>
>>> PS: I originally suggested the 'eto' primitive because it is useful to
>>> design vehicle wheels. But other people who have been around here longer
>>> than I have can better suggest you which primitives are most useful to
>>> implement. Sean and Erik were my GSoC mentors last year. They should know
>>> that better.
>>>
>>> Regards,
>>> -Vasco Costa
>>>
>>> On Mon, Mar 7, 2016 at 7:30 PM, Vasco Alexandre da Silva Costa <
>>> vasco.co...@gmail.com> wrote:
>>>
 On Mon, Mar 7, 2016 at 11:28 AM, Param Hanji <
 param.catchch...@gmail.com> wrote:

> Hi,
>
> I've managed to accelerate "librt/primitives/epa". I now need to
> create an ID for it in "primitives/rt.cl". It's okay if I define it
> with ID 40 right(on line 94)?
>
> I've also made changes to "primitives/common.cl",
> "librt/CMakeLists.txt", "primitives/primitive_util.c" and
> "primitives/epa/epa.c". Are there any other changes required?
>

 Not that I can think of. Test the code (e.g. inside mged type 'make epa
 epa'; then render it with 'rt' with and without OpenCL acceleration). Can
 you get us a screenshot?

 Once everything is working ok you can create a patch in unified diff
 format e.g. with 'diff -Nurd' and then submit it to the BRL-CAD patch
 tracker at:
 https://sourceforge.net/p/brlcad/patches/

 All the best,
 -Vasco Costa


> And grep really helped. Thank you :)
>
> On Sun, Mar 6, 2016 at 5:20 AM Vasco Alexandre da Silva Costa <
> vasco.co...@gmail.com> wrote:
>
>> PS: When I was starting out programming in this project I used the
>> NetBeans IDE to browse the BRL-CAD source code so I could understand the
>> code structure better. As a last resort grep is your friend...
>>
>> On Sat, Mar 5, 2016 at 10:25 PM, Vasco Alexandre da Silva Costa <
>> vasco.co...@gmail.com> wrote:
>>
>>> The primitives folder has the primitive implementation code. See
>>> librt/primitives/primitive_util.c for the OpenCL C calls proper.
>>>
>>> On Sat, Mar 5, 2016 at 7:10 AM, Param Hanji <
>>> param.catchch...@gmail.com> wrote:
>>>
 Hello,

 I was going through the code in librt/primitives folder. The OpenCL
 specific code seems very unfamiliar to me.

 Granted I'm new to OpenCL and large open source projects like this
 one, I still find it harder to understand than what I expected.

 "ell.c" nor any of the other files here contain code to create and
 configure the OpenCL data structures(for device, kernel, context etc).
 There no function calls like clCreateContext, clGetPlatformIDs, 
 clGetDeviceIDs.
 The .cl file also doesn't have kernel functions as well. So I just
 don't know where to start.

 Is my working of knowledge of OpenCL wrong/outdated? Are there
 resources I can refer to? Any help would be great. Thank you for your 
 time!

 Best,
 Param Hanji

>>>
>>>
>>>
>>> --
>>> Vasco Alexandre da Silva Costa
>>> PhD in Computer Engineering (Computer Graphics)
>>> Instituto Superior Técnico/University of Lisbon, Portugal
>>>
>>
>>
>>
>> --
>> Vasco Alexandre da Silva Costa
>> PhD in Computer Engineering (Computer Graphics)

Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

PS: I originally suggested the 'eto' primitive because it is useful to
design vehicle wheels. But other people who have been around here longer
than I have can better suggest you which primitives are most useful to
implement. Sean and Erik were my GSoC mentors last year. They should know
that better.

Regards,
-Vasco Costa

On Mon, Mar 7, 2016 at 7:30 PM, Vasco Alexandre da Silva Costa <
vasco.co...@gmail.com> wrote:

> On Mon, Mar 7, 2016 at 11:28 AM, Param Hanji 
> wrote:
>
>> Hi,
>>
>> I've managed to accelerate "librt/primitives/epa". I now need to create
>> an ID for it in "primitives/rt.cl". It's okay if I define it with ID 40
>> right(on line 94)?
>>
>> I've also made changes to "primitives/common.cl",
>> "librt/CMakeLists.txt", "primitives/primitive_util.c" and
>> "primitives/epa/epa.c". Are there any other changes required?
>>
>
> Not that I can think of. Test the code (e.g. inside mged type 'make epa
> epa'; then render it with 'rt' with and without OpenCL acceleration). Can
> you get us a screenshot?
>
> Once everything is working ok you can create a patch in unified diff
> format e.g. with 'diff -Nurd' and then submit it to the BRL-CAD patch
> tracker at:
> https://sourceforge.net/p/brlcad/patches/
>
> All the best,
> -Vasco Costa
>
>
>> And grep really helped. Thank you :)
>>
>> On Sun, Mar 6, 2016 at 5:20 AM Vasco Alexandre da Silva Costa <
>> vasco.co...@gmail.com> wrote:
>>
>>> PS: When I was starting out programming in this project I used the
>>> NetBeans IDE to browse the BRL-CAD source code so I could understand the
>>> code structure better. As a last resort grep is your friend...
>>>
>>> On Sat, Mar 5, 2016 at 10:25 PM, Vasco Alexandre da Silva Costa <
>>> vasco.co...@gmail.com> wrote:
>>>
 The primitives folder has the primitive implementation code. See
 librt/primitives/primitive_util.c for the OpenCL C calls proper.

 On Sat, Mar 5, 2016 at 7:10 AM, Param Hanji  wrote:

> Hello,
>
> I was going through the code in librt/primitives folder. The OpenCL
> specific code seems very unfamiliar to me.
>
> Granted I'm new to OpenCL and large open source projects like this
> one, I still find it harder to understand than what I expected.
>
> "ell.c" nor any of the other files here contain code to create and
> configure the OpenCL data structures(for device, kernel, context etc).
> There no function calls like clCreateContext, clGetPlatformIDs, 
> clGetDeviceIDs.
> The .cl file also doesn't have kernel functions as well. So I just
> don't know where to start.
>
> Is my working of knowledge of OpenCL wrong/outdated? Are there
> resources I can refer to? Any help would be great. Thank you for your 
> time!
>
> Best,
> Param Hanji
>



 --
 Vasco Alexandre da Silva Costa
 PhD in Computer Engineering (Computer Graphics)
 Instituto Superior Técnico/University of Lisbon, Portugal

>>>
>>>
>>>
>>> --
>>> Vasco Alexandre da Silva Costa
>>> PhD in Computer Engineering (Computer Graphics)
>>> Instituto Superior Técnico/University of Lisbon, Portugal
>>>
>>
>
>
> --
> Vasco Alexandre da Silva Costa
> PhD in Computer Engineering (Computer Graphics)
> Instituto Superior Técnico/University of Lisbon, Portugal
>



-- 
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://makebettercode.com/inteldaal-eval___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

On Mon, Mar 7, 2016 at 11:28 AM, Param Hanji 
wrote:

> Hi,
>
> I've managed to accelerate "librt/primitives/epa". I now need to create an
> ID for it in "primitives/rt.cl". It's okay if I define it with ID 40
> right(on line 94)?
>
> I've also made changes to "primitives/common.cl", "librt/CMakeLists.txt",
> "primitives/primitive_util.c" and "primitives/epa/epa.c". Are there any
> other changes required?
>

Not that I can think of. Test the code (e.g. inside mged type 'make epa
epa'; then render it with 'rt' with and without OpenCL acceleration). Can
you get us a screenshot?

Once everything is working ok you can create a patch in unified diff format
e.g. with 'diff -Nurd' and then submit it to the BRL-CAD patch tracker at:
https://sourceforge.net/p/brlcad/patches/

All the best,
-Vasco Costa


> And grep really helped. Thank you :)
>
> On Sun, Mar 6, 2016 at 5:20 AM Vasco Alexandre da Silva Costa <
> vasco.co...@gmail.com> wrote:
>
>> PS: When I was starting out programming in this project I used the
>> NetBeans IDE to browse the BRL-CAD source code so I could understand the
>> code structure better. As a last resort grep is your friend...
>>
>> On Sat, Mar 5, 2016 at 10:25 PM, Vasco Alexandre da Silva Costa <
>> vasco.co...@gmail.com> wrote:
>>
>>> The primitives folder has the primitive implementation code. See
>>> librt/primitives/primitive_util.c for the OpenCL C calls proper.
>>>
>>> On Sat, Mar 5, 2016 at 7:10 AM, Param Hanji 
>>> wrote:
>>>
 Hello,

 I was going through the code in librt/primitives folder. The OpenCL
 specific code seems very unfamiliar to me.

 Granted I'm new to OpenCL and large open source projects like this one,
 I still find it harder to understand than what I expected.

 "ell.c" nor any of the other files here contain code to create and
 configure the OpenCL data structures(for device, kernel, context etc).
 There no function calls like clCreateContext, clGetPlatformIDs, 
 clGetDeviceIDs.
 The .cl file also doesn't have kernel functions as well. So I just
 don't know where to start.

 Is my working of knowledge of OpenCL wrong/outdated? Are there
 resources I can refer to? Any help would be great. Thank you for your time!

 Best,
 Param Hanji

>>>
>>>
>>>
>>> --
>>> Vasco Alexandre da Silva Costa
>>> PhD in Computer Engineering (Computer Graphics)
>>> Instituto Superior Técnico/University of Lisbon, Portugal
>>>
>>
>>
>>
>> --
>> Vasco Alexandre da Silva Costa
>> PhD in Computer Engineering (Computer Graphics)
>> Instituto Superior Técnico/University of Lisbon, Portugal
>>
>


-- 
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://makebettercode.com/inteldaal-eval___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

PS: When I was starting out programming in this project I used the NetBeans
IDE to browse the BRL-CAD source code so I could understand the code
structure better. As a last resort grep is your friend...

On Sat, Mar 5, 2016 at 10:25 PM, Vasco Alexandre da Silva Costa <
vasco.co...@gmail.com> wrote:

> The primitives folder has the primitive implementation code. See
> librt/primitives/primitive_util.c for the OpenCL C calls proper.
>
> On Sat, Mar 5, 2016 at 7:10 AM, Param Hanji 
> wrote:
>
>> Hello,
>>
>> I was going through the code in librt/primitives folder. The OpenCL
>> specific code seems very unfamiliar to me.
>>
>> Granted I'm new to OpenCL and large open source projects like this one, I
>> still find it harder to understand than what I expected.
>>
>> "ell.c" nor any of the other files here contain code to create and
>> configure the OpenCL data structures(for device, kernel, context etc).
>> There no function calls like clCreateContext, clGetPlatformIDs, 
>> clGetDeviceIDs.
>> The .cl file also doesn't have kernel functions as well. So I just don't
>> know where to start.
>>
>> Is my working of knowledge of OpenCL wrong/outdated? Are there resources
>> I can refer to? Any help would be great. Thank you for your time!
>>
>> Best,
>> Param Hanji
>>
>
>
>
> --
> Vasco Alexandre da Silva Costa
> PhD in Computer Engineering (Computer Graphics)
> Instituto Superior Técnico/University of Lisbon, Portugal
>



-- 
Vasco Alexandre da Silva Costa
PhD in Computer Engineering (Computer Graphics)
Instituto Superior Técnico/University of Lisbon, Portugal
--
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Help understanding code

[Vasco Alexandre da Silva Costa]

The primitives folder has the primitive implementation code. See
librt/primitives/primitive_util.c for the OpenCL C calls proper.

On Sat, Mar 5, 2016 at 7:10 AM, Param Hanji 
wrote:

> Hello,
>
> I was going through the code in librt/primitives folder. The OpenCL
> specific code seems very unfamiliar to me.
>
> Granted I'm new to OpenCL and large open source projects like this one, I
> still find it harder to understand than what I expected.
>
> "ell.c" nor any of the other files here contain code to create and
> configure the OpenCL data structures(for device, kernel, context etc).
> There no function calls like clCreateContext, clGetPlatformIDs, 
> clGetDeviceIDs.
> The .cl file also doesn't have kernel functions as well. So I just don't
> know where to start.
>
> Is my working of knowledge of OpenCL wrong/outdated? Are there resources I
> can refer to? Any help would be great. Thank you for your time!
>
> Best,
> Param Hanji
>



-- 
Vasco Alexandre da Silva Costa
PhD in Computer Engineering (Computer Graphics)
Instituto Superior Técnico/University of Lisbon, Portugal
--
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

[brlcad-devel] Help understanding code

[Param Hanji]

Hello,

Let me start off by saying that I'm new to OpenCL and large open source
projects like BRL-CAD, and could really use a bit of guidance.

I was going through the code in librt/primitives/ehy folder as pointed out
by a member of this community yesterday. The "ehy_shot.cl" file in this
folder as well as others(like ell_shot.cl) got me stumped. There are no
kernel functions(functions with __kernel prefix).

Also, "ehy.c" doesn't contain code to create and configure the OpenCL data
structures(for device, command queue, context etc). There are no function
calls like clCreateContext(), clGetPlatformIDs(), clGetDeviceIDs(), etc. So
I just don't know where to start.

Any kind of help would be great. Maybe someome could point to some
resources that I could go through. Thank you for your time.

Best,
Param Hanji
--
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel