| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Consolidated C custom code so common functions are only defined once in
the 1.1 version, then are called from the 1.2 and 2.0 version. Pulled
common code in CLImpl up into the autogenerated implementation class and
removed the hand-written implementation (since it was left empty).
Factored custom Java code out so there was as little duplication as
possible across the three CLImpl versions, with common code for all
three versions in clImplCustomCode.java.
|
|
|
|
|
| |
This makes all three versions (1.1, 1.2, and 2.0) use the same naming
convention, and sets me up to use the unversioned name to factor out
code common to all three.
|
|
|
|
| |
Adapt to GlueGen commit f5c48efcf546ba4e08e197ccced6df83b57e1755
|
|
|
|
| |
46faa59d439ef235d7691fc64d56eedc600ffa1a
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
c47bc86ae2ee268a1f38c5580d11f93d7f8d6e74)
- Change non static accesses to static members using declaring type
- Change indirect accesses to static members to direct accesses (accesses through subtypes)
- Add final modifier to private fields
- Add final modifier to method parameters
- Add final modifier to local variables
- Remove unnecessary casts
- Remove unnecessary '$NON-NLS$' tags
- Remove trailing white spaces on all lines
|
|
|
|
|
|
|
| |
These pointers were showing up as uninitialized variables; on inspection
they just weren't being passed in from the Java side or assigned on
the C side. There are currently no tests of this function, which is how
we didn't notice this omission.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|