GSoC 2016, BRL-CAD

GSoC Wrap up

catchchaos — Sun, 21 Aug 2016 18:15:01 +0000

It’s almost August 23rd and that signals the end of GSoC ’16. For the final review I’m required to summarize my work during the past 4 or so months. I figured a blog post was the perfect place for this.

For GSoC this year I’ve worked to improve OpenCL support for BRL-CAD. I started off by accelerating a few of the primitives used for CSG (Constructive Solid Geometry).

This basically meant writing kernel code for the shoot algorithms for various primitives. I had accelerated EPA just before GSoC began. This was followed up with ETO and then PART. PART in particular had a few changes since it had goto statements.

https://sourceforge.net/p/brlcad/patches/435/
https://sourceforge.net/p/brlcad/patches/444/
https://sourceforge.net/p/brlcad/patches/446/

All of these contains images depicting the primitives generated in OpenCL mode. They have been accepted onto the BRL-CAD code base. There are still a few primitives left to be accelerated. In my opinion, this is the perfect place for a new person to start contributing (I started here as well).

Then I moved on to incorporate boolean evaluation on the GPU side so that complex figures can be generated. We decided that it was a good idea to first have an interface to call the serial boolweave() and boolfinal() functions using GPU generated segments as inputs. By doing so, we could compare results and note the performance increase achieved. However, this yielded mixed results.

I’m pretty confident weaving happened correctly, but the final boolean evaluation failed. This was sort of confirmed by PGM files generated (showing number of segments and partitions for each pixel). To make this clearer, head over this post a few weeks ago.

Next I worked on writing kernel code to implement boolean weaving. The dynamic linked list of partitions proved to be tricky, but this was expected. I decided 2*Number of primitives could work as an upperbound for the segments. This allowed me to use the same head pointer as segs (indexing partitions of an individual pixel as parts[h[2*i]] for corresponding segment segs[h[i]]).

All the compile time errors have been fixed. I can’t really test this however, because boolean evaluation needs to be performed before any visible results can be seen. Unfortunately, I ran out of time and was unable to implement evaluation on the GPU.

That’s the first thing that needs to be done after GSoC. An attempt to restructure bool_eval() was started by Sean and then Vasco too and can be viewed here.

That brings to an end an exciting and highly educative few months. Contributing to BRL-CAD was awesome and I will continue to do so. Lastly, I’ve added a link to a folder containing a couple of patches, depicting my work towards the interface to call CPU bool functions and the boolean weaving in OpenCL. My development logs can be found here at WordPress itself. Fingers crossed for the evaluations.

catchchaos — Thu, 11 Aug 2016 20:25:26 +0000

A quick update on yesterday’s post. I went through the code as promised. The issue does indeed seem pointer related. Fields on the CPU partition structure (seg and hit) are simply pointers. Currently I have replicated this version of partition, but I doubt this can be achieved on the GPU. I’ll explore this a little more and see what can be done.

Pointer Usage

catchchaos — Wed, 10 Aug 2016 19:07:29 +0000

I think the run time errors are due to improper use of pointers. I believe I’m assigning values to seg and part pointers without allocation memory appropriately first. Obviously malloc() can’t be used on the kernel.

So I’ll review my entire code keeping this in mind and see what I can do. If this fails too, I’ll use the debugging tools suggested to me on the BRL-CAD mailing list.

Runtime debugging

catchchaos — Fri, 05 Aug 2016 05:05:26 +0000

Like I said earlier, I fixed all the compile errors and moved onto runtime errors.

Currently the kernel weave function spits out garbage in place of partitions. I spent most of yesterday trying to figure out what was wrong. It’d be nice to have Vasco to bounce thoughts off, hut he’s still recovering from his surgery.

I tried printf statements in a loop to try to access the partitions before and after kernel execution. This leads to a segmentation fault. Runtime debugging is generally hard on the GPU.

Compile errors

catchchaos — Tue, 02 Aug 2016 19:45:47 +0000

I finished writing up an initial draft for weave on the kernel. I finally compiled it and it obviously contained a host of errors.

To prevent rebuilding after every small change, I started editing the rt.cl in share/opencl instead of the one in src.

I also wrote code for weaving 0 thickness segments. I’m very unsure about my implementation though, so I’ll need to spend some time running and fixing it. For now, it gives a segmentation fault if I run a loop to try to read all the generated partitions. I’ll try to figure out what’s wrong tomorrow.

Back to work

catchchaos — Mon, 01 Aug 2016 17:51:19 +0000

I feel a lot better after some rest and antibiotics. Back to work today.

I wrote some more kernel code for weaving and created functions to insert partitions, and add segments to partitions. I hope Vasco recovers soon, it’d be nice to have my code reviewed. Before that I need to complete at least the weaving.

I’m yet to try to compile anything. Weave0 function also needs to be written.

Fever go away

catchchaos — Wed, 27 Jul 2016 06:04:27 +0000

I got back to college for mmy new term and looks like my body isn’t liking the weather here too much. I’m down with a horrible throat infection and a fever again. I’ve been bunking class and just sleeping the whole day.

This is the worst possible time for a fever from a GSoC perspective, what with the final evaluations so close by. But there’s nothing I can do about it. My doctor says it’ll take about 3 days to go away.

First attempt at GPU weaving

catchchaos — Mon, 25 Jul 2016 19:25:38 +0000

Spent sometime writing kernel code. The primary task at hand was to convert the partition list from the doubly linked list representation. I’ve attempted to rewrite this as an array. The code is obviously untested at the moment. I haven’t even checked for compile errors as certain functions haven’t been defined.

Basically, I assumed some of the macros like APPEND_PT and INSERT_PT are functions defined on the kernel. Tomorrow I’ll define these functions as well and try to look for errors. I’ll also need to look into the unique insertion of segments into the pt_seglist field.

Partition size

catchchaos — Thu, 21 Jul 2016 05:44:57 +0000

While writing weaving kernel code I realized that list of partitions actually grows dynamically, so does list of unique segments in pt_seglist (went through my proposal just now, and this is in fact mentioned there). I took a piece of paper and doodled around a bit. Turns out 2*(number of segs) could be an upper bound (definitely not a tight one) on the number of partitions for each pixel. I’m not entirely sure of this fact as I can’t prove it mathematically, but it seems correct. So I thought I’d give it a shot.

The same head pointer “h” can be used. So for segments segs[h[i]] and for partitions parts[2*h[i]] iterates through the respective arrays. But number of partitions is mostly less than this. To prevent a segmentation fault, I’ve added a field “exists” in the partition. This can be be set to false initially and changed to to true when the particular partition gets seg and hit data. Let’s see if this works.

catchchaos — Tue, 19 Jul 2016 18:08:26 +0000

A quick one today. As I mentioned yesterday, I started work on the GPU boolean weaving. First thing I started was the kernel code for weaving. A number of sanity checks and print statements needed to be removed. I stopped at the point of creating a function to add new partition. At this point, it becomes vital to figure out how to represent the partitions on GPU. I will worl on that tomorrow.