I could run all the JCUDA examples successfully on the SAMPLE page except those interact with JOGL (JCUDA/JOGL interoperability).
I have downloaded the packages and libs required by JOGL and could run simple JOGL demo. So I think I’ve properly setup the environment for JOGL.
When I run the sample JCudaDriverGLSample3.java, I’ve got an CUDA_ERROR_UNKNOWN at line cuGLCtxCreate(glCtx, 0, dev) in initJCuda(). After doing some search, I thought that I should add cuGLInit() before cuGLCtxCreate(glCtx, 0, dev). However, I’ve found the error would occur at cuGLInit() and it seems that cuGLInit() is deprecated since CUDA 3.0.
Now I’ve no idea how to run this demo and ask for help. My laptop is Thinkpad T420 with win7 32bit OS, CUDA 4.0, and a NVS 4200m card (compute capability 2.1).
I looked at the code and documentation again, but could not yet find an explaination for that.
There sometimes are some … “limitations” for the Notebook Graphics cards (i.e. those that carry an ‘M’, for ‘mobile’, in their name), but I can’t imagine that this applies to buffer sharing in general, especially since it’s a very new card.
Do you have the chance to run the ‘simpleGL’ example from the SDK? Although it uses the Runtime API and does not involve an explicit call to cuGLCtxCreate, it has served as the basis for the JCuda sample, and is also a simple example to demonstrate buffer sharing. To see whether it works or not might help to narrow down the range of possible reasons for this error…
I can run the simpleGL example downloaded from NVIDIA’s SDK website (cool).
The following is the stack trace printed by JCudaDriverGLSample3.java:
Exception in thread “AWT-EventQueue-0-AWTAnimator-1” javax.media.opengl.GLException: jcuda.CudaException: CUDA_ERROR_UNKNOWN
at jogamp.opengl.awt.AWTThreadingPlugin.invokeOnOpenGLThread(AWTThreadingPlugin.java:98)
at jogamp.opengl.ThreadingImpl.invokeOnOpenGLThread(ThreadingImpl.java:197)
at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:164)
at javax.media.opengl.awt.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:792)
at javax.media.opengl.awt.GLCanvas.display(GLCanvas.java:398)
at com.jogamp.opengl.util.AWTAnimatorImpl.display(AWTAnimatorImpl.java:74)
at com.jogamp.opengl.util.AnimatorBase.display(AnimatorBase.java:142)
at com.jogamp.opengl.util.Animator$MainLoop.run(Animator.java:174)
at java.lang.Thread.run(Unknown Source)
Caused by: jcuda.CudaException: CUDA_ERROR_UNKNOWN
at jcuda.driver.JCudaDriver.checkResult(JCudaDriver.java:249)
at jcuda.driver.JCudaDriver.cuGLCtxCreate(JCudaDriver.java:11657)
at MiniCUDA.JCudaDriverGLSample3.initJCuda(JCudaDriverGLSample3.java:368)
at MiniCUDA.JCudaDriverGLSample3.init(JCudaDriverGLSample3.java:321)
at jogamp.opengl.GLDrawableHelper.init(GLDrawableHelper.java:132)
at jogamp.opengl.GLDrawableHelper.init(GLDrawableHelper.java:151)
at javax.media.opengl.awt.GLCanvas$InitAction.run(GLCanvas.java:881)
at jogamp.opengl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:336)
at javax.media.opengl.awt.GLCanvas$DisplayOnEventDispatchThreadAction.run(GLCanvas.java:915)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$000(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Actually, I was confused by the version of JOGL (or OpenGL). I need to modify the souce code of JCudaDriverGLSample3.java to remove compiling errors. That is changing GL3 to GL2 throughout the file. And I only put four dll files (gluegen-rt.dll, jogl_desktop.dll, nativewindow_awt.dll, nativewindow_win32.dll) in the project’s directory.
I guess more dll files are required but I do not know exactly which is required. Or, something else is wrong.
(Admittedly, I’ve also only once figured out the minimal set of files for JOGL for an older version, but I think for the newest version, as a first test (!) you can just unpack all DLLs and JARs, and add ‘gluegen-rt.jar’ and ‘jogl-all.jar’ to the project build path)
I’ve downloaded the newest version (jogamp-windows-i586.7z) you provided and unpack ‘gluegen-rt.jar’ and ‘jogl-all.jar’ into the build path. However, the program still failed with this message:
Exception in thread “main” javax.media.opengl.GLException: Profile GL3 is not available on null, but: [GLProfile[GL2ES2/GL2], GLProfile[GL2ES1/GL2], GLProfile[GL2/GL2], GLProfile[GL2/GL2], GLProfile[GL2GL3/GL2]]
at javax.media.opengl.GLProfile.get(GLProfile.java:655)
at javax.media.opengl.GLProfile.get(GLProfile.java:668)
at MiniCUDA.JCudaDriverGLSample3.main(JCudaDriverGLSample3.java:49)
which makes me change all ‘GL3’ to ‘GL2’ last time (not the compiling error but runtime error).
Another thing surprising me is that it looks like I do not need to deploy the dll files (e.g., gluegen-rt.dll) under the project’s directory. But when setting up the JCuda environment, the dll files (e.g., JCudaDriver-windows-x86.dll) are required to copy to project’s directory.
Concerning the DLL files: Jogamp have added some JAR files that contain the DLL files, namely the JAR files that contain the word “natives”. The DLL files are unpacked from these JARs at runtime, and can be used as an alternative to putting the DLLs into the directory manually. But when you did NOT add these “…natives” JAR files, it could be that it still finds old DLLs somewhere else, and this could contribute to the error.
(You could try to make sure that you don’t have any out-dated JOGL DLLs in any visible path, but do NOT delete any DLLs when you are not absolutely sure that they are not needed any more!!!)
According to that, the reason might be that JOGL is using the built-in Graphics Card from the Notebook. Maybe you can start looking for a solution based on the Bug report and the links it contains. If this does not help, I can try to read the links and hints later and see if I find further ideas.
The problem is that my laptop has two video cards. When using the built-in card (Intel), the program would fail. Switch to the NVIDIA card (more powerful) is the solution.
Maybe a hint might be helpful how this “Switching” did work, just for the case that someone finds this thread and is searching for an answer. I considered that it might help to deactivate the Built-In Card in the BIOS, but presumably, there is an alternative solution, maybe something with the configuration of JOGL…?
This way is not usually seen because I never use a laptop with two graphic cards.
After the installation of NVIDIA driver obtained from CUDA website, there would be an option when you right click the .exe files. One is using built-in card to execute the program you click, another is using the NVIDIA card.
I’ve notice this feature (switching between two cards, and I’ve also seen some laptops use hard switch on the keyboard) before running this example, but I know the purpose of this feature until now. Maybe it is a soft way to switch two cards, not hard switch, not in BIOS, for convinence.
Hello Marco,
I had a similar problem. My laptop has the „optimus“ technology and two graphics cards (Intel and NVIDIA 620M).
I can see that running the class files externally using a terminal window works fine but I am unable to run the sample inside Eclipse (I’m on linux and I’m using bumblebee to use the optimus feature).
I think I know where the problem is! in
GLProfile profile = GLProfile.get(GLProfile.GL3);
the get function is using the default graphics card (which is Intel) to get the profile and continue the program. I just found out about the JOGL library today and I am not really familiar with it.
I see that there are additional overloads of the get method (specifically the one that gets an AbstractGraphicsDevice instance). Is there a way to tell JOGL to use another graphics device rather than the default one? In that case, your example could work on any computer with just a minor modification.
Admittedly, don’t understand exactly how the „optimus“ technology relates to this problem. And additionally, I’m not an expert with OpenGL and JOGL, and especially its Profile handling… I once saw http://jogamp.org/jogl/doc/bouml/html-svg/ , but usually, as soon as I have a black window and can do the ‚gl*‘ calls, I’m happy although I see that there is an increasing number of different devices, and I should probably try to better understand the concepts behind that.
Maybe I can try to generalize the example and see whether it’s possible to tell JOGL about which device it should use, but I’d first try to search the Jogamp forums for some information about that. I’ll put this on my ‚todo‘ list - right behind the task to „Create an example of JCuda+LWJGL-Interoperability“
Are you intending to use the GL interoperability with JOGL?
Admittedly, don’t understand exactly how the „optimus“ technology relates to this problem. And additionally, I’m not an expert with OpenGL and JOGL, and especially its Profile handling… I once saw http://jogamp.org/jogl/doc/bouml/html-svg/ , but usually, as soon as I have a black window and can do the ‚gl*‘ calls, I’m happy although I see that there is an increasing number of different devices, and I should probably try to better understand the concepts behind that.
Maybe I can try to generalize the example and see whether it’s possible to tell JOGL about which device it should use, but I’d first try to search the Jogamp forums for some information about that. I’ll put this on my ‚todo‘ list - right behind the task to „Create an example of JCuda+LWJGL-Interoperability“
Are you intending to use the GL interoperability with JOGL?
bye
Marco[/QUOTE]
Hello Marco,
Thank you for the fast reply. Actually I am not really good with OpenGL (I only know basic stuff and like yourself, seeing a black window makes me really happy! :D)
But for my thesis, since it is related to computer vision and machine learning, I need to do visualization and the visualization’s data is generated by CUDA.
I really don’t know if I am going to use JOGL but I am sure I will need to use OpenGL at some point. I tried LWJGL yesterday and it seems to be really close to vanilla C OpenGL.
I would be grateful if you could provide LWJGL Interoperability as well. Using modifies versions of the samples you provide, I would be able to focus on the actual research and not the programming side
I tried JOGAMP forums with not much luck…
Thank you very much in advance.
Well, for JOCL I created samples using either JOGL or LWJGL (see http://www.jocl.org/samples/samples.html, the LWJGL sample is rather similar to the JOGL sample), however, it’s hard to give any recommendations concerning LWJGL or JOGL.
I always have some doubts when a small sample is used as-it-is as a basis for further development. Usually the structure of a real ‘application’ is completely different from the structure of such a sample, where 1000 lines of code are pragmatically put together in order to create a single class that can be compiled and run without further dependencies. But I see that if the intention is not to write an ‘application’, but just to “get the data on the screen somehow”, this might at least to some extent be feasible.
Thre are still some other important tasks in my queue, but creating the sample should not be too difficult, so maybe I can do this soon. However, the question about which device is going to be used will probably have to be answered for LWJGL as well…
Hello Marco,
I suspect another thing might be causing the error (totally unrelated to setting the adapter in use).
As you may be aware I am using Linux and to use JCuda I must set LD_PRELOAD (as per instructions in http://forum.byte-welt.net/showthread.php?t=4038 )
I have discovered that when I don’t set the LD_PRELOAD to libcuda.so, OpenGL in fact initializes and shows the black (!) window but JCuda fails to start (throws error undefined symbol cuInit)
However, when I do set LD_PRELOAD, JCuda initializes successfully but OpenGL (both JOGL and LWJGL) fail to initialize and throw exceptions.
The interesting thing is that when I do this inside Eclipse (in Run Configurations), this behavior is manifested but if I just package the whole project in a JAR file and run it using a terminal window, everything works…
As much as I don’t like Linux, I still need to use it because of the setup environment that I have at school.
OK, as I mentioned in the other thread: I’m not so familiar with Linux. I have read about this LD_PRELOAD-Thing, but did not quite understand it.
Which exceptions are thrown by OpenGL when you use LD_PRELOAD? (And, by the way: I’d be curious whether it works when you do not compile it into a JAR, but start it from the terminal directly… But I assume that there are some interdependencies between CUDA, JCuda, JVM, OS, Graphics Card drivers and execution settings that are hard to grasp… for me, at least… -_- )
All I know is that LD_PRELOAD would cause subsequent function calls to use a specific implementation in a library file (eg. a library that has implemented malloc() and free() can be preloaded with LD_PRELOAD and any program that is called after LD_PRELOAD setting would use that specific implementation of malloc and free rather than the standard one provided by standard C)
JOGL throws the same exception mentioned in this thread:
Exception in thread „main“ javax.media.opengl.GLException: Profile GL3 is not available on null, but: [GLProfile[GL2ES2/GL2], GLProfile[GL2ES1/GL2], GLProfile[GL2/GL2], GLProfile[GL2/GL2], GLProfile[GL2GL3/GL2]]
I don’t exactly remember what exception was being thrown by LWJGL as I don’t have access to the machine I was running it on right now, but I can check later.
I did not try to run it without JAR (too many dependencies, I was lazy ) but again, I could try and run it and get back to you if it helps.
OK, and I think it’s not possible (or not easy) do deactivate the „wrong“ graphics card? I’ll try check whether it’s possible to select the device that should be used for JOGL, but of course, can only do some guesswork based on what I’ll find in the API. Maybe there are also some settings in dhe ‚Control Panel‘ of the Graphics Card driver or so…?
[QUOTE=SirM2X;19495]
I did not try to run it without JAR (too many dependencies, I was lazy ) but again, I could try and run it and get back to you if it helps.[/QUOTE]
Most likely it will not really help: If it works, we don’t know why, and if it does not work, we don’t know why, either I just was wondering what exactly might be the difference between both ways of launching it, because I thought that the way of launching a Java Application on the one hand and the Graphics Card that is used for this application on the other hand should be fairly unrelated, but again, it’s hard to see though all the possible interdependencies…
OK, and I think it’s not possible (or not easy) do deactivate the „wrong“ graphics card? I’ll try check whether it’s possible to select the device that should be used for JOGL, but of course, can only do some guesswork based on what I’ll find in the API. Maybe there are also some settings in dhe ‚Control Panel‘ of the Graphics Card driver or so…?
In Windows it is possible to deactivate the wrong (eg. Intel) graphics card. But in Linux there is currently no way…
Something to note is that when using the wrong graphics card in Windows, cuGLCtxCreate throws CUDA_ERROR_UNKNOWN exception! On Linux, only JOGL will throw error (the one I mentioned earlier).
This whole thing is making me really confused As long as I could just use some basic CUDA/OGL interoperability I could live with the confusion
OK, once this works in general, there will also be the next question: Whether the intention is to use buffer sharing between CUDA and OpenGL. Otherwise, the data may simply be transferred via the host. But this would be the next step, after the first example is up and running…
although I see that there is an increasing number of different devices, and I should probably try to better understand the concepts behind that.
) but again, I could try and run it and get back to you if it helps.