From my research, I have found that it is not possible to allocate memory from inside RenderScript. For example, int* values = new int[10];
isn't allowed in C99. I would like this array to be local only to the current pixel being processed, which such a dynamic allocation would guarantee if it's declared and instantiated from inside the kernel function.
I know that int values[10];
is a valid declaration. If I put it in the beginning of the RenderScript, it becomes a global array, which we would be able to set from Java code (using an Allocation
).
I tried putting int values[10];
inside the kernel, which I assumed would be local to the current pixel. I know that declaring a single-value variable (like uint32_t, float4, etc.) is definitely local to the current pixel. However, an array declared inside the kernel is still a global variable - all the other pixels can read from and write to it.
uchar4 RS_KERNEL mykernel(uchar4 in, uint32_t x, uint32_t y){
int* values = (int*)malloc(sizeof(int)*256); // illegal
int* values2 = new int[256]; // illegal
int values3[256]; // legal, but it's global. I want a local array
}
In case you're wondering, I want to access neighboring pixels from the current pixel (x, y). I've been able to pull that. However, I need to store some pixel information (like one each of those neighboring pixels' color component) in an array because I may need to pick out the most frequently-occurring color component, the exact middle component once that array is sorted, etc. So, I'm trying to pull mode and median filters, and even an oil painting effect - all of which need me to store neighboring pixel data in local arrays.
So, how can we declare a local/private array in RenderScript, which only the current pixel being processed can touch? If that's not possible, how do I simulate local array requiring tasks with only single-value variables?
Update
The int values3[256];
above IS indeed local to the current thread. It turns out that it may contain trash values that we don't want. I assumed that the value at each index is 0 by default. Some are, some aren't. That's why I thought that all the other threads were writing to it. I intended for the above to be tallies, so I wasn't always starting at 0 as expected. That's why my calculations were off!