When I restart and login my system first time. Opencl support wouldn’t be enabled. As below shown.
#clinfo
Number of platforms 0
But if I use “sudo clinfo”, opencl support be enabled. And I don’t have to use sudo again to get the opencl support.
I think this is not a correct way to active opencl.
Is my setting wrong?[FONT=arial] Or is it a bug?
[/FONT]
#sudo clinfo
Number of platforms 1
Platform Name NVIDIA CUDA
Platform Vendor NVIDIA Corporation
Platform Version OpenCL 1.2 CUDA 10.2.109
Platform Profile FULL_PROFILE
Platform 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_fp64 cl_khr_byte_addressable_store cl_khr_icd cl_
khr_gl_sharing cl_nv_compiler_options cl_nv_device_attribute_query cl_nv_pragma_unroll cl_nv_copy_opts cl_khr_gl_event cl_
nv_create_buffer cl_khr_int64_base_atomics cl_kernel_attribute_nv
Platform Extensions function suffix NV
.......
It’s my understanding that clinfo is purely a utility that reports status information, it doesn’t activate opencl. Maybe I’m misunderstanding your post
Nonetheless, it works here, without using “sudo”, in fact it doesn’t need root privileges…
paul@Orion-17:~> clinfo
Number of platforms 1
Platform Name NVIDIA CUDA
Platform Vendor NVIDIA Corporation
Platform Version OpenCL 1.2 CUDA 10.2.109
Platform Profile FULL_PROFILE
Platform 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_fp64 cl_khr_byte_addressable_store cl_khr_icd cl_khr_gl_sharing cl_nv_compiler_options cl_nv_device_attribute_query cl_nv_pragma_unroll cl_nv_copy_opts cl_nv_create_buffer cl_khr_int64_base_atomics cl_khr_int64_extended_atomics
Platform Extensions function suffix NV
Platform Name NVIDIA CUDA
Number of devices 1
Device Name GeForce GT 710
Device Vendor NVIDIA Corporation
Device Vendor ID 0x10de
Device Version OpenCL 1.2 CUDA
Driver Version 440.44
Device OpenCL C Version OpenCL C 1.2
... snip
In the first instance (# clinfo) did you login to a graphical environment as root (and thus create a “root” user environment), or did you login as a user and then “su -” to root (when root’s environment does not have any graphical (Nvidia) components?
I remember seeing something similar a few years ago, IIRC it had something to do with the /dev/nvidia_uvm device ownership or permissions, so checking if there is something odd there might be useful.
Old notes recall this bug https://bugzilla.novell.com/show_bug.cgi?id=879767 but so much water has passed since that I don’t know if it might be still relevant.
Hi all, thanks for your reply.
I’m a rookie of Linux, if I reply too stupid, please don’t mind.
tannington,
I know “clinfo” is a utility, so I need to use “sudo clinfo” to active Opencl is so weird.
OrsoBruno,
I found this post before, but it didn’t work.
eng-int,
I login as a user and didn’t su- to root. Should I use “su-” to root before use “clinfo”?
When I use “clinfo” without “sudo” it will show “Number of platforms 0”.
malcolmlewis,
I use YaST to install the driver not hard way.
If Opencl works from the second invocation, there is no driver problem apparently at the moment (although k2100m support has been dropped from G05 drivers recently, as @malcolmlewis suggests).
I still think there is a permission problem somewhere, e.g. loading the nvidia_uvm module or creating the /dev/nvidia_uvm device; once the kernel module is loaded and the device has been setup, there are no further problems apparently.
Does adding the current user to the “video” group have any effect?
Can you post the result of the following commands just after login (Opencl not working) and after “sudo clinfo” has been issued? Does anything change?
lsmod | grep uvm
ls -l /dev/ | grep uvm
(Sorry, no opencl installed here at the moment, so cannot check it myself)
When you start YaST from the GUI, it will become a root process (and ask you for the root password), you may see that as being “logged in as root”.
And yes, zypper does not have a builtin switch to root, thus your must already run the CLI as root (expressed as “being logged in as root”).
I assume the remark was only made to remember that installing packages on the system level requires root owned processes and thus knowing root’s passdword, just as a general observation without any details on how to obtain that. Everybody has her/his own preferred way to “become root” in different situations.
And indeed, you should not log in as root directly, and certainly never in the GUI.
Maybe I have to explain that I have no idea about your problem, or even the subject you have the problem with. I did not even read all the posts above.
I only answered with general information about installing software packages **on the system level **(remember that you can always install/copy software as a “normal user” somewhere inside your home directory and use it as that user, but that is NOT available then for the system).
I repeat that I did not read all the posts above, so you may have posted that already, but in general, when you say "I’ve installed driver ", you should always post exactly how you did that. Vague information will not help people in understanding what you did as long as they can not look over your shoulder
YaST User and Group management.
Select the user of interest, click the “Edit” button.
Select the “Detail” tab; scroll down the “Additional Groups” menu on the right, tick the “video” box.
Click “OK”, logout, login again and see if anything changes.
