C-Ray 1.1 for Parallella!

[jar]

C-Ray is a common ray tracer benchmark for parallel systems that has a very high arithmetic intensity and a small amount of data -- making it quite suitable for offload to Epiphany. I tinkered with this about a year ago just for fun but have finally gotten around to updating it with the COPRTHR-2. There are some modifications from the original code which are described in the README. The code is fairly simple but has some interesting uses of the COPRTHR-2 interface including the unified virtual memory (shared between the ARM host and Epiphany cores) and device-side mutexes for parallel load balancing.

You may view the code here:
https://github.com/jar/c-ray-1.1-coprthr2

[aolofsson]

Very nice!

[theover]

I've a background in CG machine design, so naturally I would have to be interested in nice graphics!

It's only spheres, light and cam, right ? No polygons, textures, or solids of some kind, that's a shame for a good example of the Epiphany as ray tracer, to check out whether the bus bandwidth and practical FLOPs check out right it would be nice to use a bit more widely applicable natural example scenes as test material.

I've considered trying a Bezier surface renderer, for which I've made a (basic) FPGA design a decade ago, but it's some work before it really becomes something that compares with POVray or what have you so that people can understand the value of the primitives, the language, and in this case, the acceleration power of the Parallella and maybe some helper libs for parallelization.

T.

[jar]

[theover]

In ray tracing, there are usually some options for the computations that follow from the geometry in terms of vector component based math versus sin/cos type as well as various intersection computations methods. I don't remember the easiest ray-sphere computation, but if you take your ray-sphere intersect code for instance you should be able to compute the number of main compute instructions need to go in there, like a number of multiplies and additions (the cheapest instructions for the Epiphany costing a small number of clock cycles), and maybe an estimate of things like comparing for closest, preparing ray-data and setting up intermediate constants or something. Once you know what the absolute optimal instruction count for the inner loop computations should be, it becomes more fun to compare how well the actual program coming from the compiler comes close to that. Since you have the "database" of graphics object on each core, as you write you need scheduling data and pixels for the resulting image to go through the communication means, for which it can also be theoretically computed what bandwidth is required such that with optimal computations on each core, you could find out whether the application for in this case the Epiphany is bandwidth limited or Flops limited.

T.