Using ulong instead of uint in OpenCL for device array indexing - c++

Question

I am programming a project for tomographic reconstruction in OpenCL. Until now all my device structures had length less than MAXUINT32. Now I am facing the problem for some big datasets, this is too restrictive and I would need possibility to index by UINT64, represented by ulong type in OpenCL. Some of the kernels need to use array size as argument and apparently it is forbidden to use size_t in kernel arguments, especially on NVidia platforms.
I have two use cases, the code computing partial sums by two methods. The first do not have to use ulong in kernel argument since the block of the memory partialFrameSize on which each instance will work does not exceed MAXUINT32.
void kernel FLOATvector_SumPartial(global const float* restrict x,
global float* restrict sumPartial,
private uint partialFrameSize)
{
uint gid = get_global_id(0);
uint start = gid * partialFrameSize;
uint end = start + partialFrameSize;
float sum = 0.0f;
float val;
for(uint i = start; i < end; i++)
{
val = x[i];
sum += val;
}
sumPartial[gid] = sum;
}
Second is doing the same using fancier implementation and barrier calls. Because of the memory alignment, it needs to have parameter private uint vecLength, which needs to be changed to private ulong vecLength.
void kernel FLOATvector_SumPartial_barrier(global const float* restrict x,
global float* restrict partialSum,
local float* loc,
private uint vecLength)
{
uint gid = get_global_id(0);
uint gs = get_global_size(0);
uint lid = get_local_id(0);
uint ls = get_local_size(0);
float val;
if(gid < vecLength)
{
val = x[gid];
} else
{
val = 0.0;
}
loc[lid] = val;
barrier(CLK_LOCAL_MEM_FENCE);
for(uint stride = ls / 2; stride > 1; stride >>= 1) // Does the same as /=2
{
if(lid < stride)
{
loc[lid] += loc[lid + stride];
}
barrier(CLK_LOCAL_MEM_FENCE);
}
if(lid == 0)
{
gid = get_group_id(0);
partialSum[gid] = loc[0] + loc[1];
}
}
I have the following questions:
How big overhead, e.g. on NVidia V100 architecture, will be when I
replace all uint simply by ulong.
Will using size_t instead of uint in the first kernel be without any overhead?
How this can be solved in CUDA? Shall I switch?

Answer 1

If you want to use 64-bit indexing, you can use unsigned long long type. This is a 64-bit type on any platform, and it is not implementation defined, as far as the acceptable platforms go for usage of OpenCL or CUDA on a NVIDIA GPU.
How big overhead, e.g. on NVidia V100 architecture, will be when I replace all uint simply by ulong.
It should be simple enough just to test that.
Will using size_t instead of uint in the first kernel be without any overhead?
size_t, on a 64-bit platform (e.g. 64-bit OS), would have the same overhead as switching to 64-bit indexing using unsigned long long.
How this can be solved in CUDA? Shall I switch?
CUDA shouldn't be meaningfully different in this respect. It has no restrictions around usage of size_t for kernel arguments, and all current CUDA development would be on a 64-bit platform, which means that size_t would be a 64-bit unsigned integer type, just like unsigned long long. However if we compared OpenCL using unsigned long long and CUDA using unsigned long long, there should be no meaningful difference. And there would be no difference in CUDA using size_t vs. unsigned long long (again, for typical current development, on a 64-bit platform).