| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 'clGetExtensionFunctionAddress' function pointer declaration was faulty,
i.e. using CL_API_ENTRY instead of CL_API_CALL.
CL_API_CALL on windows is defined as '__stdcall' which impacts Window 32bit platforms.
Fixed same issue w/:
- clCreateContext
- clBuildProgram
Same issue occurs with _all_ gluegen generated native function wrappers,
i.e. CL_API_CALL is missing in the function declarations!
I will follow-up w/ this fix in a bit ..
|
| |
|
|
|
|
|
|
|
|
|
| |
Use DynamicLibraryBundleInfo w/ alternative native library names,
drop manual coding of loading and binding, i.e. JOCLJNILibLoader.
After trying opencl native libs (and failing), try GL libs ..
We use a manual impl. to CL's 'clGetExtensionFunctionAddress' similar to JOAL, JOGL ...
|
| |
|
| |
|
| |
|
|
- split up CL into multiple sub interfaces
- seperation is now feature wise
- introdused llb package for low level classes
|