I have an installation of Kubuntu 13.10 on my laptop which has an Nvidia GT555m with optimus technology. I am having some trouble getting my C++ code with OpenCL to compile.
The error I keep getting is Cannot find -lOpenCL. Doing a quick search with the GNU find utility gives me the following:
/usr/lib32/nvidia-319/libOpenCL.so.1
/usr/lib32/nvidia-319/libOpenCL.so
/usr/lib32/nvidia-319/libOpenCL.so.1.0
/usr/lib32/nvidia-319/libOpenCL.so.1.0.0
/usr/lib/x86_64-linux-gnu/libOpenCL.so
/usr/lib/nvidia-319/libOpenCL.so.1
/usr/lib/nvidia-319/libOpenCL.so
/usr/lib/nvidia-319/libOpenCL.so.1.0
/usr/lib/nvidia-319/libOpenCL.so.1.0.0
I have the following OpenCL development packages installed:
opencl-headers
nvidia-opencl-dev
I also tried the utility clinfo to see if I get any information, but I get the following error:
clinfo: error while loading shared libraries: libOpenCL.so.1: cannot open shared object file: No such file or directory
Does anyone have any experience setting up a Linux development environment with OpenCL on their optimus laptops?
I was under the impression that I do not need to do anything fancy to get this working.
EDIT: Ok it seems the reason I was not managing to compile was because I was mixing up headers and libraries. Using the following compiles my code well:
g++ -std=c++11 -I /usr/local/cuda-5.5/include vadd.cpp -L /usr/lib/nvidia-331 -lOpenCL
I am getting another error during runtime now (but at least I managed to compile!). The error is as follows:
ERROR: clGetPlatformIDs
-1001
From doing some research this means I probably do not have the ICD portion of nvidias toolkit installed? What I cannot understand is - where to find it!
You should install the Nvidia Cuda SDK. It contains OpenCL development libraries and includes.
You don't need development packages or libraries, (OpenCL is already there, and working, just giving you a runtime error, ICD is present). What you need is a platform ready to execute the OpenCL code, so a GPU + a driver.
You need to install the propietary driver of nVIDIA: Either by using the Ubuntu tools, or by installing the package nvidia-current.
Maybe you have to install bublebee. A library to use Cuda on Nvidia cards with optimus technology.
I do not use Kubuntu yet I got it working under Mageia release 6 Linux so I guess it should be pretty similar. In my case there were Intel and Nvidia (GeForce GTX 980M) graphic cards together in my laptop. My intention was to get running only OpenCL compiled code without any set up of Xorg graphical server.
So, as advised above by DarkZeros I did it by using only a proprietary nvidia driver (in my case downloaded from Nvidia page). Then under root user:
./NVIDIA-Linux-x86_64-375.39.run --no-opengl-files
It asked me if I wanted to modify my Xorg configuration - I said "NO". This delivered nvidia kernel modules. Next, I modified /etc/modules to let the Linux know that it should load them at start up of system (this might be different on Kubuntu)
[root#localhost ~]# cat /etc/modules
nvidia
nvidia-uvm
nvidia-drm
nvidia-modeset
and that was really it. Reboot your system and loading of modules should automatically also create correct nvidia device files under a /dev directory.
[root#localhost ~]# ls /dev/nvidia*
/dev/nvidia0 /dev/nvidiactl /dev/nvidia-uvm /dev/nvidia-uvm-tools
I've got an inspiration from [ftp://download.nvidia.com/XFree86/Linux-x86/295.59/README/optimus.html][1]
Related
I have configured Installable Client Drivers (ICDs) on an Ubuntu-distribution with Intel OpenCL runtime drivers, which was fairly straightforward. These drivers come as *.so-files which can be loaded by specifying their path in an *.icd-file under /etc/OpenCL/vendors/.
How would I proceed to specify Nvidia OpenCL-drivers on Windows, and where are these drivers located?
I use MINGW64 with and OpenCL-ICD-Loader installed via MSYS2
Where is the corresponding directory to add the *.icd-files?
On Windows with MinGW-w64 I use a combination of:
https://github.com/KhronosGroup/OpenCL-Headers
https://github.com/KhronosGroup/OpenCL-ICD-Loader
OpenCL-ICD-Loader figures out where to load the Nvidia stuff from.
To build from source I had to tweak some stuff, see my build recipes:
https://github.com/brechtsanders/winlibs_recipes/blob/main/recipes/khronos-opencl-headers.winlib
https://github.com/brechtsanders/winlibs_recipes/blob/main/recipes/khronos-opencl-icd-loader.winlib
I have a unix binary file built with QT and OpenGL which I'm trying to execute on linux-64. It is a simple visual program that shows 2d and 3d graphics.
I have installed all necessary dependencies such as QT and openGL libraries.
However, I have stuck with the following error trying to execute the binary
QXcbIntegration: Cannot create platform OpenGL context, neither GLX
nor EGL are enabled
However, the binary eventually runs but with some missing features such as 3D graphics.
my setup includes: virtual linux-64 using virtualBox, Vagrant, x-11 forwarding, and a Mac machine.
Eventually I realised that OpenGL 3.3 wouldn't work easily on virtual machines .. yet. I had to boot from ubuntu usb and work from there by installing latest mesa 3d package.
This shows a similar issue and the developer in the comment said our 3D support is not very clean in Linux guests, hence the warnings. You can give a try to VMware.
After some time trying to get some opengl working on a particular locked down linux box, I ended up going back to Qt Creator 2.5.2 .
http://download.qt.io/archive/qtcreator/2.5/
http://download.qt.io/archive/qtcreator/2.5/qt-creator-linux-x86_64-opensource-2.5.2.bin
After getting it on the linux box...
chmod u+x *.bin
./qt-creator-linux-x86_64-opensource-2.5.2.bin
And after a short installer, Qt Creator is working!
Basically QtQuick is a requirement in any Qt Creator built after 2.5 (aka Qt 5.x) and QtQuick NEEDS opengl libraries and support.
Hope that helps.
I see this problem when executing Qt App, I was executing in dash prompt. (Ubuntu 16.04 has dash by default). I changed to bash prompt and rebuilt my QT App. This error is gone.
To configure bash I used below command.
sudo dpkg-reconfigure dash
I am trying to write some openFrameworks (C++) code in a VM. My host is Windows 8 and I've tried both Arch Linux and Ubuntu guests. My host computer runs the graphics code just fine with an NVidia Optimus setup and 8GB of RAM.
I do my main development in Visual Studio, however I do prefer to create Android and test packages from Linux. For this reason I just want to fire up a VM and take care of business. The problem is that some of my graphics apps need OpenGL 3+
Has anybody else had the same problem and solved it?
Give up on VirtualBox. VB's OpenGL guest support craps out at 2.1, even then only after you install VB Guest Additions from the command line with switches and then add some Registry keys to actually enable the OpenGL guest drivers.
If you're willing to shell out money, VMware Fusion for Mac and VMware Workstation for Windows both support DirectX 10 and OpenGL 3.3.
A bit late to the party here, but hopefully helpful for someone encountering similar issues these days:
The mesa software renderer now supports OpenGL 4.5, so for me, the solution is to disable 3D acceleration in the settings of the VirtualBox machine!
The mesa software OpenGL support then takes over and provides its capabilities. It's for sure not that fast, but for my purpose (testing whether an OpenGL application starts and displays something under linux) it's sufficient!
Tested both on Fedora 34 and Ubuntu 20.04.
Try VirtualBox and prepend MESA_GL_VERSION_OVERRIDE=3.0 MESA_GLSL_VERSION_OVERRIDE=130 to your linux command line. Some of the opengl3 functions may work. Though not all of them will. I used that to bring up Civ5, the animation did not show up, nor did the on-screen fonts.
If you want to see the source code:
VirtualBox uses chromium 1.9 that is opengl 2.1. The info can be verified by the glxinfo command. Use the following commands to track the VirtualBox opengl lib file:
$ ldd /usr/bin/glxinfo
$ apt-file search /usr/lib/x86_64-linux-gnu/libGL.so.1.2
$ LIBGL_DEBUG=verbose glxinfo
Then follow links:
$ ls -l x86_64-linux-gnu/dri/
lrwxrwxrwx Apr 14 2014 vboxvideo_dri.so -> ../../VBoxOGL.so
$ apt-file search /usr/lib/VBoxOGL.so
virtualbox-dbg: /usr/lib/debug/usr/lib/VBoxOGL.so
virtualbox-guest-x11: /usr/lib/VBoxOGL.so
$ dpkg -l virtualbox*
ii virtualbox-guest-x11 4.1.18-dfsg-2+deb7 amd64
$ apt-file list virtualbox-guest-x11
...
The source code tarball was virtualbox-4.3.10-dfsg.orig.tar.gz from trusty repo. The version string can be grep'ed by $ grep -r CR_OPENGL_VERSION_STRING * and $ grep -r CR_VERSION_STRING * in the source code directory.
Update 6/1/2017: Someone told me the kvm works for civ5. A quick search turned up this thread titled "GPU Passthrough with KVM: Have Your Cake and Eat it Too". The thread is too long to read, though hope it could be useful to somebody.
I'm porting my application from Qt4 to Qt5. I installed Qt5.2.1 from the online installer on Linux Mint 16 64-bit, in a vm on my MacBook Pro. When I run qmake and build in Qt Creator, I get:
/usr/bin/ld: cannot find -lGL
Do I need openGL? I'm not using it when I build on Windows or OSX. I'm very new to Linux, and far from expert in C++ or Qt. I found a post that included a hack to remove -lGL from mkspecs/common/linux.conf. That worked.
My question is, assuming I don't need -lGL, what is the normal way to keep the linker from attempting to link it? I imagine I do something in the .pro file, but what?
Qt5 makes heavy use of OpenGL internally. On Windows OpenGL support is a bit flaky (you must install the original vendor drivers, because Microsoft strips OpenGL from the automatically installed drivers) and hence makes use of a built in OpenGL emulation layer library.
On Linux however OpenGL support is much better. You'll find at least the Mesa softpipe backend, if the GPU is not supported by the standard drivers. If the GPU is supported, then out-of-the-box OpenGL support in Linux has become pretty good over the past years.
On MacOS X OpenGL is actually the foundation of all the higher level graphics operations and hence part of the inner workings of the operating system; sounds great in theory, but is also a major obstacle for quick version turnaround, as every major OpenGL version bump mandates an operating system update.
Now, unless your installation of Linux is seriously outdated you actually should have a OpenGL library installed. If not (and your linker error tells you this), just install the Mesa development package.
Linux Mint is a derivative of Ubuntu which in turn is a Debian derivative. The command to install the Mesa development package for OpenGL is
sudo apt-get install libgl1-mesa-dev
Question: why can't it find -lGL?
Info: I wrote a program as guided by this site on my netbook this morning and it compiled and ran with no problem. I then proceeded to take the exact same code and try to run it on my desktop. the version my netbook compiled worked, but it yelled at me because my netbook doesn't have a graphics card and my desktop does so it wasn't quite compiled right. still ran though.
But when I tried to compile it on my desktop it failed. at first it was saying "Fatal error: GL/gl.h: no such file or directory" so i thought "wait, i thought opengl came with ubuntu, I mean my netbook worked, maybe I installed something and forgot about it" so i ran through apt and pulled down everything opengl I felt might help. but staring at 212 - 1278 packages (depending on what words i search with) that may or may not be opengl related, I don't know what else to try. I got past the first problem, but now it is complaining that it can't find -lGL, which seems really odd.
any tips, tricks, comments, quips? My end objective is to be able to compile c code from the command line, I've been using the command that I got from the afore mentioned site:
gcc -o gltest gltest.c -lX11 -lGL -lGLU
I run Ubuntu 11.04 desktop, 64-bit. Nvidia GTX465.
try to install the following packages:
apt-get install libgl1-mesa-dev libglu1-mesa-dev libglut3-dev
Your compiler was looking for a lib called libGL.so in /usr/lib, which was a symbolic link to /usr/lib/mesa/libGL.so, Mesa's libGL. You also have the libGL from your nVidia drivers (which are probably in 275.28 version, see the libGL name : libGL.so.275.28). Modifying the symlink to point to nVidia's one gives your compiler no longer the Mesa's one, but the nVidia's one.