64-bit capable containers

[kknox]

Currently, all of our C-based structs store their dimension sizes as cl_int. This limits the sizes of the sparse matrices our library supports to 2-billion (this was chosen without much thought at the time). Should we possibly redefine the structs to include all sizes as cl_ulong, or possible size_t? Size_t may be problematic, in that OpenCL does not allow size_t types as kernel arguments
From spec:
Arguments to __kernel functions in a program cannot be declared with the built-in scalar types bool, half, size_t, ptrdiff_t, intptr_t, and uintptr_t

[jpola]

I vote for cl_ulong.

[kknox]

I also lean in this direction; it would be nice to think we could handle 64bit sizes, but what would be the occurance of this in the 'real world'? Is it enough to just change cl_int to cl_uint? 64-bit data/registers can reduce kernel performance.

[jpola]

If we change that we need to check if the kernel wrapper is receiving correct data type and probably the kernel parameters string need to be changed accordingly. kernel parameter string defines the types of the kernel parameters by substituting #define variables in the kernel code.

I will take care of it.

[kknox]

The decision of whether we should switch our structures to use 64-bit members is somewhat dependent on how this affects kernel performance. I talk about this some in this comment: #20 (comment)

This idea is dependent on the new benchmark framework proposed in #21. We need to be able to measure performance of this change to determine if this is appropriate.

[kknox]

I've going to take care of this as I work on SpM-dM.

I've been looking at the OpenCL API, and all the API's that take size parameters are taking size_t's. I think that is a good standard, and I am going to work on changing our data structures to use size_t's. We have to be careful not to copy size_t's to clSetKernelArg(), because the device may have a different address depth than host. We should dynamically detect the address depth of the device and cast the values we pass into clSetKernelArg() and equivalents.

[jpola]

From my other projects we were taking cl_ulong for sizes. Be careful with the matrices, type for indexes are important.