-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
64-bit capable containers #17
Comments
I vote for cl_ulong. |
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. |
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. |
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. |
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. |
From my other projects we were taking cl_ulong for sizes. Be careful with the matrices, type for indexes are important. |
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
The text was updated successfully, but these errors were encountered: