Description
Hello Marco,
I've come across an issue with memory consumption of my ray tracer , in which it implements a stream compaction as described here. This uses the prefix sum approach. For example, my intersection struct has like 10 variables with float4, float2, int, int4 and thus I result to implementing jocl experimental struct from jocl website.
Due to large memory consumption on a 4GB laptop, running the ray tracer is hectic. Needs to run in server mode jvm so as to go beyond 1200m Xmx in java8. Coz my intersection struct is an array of 480000 (800 x 600 screen space), that takes a lot of java memory together with temporary array for swapping same size when compacting intersection.
I did make a simple struct implementation that can utilize an array but only uses java primitives (int/float), only useful when you use one type of variable in a struct, and OpenCL loves that approach of forced struct data alignment. It has worked well in terms of loading large scenes (Wavefront OBJ), which everything is float4 hence array of floats. And it's the default implementation for scene data. Unlike a java class which stores extra data, hence resource consuming for large arrays of class objects, primitives do well in java. I discovered alternative approaches of struct implementation like Taleo-JUnion, which takes a similar approach. It allows use of different types of primitives and inner struct and lays that in bytebuffer. Works like a class but fast like a primitive in java. Unfortunately if I transfer by the bytebuffer to opencl using jocl, the values of a simple struct with different type variables doesn't work. Data results are jumbled up when assigned in a kernel. JUnion uses native order, but it seems you can configure the order of bytebuffer. If I could ask, how does jocl experimental Struct able to map data well to GPU?
By the way, I can make a simple example of prefix sum for use in your website since prefix sum is like the hello world of parallel programming, compatible with OpenCL 1.2.
Joe.