Hi,
a feature request.. maybe LWJGL could provide OpenCL wrappers too? It seems available on many platforms now..
it will be nice, i'm agree too.
I am not sure what gain games will have for this? - but at any rate, I think that a patch would be more likely than someone from the existing contributors to work on this
LWJGL isn't used for games only and even games have a lot to gain out of OpenCL. Getting it in LWJGL is in my plans, but unfortunately I won't have time to work on it for the next 3 months (at least). So unless someone else decides to contribute, it's going to take a while.
OpenCL is useful in games, two uses I can come up with is software skinning and particle updates. OpenCL is the only way to fully take advantage of SSE instructions in java.
Then again, you can already do that, with this project: http://www.jocl.org/. Surely a LWJGL integrated solution would be useful. Perhaps the two projects can work together or something.
Another argument for having OpenCL integrated with OpenGL in LWJGL, is that OpenCL can share data with OpenGL. OpenCL can work with OpenGL textures and buffers directly. For example it would be possible to generate geometry (vertex data) using OpenCL into a buffer, then to use that buffer for rendering the geometry using OpenGL. Performance wise this is optimal, because no copying is occurring, and it all can happen on the GPU.
From a brief glance at the site - it appears to not be tied to any API as such. You should be able to use it with LWJGL too?
I do not expect that the two API's can work together, without jocl doing a license change (currently L/GPL).
I don't think mixed licenses will hurt anyone's ability to use JOCL with LWJGL.
But at any rate: JOCL's there, it does the job, doesn't need any competition from an alternative implementation for now (especially considering its extremely niche interest).
An SSE/assembler library might be nice though...
Cas :)
Quote from: VeAr on February 20, 2010, 22:05:15
Another argument for having OpenCL integrated with OpenGL in LWJGL, is that OpenCL can share data with OpenGL. OpenCL can work with OpenGL textures and buffers directly.
That is proposed but not implemented afaik. Neither Nvidia nor ATI drivers seems support that, pretty poor.
afaik thats right. you cannot share a texture properly yet. works ok with buffertype stuff like PBO's and map unmap buffer but thats not realy helping yet.
anyway. you can create an opencl image from a gl texture but you cannot (probably) write or read it ... still, I managed to create such texture and at least read out the order, format and dimensions correctly.
one thing that would be realy helpful with lwjgl is a bit support with opencl context creation. the way I did it atm is something like this:
cl_context = clCreateContextFromType ( contextProperties, CL_DEVICE_TYPE_GPU, null, null, null );
where the properties are :
[... setup platforms ...]
cl_context_properties contextProperties = new cl_context_properties ();
contextProperties.addProperty ( CL_CONTEXT_PLATFORM, platforms [ 0 ] );
but then :
Class< org.lwjgl.opengl.Display > display = org.lwjgl.opengl.Display.class;
Field display_impl = display.getDeclaredField ( "display_impl" );
Field ctx = display.getDeclaredField ( "context" );
display_impl.setAccessible ( true );
ctx.setAccessible ( true );
Method getHdc = display_impl.get ( display ).getClass ().getDeclaredMethod ( "getHdc" );
Method getHandle = ctx.get ( display ).getClass ().getDeclaredMethod ( "getHandle" );
getHdc.setAccessible ( true );
getHandle.setAccessible ( true );
long getHdcValue = ( Long ) getHdc.invoke ( display_impl.get ( display ));
ByteBuffer glHandle = ( ByteBuffer ) getHandle.invoke ( ctx.get ( display ));
glHandle.rewind ();
contextProperties.addProperty ( CL_GL_CONTEXT_KHR, glHandle.getInt ( 0 ));
contextProperties.addProperty ( CL_WGL_HDC_KHR, getHdcValue );
works for windows and JOCL. clCreateFromGLTexture2D does not return with CL_INVALID_CONTEXT anymore.
very ugly, you may see my point :)
Quotevery ugly, you may see my point
Yeah, reflection is such a nice tool!
I currently want to integrate OpenCL into my OpenGL render framework, too, for some offscreen heightfield/normalmap generation computations for generated terrains. I currently do it via shaders but at some point this is becoming a real mess. Especially the fact that coordinates need to remap from pixel centroid positions to [0.0, 1.0] again for the whole viewport and things like that. OpenCL integration into LWJGL here would be REALLY nice.
And by "OpenCL integration" I merely mean the possibility to get low-level information, such as the context and drawable handles, out of LWJGL. JOGL does a fine job with that, according to the sample applications on the JOCL http://www.jocl.org/samples/samples.html (http://www.jocl.org/samples/samples.html) site!
So for the meantime, doing it with reflection is the way I will go.
Quote from: Kai on April 26, 2010, 10:47:18
[...] JOGL does a fine job with that, according to the sample applications on the JOCL http://www.jocl.org/samples/samples.html (http://www.jocl.org/samples/samples.html) site!
So for the meantime, doing it with reflection is the way I will go.
aye! the new version shows us a realy nice way to handle that stuff.
look up the initContextProperties function in JOCLSimpleGL3.java. CL_WGL_HDC_KHR, CL_GLX_DISPLAY_KHR, CL_CGL_SHAREGROUP_KHR .. all that stuff.
just to keep it complete .. with lwjgl v.2.5 we need to do something like that. notice how the way to access the context class changed :
Class< org.lwjgl.opengl.Display > display = org.lwjgl.opengl.Display.class;
Field display_impl = display.getDeclaredField ( "display_impl" );
display_impl.setAccessible ( true );
Drawable d = org.lwjgl.opengl.Display.getDrawable ();
Method getcontext = d.getClass ().getSuperclass ().getDeclaredMethod ( "getContext" );
getcontext.setAccessible ( true );
Object ctx = getcontext.invoke ( d );
Method getHdc = display_impl.get ( display ).getClass ().getDeclaredMethod ( "getHdc" );
Method getHandle = ctx.getClass ().getDeclaredMethod ( "getHandle" );
getHdc.setAccessible ( true );
getHandle.setAccessible ( true );
long getHdcValue = ( Long ) getHdc.invoke ( display_impl.get ( display ));
ByteBuffer glHandle = ( ByteBuffer ) getHandle.invoke ( ctx );
glHandle.rewind ();
contextProperties.addProperty ( CL_GL_CONTEXT_KHR, glHandle.getInt ( 0 ));
contextProperties.addProperty ( CL_WGL_HDC_KHR, getHdcValue );
... so we can use
Drawable d = org.lwjgl.opengl.Display.getDrawable ();
Method getcontext = d.getClass ().getSuperclass ().getDeclaredMethod ( "getContext" );
.. some good news about opencl v.1.1 :
http://gpgpu.org/2010/06/18/opencl-1-1-released
maybe now, if new drivers follow, we can do proper integration into opengl. :)
Hey, just letting you know that I've started working on OpenCL support. It's been only a couple of days, so I'm still in the process of reading the specification and figuring out the best way to integrate this in LWJGL. I haven't used OpenCL before and I've no clue how long this is going to take, I'll try to give you an estimate early next week.
no hurry :) .. good news tho'!
OpenCL is very very poorly supported by drivers at this stage IME(InMyExperence). I don't think there is any rush till things stabilize to something you at least have a hope of get working on a clients computer.
I just made the first successful LWJGL OpenCL call, yay. I should be able to implement OpenCL 1.0, 1.1 + extensions over the weekend, then I'll work on the java-side API, then integration with OpenGL... should have a beta version committed by the next weekend, hopefully.
It took a while because OpenCL makes heavy use of pointer arrays and size_t parameters. I ended up implementing a PointerBuffer class that mirrors the LongBuffer API at the Java-side, but works with either 32bit or 64bit values underneath. Then I had to add support for it in our generator, do a bit of refactoring, etc.
Excellent work. Should we hold 2.6 and get that in or ?
If there's an important fix/feature in 2.6, we should go ahead and release it, OpenCL can wait.
nope - I'd also like to get opencl out there and then do a 2.6.x later on
It currently looks like that the OpenCL binding would be much cleaner/prettier if we could use generics and enums. Do you think this is a good time to move to a 1.5+ code base? Or should we wait for 3.0 (which might also include non-backwards-compatible changes)?
I'd be shocked if there is a computer out there that supports OpenCL and has Java 1.4 :)
Let me just check my "in-the-wild" Java stats to see what 1.4 VMs are still out there...
Cas :0
would retroweaver be an option?
Quote from: princec on September 20, 2010, 17:24:41
Let me just check my "in-the-wild" Java stats to see what 1.4 VMs are still out there...
Cas :0
last I checked on StatOWL, Java 1.4
and all jre versions below it only accounted for about 5% of all java installs. Java 1.5 accounted for about 15% and with the rest either having Java 6 or no java.
but will be interesting to see what stats you get from your games.
Right, stats since the great hard disk crash indicate a still reasonably sizeable 10% of the Mac-using population running Puppygames are using 1.4 for some reason. (That's unique installs too, not plays) I'm on the verge of saying "ditch them" as those running 1.4 are also mostly running 10.3.9 and 10.4.11 which are getting pretty long in the the tooth. Mac being 50% of my customer base that's a fairly sizable number of people though.
To move to Java 5 syntax and so on we should bump the major version number of LWJGL though - maybe to 3.0 - and archive the 2.5 LWJGL release so that those wanting backward 1.4 compatibility don't have to arse about retroweaving or anything.
Cas :)
just curious, how will OpenCL be integrated into LWJGL, will it just be a in the lwjgl.jar/lwjgl.dll or will it be a separate standalone optional jar and native (lwjgl-opencl.jar and opencl.dll) ?
do consider its likely to a be a small niche market for a while yet.
I was thinking about that too, might as well go for a separate jar/dll for now. I'll see how it goes first though, gonna decide when the implementation is complete.
edit: On a related note, we could do an extension cleanup soon. We support dozens of legacy extensions that can be easily removed.
yeh agreed, did notice that the lwjgl.jar has picked up some weight as of late (*shakes fist at khronos*).
e.g.
lwjgl 2.3 = lwjgl.jar (590kb)
lwjgl 2.5 = lwjgl.jar (729kb)
I took a break from OpenCL and made another change to the Generator that lets us reuse entry points. Many ARB extensions will now reuse the implementations of the core functions (even if the corresponding GL version isn't supported). A total of 287 functions have been updated to use this trick.
I just committed OpenCL support to LWJGL! For a quick preview, click here (http://i54.tinypic.com/10f1idd.jpg).
Features:
- Full OpenCL 1.0 and 1.1 support.
- All OpenCL extensions are supported.
- CL/GL interop support.
- Low-level binding (COMPLETE) + high-level API for convenience (WIP).
TODO/Known Issues:
- Need to build and test on MacOS.
- CL/GL interop is not supported in MacOS. Apparently it requires CGL and we don't use that in LWJGL.
- Need to add more high-level API, there are quite a few annoying methods that can be improved.
- It's beta quality really, needs a lot more testing. If you try it out and it breaks somewhere, or if you have a suggestion for an improvement, just let me know.
- The current codebase requires Java 1.5. Need to sort this out somehow.
awesome work!
I will test on my available platforms asap and report back.
As for the 1.5 issue. I *really* dont have an issue with it - but there might be an issue with legacy mac users. Anyone have any numbers?
I have had no problems with mac users and i force them to use java 1.6, while i get the odd email from window users. About half my users are on Macs, but this is for scientific code which could skew the stats somewhat.
I'm sure princec has some numbers.
Hudson is being weird (https://www.newdawnsoftware.com/hudson/view/LWJGL/). I've uploaded a build for people that can't build from svn:
edit:
Removed, you can download everything from Hudson now.
I tried to compile LWJGL with -g:none and lwjgl.jar drops from 819kb to 618kb, a good 25%. I can change the build script so that the debug jar is compiled with debug information and the normal jar without. Should I go for it or is it a bad idea?
shouldn't that be a deployer optimization? like using pack200 or using proguard to remove unused classes.
I think the lwjgl library should have the java debug info included.
Quote from: ruben01 on September 27, 2010, 18:15:43
shouldn't that be a deployer optimization? like using pack200 or using proguard to remove unused classes.
I think the lwjgl library should have the java debug info included.
agreed - we shouldn't be so scared about size of the java code, since it - will be - should be - obfuscated before deployment.
Windows 7, 32 bit, AMD - OK
-------------------------
NEW PLATFORM: 75289612
OpenCL 1.1 - Extensions:
-------------------------
CL_PLATFORM_PROFILE = FULL_PROFILE
CL_PLATFORM_VERSION = OpenCL 1.1 ATI-Stream-v2.2 (302)
CL_PLATFORM_NAME = ATI Stream
CL_PLATFORM_VENDOR = Advanced Micro Devices, Inc.
NEW DEVICE: 77719864
OpenCL 1.1 - Extensions: cl_amd_device_attribute_query cl_amd_fp64 cl_amd_printf cl_ext_device_fission cl_khr_byte_addressable_store cl_khr_gl_sharing cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics
-------------------------
CL_DEVICE_TYPE = 2
CL_DEVICE_VENDOR_ID = 4098
CL_DEVICE_MAX_COMPUTE_UNITS = 2
CL_DEVICE_MAX_WORK_ITEM_DIMENSIONS = 3
CL_DEVICE_MAX_WORK_GROUP_SIZE = 1024
CL_DEVICE_MAX_CLOCK_FREQUENCY = 1995
CL_DEVICE_ADDRESS_BITS = 32
CL_DEVICE_AVAILABLE = true
CL_DEVICE_COMPILER_AVAILABLE = true
CL_DEVICE_NAME = Intel(R) Core(TM)2 Duo CPU T6400 @ 2.00GHz
CL_DEVICE_VENDOR = GenuineIntel
CL_DRIVER_VERSION = 2.0
CL_DEVICE_PROFILE = FULL_PROFILE
CL_DEVICE_VERSION = OpenCL 1.1 ATI-Stream-v2.2 (302)
CL_DEVICE_OPENCL_C_VERSION = OpenCL C 1.1
-TRYING TO EXEC NATIVE KERNEL-
memobjs = 1
memobjs[0].remaining() = 128
Sub Buffer destructed: 77725336
SECOND Buffer destructed: 77725200
FIRST Buffer destructed: 77725200
NEW DEVICE: 77720344
OpenCL 1.0 - Extensions: cl_amd_device_attribute_query cl_khr_gl_sharing
-------------------------
CL_DEVICE_TYPE = 4
CL_DEVICE_VENDOR_ID = 4098
CL_DEVICE_MAX_COMPUTE_UNITS = 8
CL_DEVICE_MAX_WORK_ITEM_DIMENSIONS = 3
CL_DEVICE_MAX_WORK_GROUP_SIZE = 128
CL_DEVICE_MAX_CLOCK_FREQUENCY = 550
CL_DEVICE_ADDRESS_BITS = 32
CL_DEVICE_AVAILABLE = true
CL_DEVICE_COMPILER_AVAILABLE = true
CL_DEVICE_NAME = ATI RV730
CL_DEVICE_VENDOR = Advanced Micro Devices, Inc.
CL_DRIVER_VERSION = CAL 1.4.792
CL_DEVICE_PROFILE = FULL_PROFILE
CL_DEVICE_VERSION = OpenCL 1.0 ATI-Stream-v2.2 (302)
CL_DEVICE_OPENCL_C_VERSION = OpenCL C 1.0
Sub Buffer destructed: 77725336
SECOND Buffer destructed: 77725200
FIRST Buffer destructed: 77725200
Another update today, fixed a few bugs and the "high-level" API should be more or less complete now. Also ported the entire codebase to use Java 1.5 features.
Are we ready to release 2.6 or should we wait a bit ?
...2.6 is Java 5.0+ is it? That should be 3.0?
Cas :)
Quote from: princec on September 29, 2010, 10:46:43
...2.6 is Java 5.0+ is it? That should be 3.0?
Cas :)
oh, I thought we were saving 3.0 for major api breakage and new features but guess LWJGL 4.0 is still available :)
changes such as:
1) Moving the native window code out of the opengl package, possibly into org.lwjgl.display.*. Thus allowing way for stuff like OpenGL ES, DirectX, etc to be plugged in easily.
2) Multiple Window/Display support which would probably require api breakage.
3) Proper lightweight native window system for LWJGL on mac (Cocoa?) and not relying on AWT.
4) Proper alternative to Display.setParent and AWTGLCanvas (maybe some sort of merge).
5) Support for OpenGL ES.
etc (i'm sure theres a few others but can't recall atm).
but then again OpenGL 4.1 and OpenCL support is a pretty big addition.
oh btw just curious what about making the OpenCL stuff a standalone java 1.5 jar and native (thus keeping core LWJGL 2.x java 1.4 compatible until LWJGL 3.0)? probably not worth the effort though if the OpenCL stuff is already interweaved with LWJGL code.
Quote from: Matzon on September 29, 2010, 08:52:41Are we ready to release 2.6 or should we wait a bit ?
Doing a few tests atm, better wait a bit. In any case, I don't think the 2.6 release will be stable. The OpenCL implementation is barely tested and things will change as more people start experimenting with it and the vendors release better implementations (that may brake assumptions I've made while coding this binding). Unfortunately I don't have a proper app that I can throw at it for testing, like I can do with Marathon and OpenGL. But anyway, it doesn't really matter as long as the rest of the library works. People working with OpenCL will expect instabilities.
Quote from: kappa on September 29, 2010, 11:14:02oh, I thought we were saving 3.0 for major api breakage and new features but guess LWJGL 4.0 is still available :)
changes such as:
1) Moving the native window code out of the opengl package, possibly into org.lwjgl.display.*. Thus allowing way for stuff like OpenGL ES, DirectX, etc to be plugged in easily.
2) Multiple Window/Display support which would probably require api breakage.
3) Proper lightweight native window system for LWJGL on mac (Cocoa?) and not relying on AWT.
4) Proper alternative to Display.setParent and AWTGLCanvas (maybe some sort of merge).
5) Support for OpenGL ES.
etc (i'm sure theres a few others but can't recall atm).
but then again OpenGL 4.1 and OpenCL support is a pretty big addition.
oh btw just curious what about making the OpenCL stuff a standalone java 1.5 jar and native (thus keeping core LWJGL 2.x java 1.4 compatible until LWJGL 3.0)? probably not worth the effort though if the OpenCL stuff is already interweaved with LWJGL code.
I agree on everything. LWJGL 3.0 should be the major refactoring + API breakage. I tried to implement multiple windows sometime this summer, while trying to keep compatibility, it's a mess. If we're going to implement all of the above we'll need to redesign a lot of code.
About OpenCL, the overhead is minimal tbh, only ~100kb compared to 2.5 for lwjgl.jar. I don't think it's worth the pain of deploying an additional jar and native lib. Also, I've made a 2.5 branch on our SVN, in case we need to back-port an important 1.4-compatible fix.
I tried running the HelloOpenCL demo:
-------------------------
NEW PLATFORM: 80292888
OpenCL 1.0 - Extensions: cl_khr_d3d10_sharing cl_khr_gl_sharing cl_khr_icd
-------------------------
CL_PLATFORM_PROFILE = FULL_PROFILE
CL_PLATFORM_VERSION = OpenCL 1.0 CUDA 3.1.1
CL_PLATFORM_NAME = NVIDIA CUDA
CL_PLATFORM_VENDOR = NVIDIA Corporation
CL_PLATFORM_EXTENSIONS = cl_khr_byte_addressable_store cl_khr_icd cl_khr_gl_sharing cl_nv_d3d9_sharing cl_nv_d3d10_sharing cl_khr_d3d10_sharing cl_nv_d3d11_sharing cl_nv_compiler_options cl_nv_device_attribute_query cl_nv_pragma_unroll
NEW DEVICE: 80292992
OpenCL 1.0 - Extensions: cl_khr_byte_addressable_store cl_khr_gl_sharing cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics
-------------------------
CL_DEVICE_TYPE = 4
CL_DEVICE_VENDOR_ID = 4318
CL_DEVICE_MAX_COMPUTE_UNITS = 2
CL_DEVICE_MAX_WORK_ITEM_DIMENSIONS = 3
CL_DEVICE_MAX_WORK_GROUP_SIZE = 512
CL_DEVICE_MAX_CLOCK_FREQUENCY = 800
CL_DEVICE_ADDRESS_BITS = 32
CL_DEVICE_AVAILABLE = true
CL_DEVICE_COMPILER_AVAILABLE = true
CL_DEVICE_NAME = GeForce 8400M GS
CL_DEVICE_VENDOR = NVIDIA Corporation
CL_DRIVER_VERSION = 258.96
CL_DEVICE_PROFILE = FULL_PROFILE
CL_DEVICE_VERSION = OpenCL 1.0 CUDA
Exception in thread "main" java.lang.IllegalArgumentException: Invalid parameter specified: 0x103D
at org.lwjgl.opencl.InfoUtilAbstract.getSizeRet(InfoUtilAbstract.java:129)
at org.lwjgl.opencl.InfoUtilAbstract.getInfoString(InfoUtilAbstract.java:114)
at org.lwjgl.opencl.CLDevice.getInfoString(CLDevice.java:103)
at org.lwjgl.test.opencl.HelloOpenCL.printDeviceInfo(HelloOpenCL.java:170)
at org.lwjgl.test.opencl.HelloOpenCL.execute(HelloOpenCL.java:94)
at org.lwjgl.test.opencl.HelloOpenCL.main(HelloOpenCL.java:183)
It works okay until the exception, not sure why its happening.
EDIT: The Mandelbrot demo runs at about 17 fps.
Tnx Momoko_Fan, it's fixed now. Could you try the fractal demo with the next build and let me know if you get the same fps? You should also get a message on whether or not it runs on the GPU.
Matzon, I think I'm done now, feel free to release 2.6 whenever you can.
I found some new bugs :)
This is on a different machine, btw. With ATI Radeon HD 5770.
Exception in thread "main" java.lang.NullPointerException
at org.lwjgl.test.opencl.HelloOpenCL.execute(HelloOpenCL.java:56)
at org.lwjgl.test.opencl.HelloOpenCL.main(HelloOpenCL.java:182)
Exception in thread "main" java.lang.RuntimeException: java.lang.RuntimeExceptio
n: No OpenCL platforms found.
at org.lwjgl.test.opencl.gl.DemoFractal.init(DemoFractal.java:324)
at org.lwjgl.test.opencl.gl.DemoFractal.main(DemoFractal.java:723)
Caused by: java.lang.RuntimeException: No OpenCL platforms found.
at org.lwjgl.test.opencl.gl.DemoFractal.initCL(DemoFractal.java:343)
at org.lwjgl.test.opencl.gl.DemoFractal.init(DemoFractal.java:319)
... 1 more
Do note that it has OpenCL, I have GPU Caps Viewer installed and all the OpenCL demos work fine there.
Also, for 64 bit LWJGL only:
Exception in thread "main" java.lang.LinkageError: Version mismatch: jar version
is '23', native libary version is '22'
at org.lwjgl.Sys.<clinit>(Sys.java:105)
at org.lwjgl.opencl.CL.<clinit>(CL.java:49)
at org.lwjgl.test.opencl.HelloOpenCL.execute(HelloOpenCL.java:53)
at org.lwjgl.test.opencl.HelloOpenCL.main(HelloOpenCL.java:182)
Looks like someone needs to update lwjgl64.dll?
About the first problem: Could you run the same tests with lwjgl-debug.jar and -Dorg.lwjg.util.Debug=true and see what the output is? Also, what version of the Stream SDK is installed on that machine?
Okay here it is with HelloOpenCL.
ATI Stream version 2.2, Catalyst 10.9.
getPathFromClassLoader: searching for: OpenCL
Failed to locate findLibrary method: java.lang.NoSuchMethodException: sun.misc.Launcher$AppClassLoader.findLibrary(java.lang.String)
Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.net.URLClassLoader.findLibrary(java.lang.String)
Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.security.SecureClassLoader.findLibrary(java.lang.String)
getPathFromClassLoader: searching for: lwjgl
Failed to locate findLibrary method: java.lang.NoSuchMethodException: sun.misc.Launcher$AppClassLoader.findLibrary(java.lang.String)
Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.net.URLClassLoader.findLibrary(java.lang.String)
Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.security.SecureClassLoader.findLibrary(java.lang.String)
Found 8 OpenCL paths
T
Failed to load C:\Program Files (x86)\Java\jre6\bin\OpenCL.dll: C
T
F
Exception in thread "main" org.lwjgl.opencl.OpenCLException: Error Code: CL_PLATFORM_NOT_FOUND_KHR (0xFFFFFC17)
at org.lwjgl.opencl.Util.throwCLError(Util.java:73)
at org.lwjgl.opencl.Util.checkCLError(Util.java:66)
at org.lwjgl.opencl.CL10.clGetPlatformIDs(CL10.java:402)
at org.lwjgl.opencl.InfoUtilFactory$CLPlatformUtil.getPlatforms(InfoUtilFactory.java:293)
at org.lwjgl.opencl.CLPlatform.getPlatforms(CLPlatform.java:122)
at org.lwjgl.opencl.CLPlatform.getPlatforms(CLPlatform.java:111)
at org.lwjgl.test.opencl.HelloOpenCL.execute(HelloOpenCL.java:55)
at org.lwjgl.test.opencl.HelloOpenCL.main(HelloOpenCL.java:183)
And DemoFractal:
getPathFromClassLoader: searching for: OpenCL
Failed to locate findLibrary method: java.lang.NoSuchMethodException: sun.misc.Launcher$AppClassLoader.findLibrary(java.lang.String)
Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.net.URLClassLoader.findLibrary(java.lang.String)
Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.security.SecureClassLoader.findLibrary(java.lang.String)
getPathFromClassLoader: searching for: lwjgl
Failed to locate findLibrary method: java.lang.NoSuchMethodException: sun.misc.Launcher$AppClassLoader.findLibrary(java.lang.String)
Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.net.URLClassLoader.findLibrary(java.lang.String)
Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.security.SecureClassLoader.findLibrary(java.lang.String)
Found 8 OpenCL paths
T
Failed to load C:\Program Files (x86)\Java\jre6\bin\OpenCL.dll: C
T
F
Initial mode: 1920 x 1080 x 32 @60Hz
Could not locate symbol glEnableClientStateiEXT
Could not locate symbol glDisableClientStateiEXT
Could not locate symbol glGetFloati_vEXT
Could not locate symbol glGetDoublei_vEXT
Could not locate symbol glGetPointeri_vEXT
Could not locate symbol glGetCompressedMultiTexImage
GL_EXT_direct_state_access was reported as available but an entry point is missing
Could not locate symbol glVertexAttribL1dEXT
Could not locate symbol glVertexAttribL2dEXT
Could not locate symbol glVertexAttribL3dEXT
Could not locate symbol glVertexAttribL4dEXT
Could not locate symbol glVertexAttribL1dvEXT
Could not locate symbol glVertexAttribL2dvEXT
Could not locate symbol glVertexAttribL3dvEXT
Could not locate symbol glVertexAttribL4dvEXT
Could not locate symbol glVertexAttribLPointerEXT
Could not locate symbol glGetVertexAttribLdvEXT
GL_EXT_vertex_attrib_64bit was reported as available but an entry point is missing
Could not locate symbol glMinSampleShading
OpenGL40 was reported as available but an entry point is missing
Could not locate symbol glVertexWeighthNV
Could not locate symbol glVertexAttrib1hNV
Could not locate symbol glVertexAttrib2hNV
Could not locate symbol glVertexAttrib3hNV
Could not locate symbol glVertexAttrib4hNV
Could not locate symbol glVertexAttribs1hvNV
Could not locate symbol glVertexAttribs2hvNV
Could not locate symbol glVertexAttribs3hvNV
Could not locate symbol glVertexAttribs4hvNV
Exception in thread "main" java.lang.RuntimeException: org.lwjgl.opencl.OpenCLException: Error Code: CL_PLATFORM_NOT_FOUND_KHR (0xFFFFFC17)
at org.lwjgl.test.opencl.gl.DemoFractal.init(DemoFractal.java:324)
at org.lwjgl.test.opencl.gl.DemoFractal.main(DemoFractal.java:723)
Caused by: org.lwjgl.opencl.OpenCLException: Error Code: CL_PLATFORM_NOT_FOUND_KHR (0xFFFFFC17)
at org.lwjgl.opencl.Util.throwCLError(Util.java:73)
at org.lwjgl.opencl.Util.checkCLError(Util.java:66)
at org.lwjgl.opencl.CL10.clGetPlatformIDs(CL10.java:402)
at org.lwjgl.opencl.InfoUtilFactory$CLPlatformUtil.getPlatforms(InfoUtilFactory.java:293)
at org.lwjgl.opencl.CLPlatform.getPlatforms(CLPlatform.java:122)
at org.lwjgl.opencl.CLPlatform.getPlatforms(CLPlatform.java:111)
at org.lwjgl.test.opencl.gl.DemoFractal.initCL(DemoFractal.java:341)
at org.lwjgl.test.opencl.gl.DemoFractal.init(DemoFractal.java:319)
... 1 more
Here's the output of one of the OpenCL testing software I ran on this machine, maybe it will help debug this issue.
clGetPlatformIDs=1
cl_platform_id=0
CL_PLATFORM_PROFILE=FULL_PROFILE
CL_PLATFORM_VERSION=OpenCL 1.1 ATI-Stream-v2.2 (302)
CL_PLATFORM_NAME=ATI Stream
clGetDeviceIDs=2
cl_device_id=0
CL_DEVICE_VENDOR_ID=4098
bAlreadyUsed=FALSE
CL_DEVICE_NAME=Intel(R) Core(TM)2 Quad CPU Q8300 @ 2.50GHz
CL_DEVICE_VENDOR=GenuineIntel
CL_DEVICE_VERSION=OpenCL 1.1 ATI-Stream-v2.2 (302)
CL_DEVICE_EXTENSIONS=cl_amd_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_gl_sharing cl_ext_device_fission cl_amd_device_attribute_query cl_amd_printf cl_khr_d3d10_sharing
CL_DEVICE_MAX_COMPUTE_UNITS=4
CL_DEVICE_MAX_CLOCK_FREQUENCY=2493
CL_DEVICE_TYPE=2
bCLMoreDevicesLeft=TRUE
OpenCL.dll path=C:\Windows\system32\OpenCL.dll
bOpenCL=TRUE
bIsGPU=FALSE
......
cl_device_id=1
CL_DEVICE_VENDOR_ID=4098
bAlreadyUsed=FALSE
CL_DEVICE_NAME=Juniper
CL_DEVICE_VENDOR=Advanced Micro Devices, Inc.
CL_DEVICE_VERSION=OpenCL 1.1 ATI-Stream-v2.2 (302)
CL_DEVICE_EXTENSIONS=cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_gl_sharing cl_amd_device_attribute_query cl_amd_printf cl_amd_media_ops cl_khr_d3d10_sharing
CL_DEVICE_MAX_COMPUTE_UNITS=10
CL_DEVICE_MAX_CLOCK_FREQUENCY=850
CL_DEVICE_TYPE=4
bCLMoreDevicesLeft=FALSE
OpenCL.dll path=C:\Windows\system32\OpenCL.dll
bOpenCL=TRUE
bIsGPU=TRUE
EDIT: I also tried the new version on my other machine, the GeForce one that I tested earlier. I get this output from HelloOpenCL:
getPathFromClassLoader: searching for: OpenCL
Failed to locate findLibrary method: java.lang.NoSuchMethodException: sun.misc.Launcher$AppClassLoader.findLibrary(java.
lang.String)
Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.net.URLClassLoader.findLibrary(java.lang.Stri
ng)
Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.security.SecureClassLoader.findLibrary(java.l
ang.String)
getPathFromClassLoader: searching for: lwjgl
Failed to locate findLibrary method: java.lang.NoSuchMethodException: sun.misc.Launcher$AppClassLoader.findLibrary(java.
lang.String)
Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.net.URLClassLoader.findLibrary(java.lang.Stri
ng)
Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.security.SecureClassLoader.findLibrary(java.l
ang.String)
Found 20 OpenCL paths
T
Failed to load C:\Program Files (x86)\Java\jre6\bin\OpenCL.dll: C
T
F
-------------------------
NEW PLATFORM: 83176504
OpenCL 1.0 - Extensions: cl_khr_d3d10_sharing cl_khr_gl_sharing cl_khr_icd
-------------------------
CL_PLATFORM_PROFILE = FULL_PROFILE
CL_PLATFORM_VERSION = OpenCL 1.0 CUDA 3.1.1
CL_PLATFORM_NAME = NVIDIA CUDA
CL_PLATFORM_VENDOR = NVIDIA Corporation
CL_PLATFORM_EXTENSIONS = cl_khr_byte_addressable_store cl_khr_icd cl_khr_gl_sharing cl_nv_d3d9_sharing cl_nv_d3d
10_sharing cl_khr_d3d10_sharing cl_nv_d3d11_sharing cl_nv_compiler_options cl_nv_device_attribute_query cl_nv_pragma_unr
oll
NEW DEVICE: 83176608
OpenCL 1.0 - Extensions: cl_khr_byte_addressable_store cl_khr_gl_sharing cl_khr_global_int32_base_atomics cl_khr_global_
int32_extended_atomics
-------------------------
CL_DEVICE_TYPE = 4
CL_DEVICE_VENDOR_ID = 4318
CL_DEVICE_MAX_COMPUTE_UNITS = 2
CL_DEVICE_MAX_WORK_ITEM_DIMENSIONS = 3
CL_DEVICE_MAX_WORK_GROUP_SIZE = 512
CL_DEVICE_MAX_CLOCK_FREQUENCY = 800
CL_DEVICE_ADDRESS_BITS = 32
CL_DEVICE_AVAILABLE = true
CL_DEVICE_COMPILER_AVAILABLE = true
CL_DEVICE_NAME = GeForce 8400M GS
CL_DEVICE_VENDOR = NVIDIA Corporation
CL_DRIVER_VERSION = 258.96
CL_DEVICE_PROFILE = FULL_PROFILE
CL_DEVICE_VERSION = OpenCL 1.0 CUDA
Exception in thread "main" org.lwjgl.opencl.OpenCLException: Error Code: CL_INVALID_VALUE (0xFFFFFFE2)
at org.lwjgl.opencl.Util.throwCLError(Util.java:73)
at org.lwjgl.opencl.Util.checkCLError(Util.java:66)
at org.lwjgl.opencl.CL10.clGetDeviceInfo(CL10.java:444)
at org.lwjgl.opencl.InfoUtilFactory$CLDeviceUtil.getInfo(InfoUtilFactory.java:101)
at org.lwjgl.opencl.InfoUtilFactory$CLDeviceUtil.getInfo(InfoUtilFactory.java:98)
at org.lwjgl.opencl.InfoUtilAbstract.getSizeRet(InfoUtilAbstract.java:127)
at org.lwjgl.opencl.InfoUtilAbstract.getInfoString(InfoUtilAbstract.java:114)
at org.lwjgl.opencl.CLDevice.getInfoString(CLDevice.java:103)
at org.lwjgl.test.opencl.HelloOpenCL.printDeviceInfo(HelloOpenCL.java:170)
at org.lwjgl.test.opencl.HelloOpenCL.execute(HelloOpenCL.java:94)
at org.lwjgl.test.opencl.HelloOpenCL.main(HelloOpenCL.java:183)
The fractal demo works fine on the GeForce, but there's no change in the fps with the new LWJGL build.
Hmm. First of all I'm pretty sure you don't have the latest build. Try these:
lwjgl.jar (http://www.zdimensions.gr/spasi/lwjgl/lwjgl.jar)
lwjgl-debug.jar (http://www.zdimensions.gr/spasi/lwjgl/lwjgl-debug.jar)
lwjgl_test.jar (http://www.zdimensions.gr/spasi/lwjgl/lwjgl_test.jar)
lwjgl.dll (http://www.zdimensions.gr/spasi/lwjgl/lwjgl.dll)
About the CL_PLATFORM_NOT_FOUND_KHR error, I think you're having problems with the ICD. Try to reinstall Stream, I think I read somewhere of people having the same issue. Also make sure [HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\OpenCL\Vendors] in the registry has proper values.
Okay I updated to the latest version.
I went to
HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\OpenCL\Vendors
and it has two keys:
atiocl.dll
atiocl64.dll
Both of them set to DWORD:0
Setting them to DWORD:1 doesn't do anything.
I uninstalled ATI Stream Developer SDK and re-installed it.
Still getting the same error as before.
And by the way, JOCL Hardware Report (http://jogamp.org/jocl-demos/www/) works fine.
With the new version on the GeForce I get the same output as before but now instead of the exception I get this line
CL_DEVICE_EXTENSIONS = cl_khr_byte_addressable_store cl_khr_icd cl_khr_gl_sharing cl_nv_d3d9_sharing cl_nv_d3d10
_sharing cl_khr_d3d10_sharing cl_nv_d3d11_sharing cl_nv_compiler_options cl_nv_device_attribute_query cl_nv_pragma_unrol
l cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics
So I think that one's fixed. :)
But now, DemoFractal doesn't work :o
Exception in thread "main" java.lang.NoSuchMethodError: org.lwjgl.opencl.CLContext.create(Lorg/lwjgl/opencl/CLPlatform;L
java/util/List;Lorg/lwjgl/opencl/CLContextCallback;Lorg/lwjgl/opengl/Drawable;Ljava/nio/IntBuffer;)Lorg/lwjgl/opencl/CLC
ontext;
at org.lwjgl.test.opencl.gl.DemoFractal.initCL(DemoFractal.java:300)
at org.lwjgl.test.opencl.gl.DemoFractal.init(DemoFractal.java:256)
at org.lwjgl.test.opencl.gl.DemoFractal.main(DemoFractal.java:240)
AMD error
Hmm. Obviously LWJGL loads OpenCL.dll and is able to detect OpenCL 1.0 (at least) and run clGetPlatformIDs. There's nothing else that runs in between. Can you try a simple test please? Compile and run the following code:
public static void main(String args[]) {
try {
CL.create();
} catch (LWJGLException e) {
e.printStackTrace();
}
IntBuffer num = BufferUtils.createIntBuffer(1);
int errcode = clGetPlatformIDs(null, num);
System.out.println("Platform count = " + num.get(0));
PointerBuffer platforms = BufferUtils.createPointerBuffer(num.get(0));
errcode = clGetPlatformIDs(platforms, null);
System.out.println("Platform[0] = " + platforms.get(0));
}
NV error
Are you sure you downloaded and replaced all 4 files I linked above? How exactly do you run the test?
Quote from: spasi on October 01, 2010, 01:20:26
NV error
Are you sure you downloaded and replaced all 4 files I linked above? How exactly do you run the test?
Yes I am sure.
Here's the commandline I am using:
java -cp lwjgl-debug.jar;lwjgl_test.jar org.lwjgl.test.opencl.gl.DemoFractalSurprisingly enough, if I change the lwjgl-debug.jar to lwjgl.jar, it goes past that error, but I get a black screen, and a OpenCL compiler error:
OpenCL COMPILER OPTIONS: -D USE_TEXTURE
BUILD LOG: :66: error: use of undeclared identifier 'float3'
float3 oc = (float3)(
^
:71: error: use of undeclared identifier 'oc'
write_imagef(output, (int2)(ix, iy), (float4)(oc / 255.0, 1.0));
OK, I've updated the files above, lwjgl-debug.jar was indeed old, sorry about that. Download the 3 jars again and you should also need lwjgl_util.jar in your classpath for the fractal demo. The compiler error should be fixed as well, apparently OpenCL 1.0 didn't have support for 3-component vectors, weird. :)
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x09fb3870, pid=1896, tid=3784
#
# JRE version: 6.0_21-b07
# Java VM: Java HotSpot(TM) Client VM (17.0-b17 mixed mode, sharing windows-x86 )
# Problematic frame:
# C [nvcompiler.dll+0x493870]
#
# An error report file with more information is saved as:
# E:\DeleteMe2\hs_err_pid1896.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Its attack of the evil errors! There's no escape!
Yeah, you fix a small error, then a bigger one pops up. Big animal eating smaller animal, etc..
The error happens when compiling the program:
org.lwjgl.opencl.CL10.nclBuildProgram(JILjava/nio/ByteBuffer;ILjava/nio/ByteBuffer;IJJJ)I
It seems like a common error that happens with OpenCL program doing incorrect things.
Also, passing the "-forcePBO" argument fixes the issue, so its gotta be in the way textures are handled.
I switched to my old 8800GTX and managed to fix this. I also applied for NV’s GPU Computing developer program, I'll try to do some tests with their 1.1 implementation when I gain access. Lets hope they release it soon enough, getting crashes because of compilation errors is not good. Btw, my 8800GTX was running the fractal demo at ~230 fps.
I've updated the jars above if you'd like to verify this.
About the clGetPlatformIDs problem on Stream, were you able to run that test code I posted above?
I wasn't able to test it on ATI yet, sorry.
With the latest jars, it seems to work on the GeForce.
Don't worry about the low framerate, the GeForce 8400M GS is an entry level card that has very low performance.
Here's a comparison: http://www.gpureview.com/show_cards.php?card1=474&card2=531
The 8400 has 25.6 GFLOPS, while 8800 has 345.6 GFLOPS.
Thats a ratio of 13:1, so the 17 fps I am getting * 13 = 230, which is the fps you're getting :P
Okay I ran it on the ATI
Platform count = 1
Platform[0] = 87741452
EDIT: Hey what do you know .. The HelloOpenCL test works now!
-------------------------
NEW PLATFORM: 87479308
OpenCL 1.1 - Extensions: cl_khr_d3d10_sharing cl_khr_icd
-------------------------
CL_PLATFORM_PROFILE = FULL_PROFILE
CL_PLATFORM_VERSION = OpenCL 1.1 ATI-Stream-v2.2 (302)
CL_PLATFORM_NAME = ATI Stream
CL_PLATFORM_VENDOR = Advanced Micro Devices, Inc.
CL_PLATFORM_EXTENSIONS = cl_khr_icd cl_amd_event_callback cl_khr_d3d10_sharing
NEW DEVICE: 89972192
OpenCL 1.1 - Extensions: cl_amd_device_attribute_query cl_amd_fp64 cl_amd_printf cl_ext_device_fission cl_khr_byte_addressable_store cl_khr_gl_sharing cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics
-------------------------
CL_DEVICE_TYPE = 2
CL_DEVICE_VENDOR_ID = 4098
CL_DEVICE_MAX_COMPUTE_UNITS = 4
CL_DEVICE_MAX_WORK_ITEM_DIMENSIONS = 3
CL_DEVICE_MAX_WORK_GROUP_SIZE = 1024
CL_DEVICE_MAX_CLOCK_FREQUENCY = 2493
CL_DEVICE_ADDRESS_BITS = 32
CL_DEVICE_AVAILABLE = true
CL_DEVICE_COMPILER_AVAILABLE = true
CL_DEVICE_NAME = Intel(R) Core(TM)2 Quad CPU Q8300 @ 2.50GHz
CL_DEVICE_VENDOR = GenuineIntel
CL_DRIVER_VERSION = 2.0
CL_DEVICE_PROFILE = FULL_PROFILE
CL_DEVICE_VERSION = OpenCL 1.1 ATI-Stream-v2.2 (302)
CL_DEVICE_EXTENSIONS = cl_amd_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_gl_sharing cl_ext_device_fission cl_amd_device_attribute_query cl_amd_printf cl_khr_d3d10_sharing
CL_DEVICE_OPENCL_C_VERSION = OpenCL C 1.1
-TRYING TO EXEC NATIVE KERNEL-
memobjs = 1
memobjs[0].remaining() = 128
Sub Buffer destructed: 89976880
SECOND Buffer destructed: 89980384
FIRST Buffer destructed: 89980384
NEW DEVICE: 89961696
OpenCL 1.1 - Extensions: cl_amd_device_attribute_query cl_amd_media_ops cl_amd_printf cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_gl_sharing cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics
-------------------------
CL_DEVICE_TYPE = 4
CL_DEVICE_VENDOR_ID = 4098
CL_DEVICE_MAX_COMPUTE_UNITS = 10
CL_DEVICE_MAX_WORK_ITEM_DIMENSIONS = 3
CL_DEVICE_MAX_WORK_GROUP_SIZE = 256
CL_DEVICE_MAX_CLOCK_FREQUENCY = 850
CL_DEVICE_ADDRESS_BITS = 32
CL_DEVICE_AVAILABLE = true
CL_DEVICE_COMPILER_AVAILABLE = true
CL_DEVICE_NAME = Juniper
CL_DEVICE_VENDOR = Advanced Micro Devices, Inc.
CL_DRIVER_VERSION = CAL 1.4.815
CL_DEVICE_PROFILE = FULL_PROFILE
CL_DEVICE_VERSION = OpenCL 1.1 ATI-Stream-v2.2 (302)
CL_DEVICE_EXTENSIONS = cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_gl_sharing cl_amd_device_attribute_query cl_amd_printf cl_amd_media_ops cl_khr_d3d10_sharing
CL_DEVICE_OPENCL_C_VERSION = OpenCL C 1.1
Sub Buffer destructed: 89976880
SECOND Buffer destructed: 89980384
FIRST Buffer destructed: 89980384
Nice! What about the fractal demo?
Fractal works as well .. about 150 fps.
Cool, I was also able to test on a macbook last night, it works there too except native kernels (probably useless in Java) and GL sharing (we need to re-implement our Mac context implementation?).
So, famous last words I know, but:
Quote from: spasi on September 30, 2010, 19:14:22Matzon, I think I'm done now, feel free to release 2.6 whenever you can.
Quote from: spasi on October 02, 2010, 16:18:33
(we need to re-implement our Mac context implementation?).
Yup, infact we should reimplement the whole mac windowing system to use Cocoa directly instead of through AWT.
Quote from: spasi on October 02, 2010, 16:18:33
Cool, I was also able to test on a macbook last night, it works there too except native kernels (probably useless in Java) and GL sharing (we need to re-implement our Mac context implementation?).
So, famous last words I know, but:
Quote from: spasi on September 30, 2010, 19:14:22Matzon, I think I'm done now, feel free to release 2.6 whenever you can.
ok, I will look into it at the beginning of the comming week. bit busy this weekend :/
Does anyone know of some JOCL online applets? It'd be cool to have that kind of in-browser computing power.
Hi guys,
I realise this topic is old, but seemed the best place to put my question :)
I tried the sum example but seems that
platform.getDevices(CL10.CL_DEVICE_TYPE_GPU);
returns null. I tried Aparapi not long ago so I have the OpenCL SDK from AMD already installed.
Any help would be appreciated
Thanks
Does it work with CL_DEVICE_TYPE_CPU?
Yup :)
Means your graphics card's driver doesn't have support for OpenCL, but your CPU does.
Well that can't be right. It's a 6850 from AMD and I've run OpenCL code on it before with aparapi
(http://s30.postimg.org/mxlkvr89t/opencl.png)
Ok, found the problem. I was trying to get GPU type devices from platform 0 which doesn't have any:) What I needed to do is get the devices from platform 1. Realised this after running HelloOpenCl :)
Thanks
Quote from: basil on September 09, 2010, 22:08:56
just to keep it complete .. with lwjgl v.2.5 we need to do something like that. notice how the way to access the context class changed :
..( ugly reflection code )..
... so we can use
Drawable d = org.lwjgl.opengl.Display.getDrawable ();
Method getcontext = d.getClass ().getSuperclass ().getDeclaredMethod ( "getContext" );
...
just to keep it complete again .. with lwjgl 2.9.1 and it's very nice openCL integration it's now very easy to use LWJGL with JOCL. it's too clear to be missed but it may be still useful to somebody.
with this little helper method you can get all values required for a gl-shared opencl context :
public static long[] getOpenCLSharingProps()
{
try
{
PointerBuffer propsBuffer = new PointerBuffer(4);
Display.getDrawable().setCLSharingProperties(propsBuffer);
propsBuffer.rewind();
long[] sharingProps = new long[propsBuffer.limit()];
while(propsBuffer.hasRemaining()) sharingProps[propsBuffer.position()] = propsBuffer.get();
return sharingProps;
}
catch(LWJGLException e)
{
Logger.log.error(e);
}
return null;
}now, when you create the jocl context properties :
[...]
cl_context_properties contextProperties = new cl_context_properties();
contextProperties.addProperty(CL_CONTEXT_PLATFORM,platforms[platform]); // defined somewhere else
if(shareProps != null) // shareProps is that long[] array
{
for(int i = 0; i < shareProps.length; )
{
long prop = shareProps[i++];
long value = shareProps[i++];
// that verify is not really required :
if( //
prop != CL_GL_CONTEXT_KHR && //
prop != CL_WGL_HDC_KHR && //
prop != CL_GLX_DISPLAY_KHR && //
prop != CL_CONTEXT_PROPERTY_USE_CGL_SHAREGROUP_APPLE) throw new UnsupportedOperationException("prop : " + prop + " value : " + value + " is not supported.");
contextProperties.addProperty(prop,value);
}
}
[...]works with windows and linux but i cannot confirm apple. actually i cannot find any CL_CONTEXT_PROPERTY_USE_CGL_SHAREGROUP_APPLE constant in jocl, what am i missing ? some extension .. or is lwjgl's cl-binding just more advanced ?
Does anyone know how to debug OpenCL scripts under LWJGL in java?
What are the ways?
I know only one decision, but it only for linux
http://suhorukov.blogspot.com/2011/12/opencl-kernel-debugging-for-java-host.html
it does'not work under windows.
Does anybody know windows solution?
My project https://github.com/proton2/java-leven
For example working with OpenCL in LWJGL.
Voxels - Dual Contouring Chunking LODs with seams
Nick Gildea Dual Contouring https://github.com/nickgildea/leven implementation in Java LWJGL
CPU and OpenCL GPU implementations.