First, I have to say that although I think I'm a fairly knowledgeable home pc user, I'm not in any way a programmer so I'm afraid I can't contribute to your C language idea.
I'm sure I followed the git procedure exactly as you described in your earlier post, but to be sure I just went through it again, with the same result.
Everything in /user/local/lib/clc seems to be correct, and here is the result of running ls -ltu in that folder...
It seems the files in '/usr/local/lib/clc' are being used (these are the ones you compiled yourself), but the files in '/usr/lib/clc' do also have recent access dates. (These are the ones from the system package.) So this didn't help much.
I hope I have time to come back with a better idea soon.
​Supported APIs:
​OpenGL 4.5 and GLX 1.4
OpenCL 1.2
Vulkan 1.0
VDPAU
DOTA 2 Game support (Vulkanâ„¢ enabled)
​​Basic display features
Basic power management features
KMS (Kernel Mode Setting) and ADF (Atomic Display Framework) support
GPL compliant kernel module
Install script and Debian packages for Ubuntu 16.04
Note
Quote:
OpenCL features are not fully validated
and only GCN 1.2 compatibility. Fury, 380X, Nano etc.
To Aaron Puchet: What you say in 157944 is correct, but I didn't realise that until after I'd posted about it. Actually, there's a second pair of folders, /usr/local/include/clc/ & /usr/include/clc where the libclc-dev files are found.
Now, I've been giving all this a break for a few days so as to test out what seems to be a (temporary?) working solution. It's a bit of a story, so I'd just like to recap a little.
At the start, Synaptic only showed the system packages that OpenCL had been using at startup, but not the new ones created by your 'git clone' procedure, which explains why that procedure had not made any difference. Clearly those files needed to be made into packages to show up in Synaptic.
To achieve this my next step used 'sudo checkinstall' instead of 'sudo make install', hoping to create deb packages that I could install. I was only able to do this with libclc-amdgcn since the other two only produced conflicts. But I did create libclc-amdgcn_20160525-1_amd64.deb successfully. I reasoned that missing the other two packages didn't matter since all the needed folders and files were in this new deb package. I then use Gdebi to install the new libclc-amdgcn package.
Back to Synaptic, and sure enough it now showed the two package versions so it seemed like a simple 'Force version...' to bring my new libclc-amdgcn into play. Not so.
Perversely, clinfo now showed errors, that OpenCL was still looking for the system packages and not 'seeing' my new package. Getting around this is where the kludge came in.
First, I went to the two system packages folders, /usr/lib & /usr/include, and renamed the two clc folders there to get them out of the way. Next, I copied the two new clc folders from the */local/* folders into the system package folders. Now, I honestly don't know how this last trick could possibly work, but it seems to have done since I'm now receiving and processing amd/ati gpu WU's from einstein@home.
I did say it's a bit of a story!
Naturally, I have no idea whether this might help any other users experiencing the same problem, or not. Is the above a temporary working solution, or just a lucky fluke?
I'll be happy to read any comments.
To AgentB: I've had a look at your link. Since this is from AMD I suppose it refers to their own fglrx based packages, which are deprecated in Ubuntu 16.04. However, it does at least show that people are starting to look seriously at AMD and OpenCL compatibility.
As an afterthought to my post 158100 I decided that the copy/paste trick wasn't a good idea, so I've created two symlinks to the new clc folders in /usr/local/*. This works just as well, and is probably better.
To AgentB: I've had a look at your link. Since this is from AMD I suppose it refers to their own fglrx based packages, which are deprecated in Ubuntu 16.04. However, it does at least show that people are starting to look seriously at AMD and OpenCL compatibility.
That link is an update of the the original link posted.
It refers to amdgpu-pro (aka Vulkan) driver release.
amdgpu-pro replaces fgrlx
amdgpu-pro runs on 16.04 Ubuntu
amdgpu-pro supports only GCN 1.2 Volcanic island cards (currently)
This link refers to the new beta release of amdgpu-pro which is 16.20.3-294842
The original post referred to the first(?) beta release amdgpu-pro which was 16.15.2-277429
Edit: I see you have managed to get a few tasks validated, so that is very good news.
Nice, it seems to work now. A couple of tasks have been validated already. I'm glad to see you could fix it.
I had already suspected a problem like that. By the FHS (Filesystem hierarchy standard), the /usr/ tree contains basically most system packages (except for a few in the root tree), while /usr/local/ contains locally-made stuff, like when you compiled something on your own. Normally, /usr/local/ should have precedence over /usr/, but sometimes distros don't look there in the first place. Sometimes you have to convince them by setting LD_LIBRARY_PATH. I hoped the access times would give us some insight here, which they didn't. But apparently you did the right thing anyway. (Seemingly contradictory to what I said, it's completely legitimate to install user-compiled packages to /usr/ instead of /usr/local/. But beware when there are updates coming, they might overwrite your hand-crafted package.)
Note that I'm not using Ubuntu myself, but we Linux users mostly have the same problems. I'm happy for every user switching to the open source drivers, because that is giving them more weight in the developer community. Which is good for all of us in the end.
Sometimes you have to convince them by setting LD_LIBRARY_PATH.
Is this something that might be fixed with ldconfig and ld.so.conf?
Quote:
But beware when there are updates coming, they might overwrite your hand-crafted package.)
Almost certainly. Hopefully the updates, when they arrive will work better.
Quote:
I'm happy for every user switching to the open source drivers, because that is giving them more weight in the developer community. Which is good for all of us in the end.
Not many users are skilled or patient to work through this, and vendors will try to preserve the status quo. Hopefully the distros will pick up these issues quickly.
First, I have to say that
)
First, I have to say that although I think I'm a fairly knowledgeable home pc user, I'm not in any way a programmer so I'm afraid I can't contribute to your C language idea.
I'm sure I followed the git procedure exactly as you described in your earlier post, but to be sure I just went through it again, with the same result.
Everything in /user/local/lib/clc seems to be correct, and here is the result of running ls -ltu in that folder...
total 22868
lrwxrwxrwx 1 root root 16 May 24 11:19 aruba-r600--.bc -> cayman-r600--.bc
lrwxrwxrwx 1 root root 18 May 24 11:19 bonaire-amdgcn--.bc -> tahiti-amdgcn--.bc
lrwxrwxrwx 1 root root 15 May 24 11:19 caicos-r600--.bc -> barts-r600--.bc
lrwxrwxrwx 1 root root 18 May 24 11:19 carrizo-amdgcn--.bc -> tahiti-amdgcn--.bc
lrwxrwxrwx 1 root root 18 May 24 11:19 fiji-amdgcn--.bc -> tahiti-amdgcn--.bc
lrwxrwxrwx 1 root root 18 May 24 11:19 hainan-amdgcn--.bc -> tahiti-amdgcn--.bc
lrwxrwxrwx 1 root root 18 May 24 11:19 hawaii-amdgcn--.bc -> tahiti-amdgcn--.bc
lrwxrwxrwx 1 root root 17 May 24 11:19 hemlock-r600--.bc -> cypress-r600--.bc
lrwxrwxrwx 1 root root 18 May 24 11:19 iceland-amdgcn--.bc -> tahiti-amdgcn--.bc
lrwxrwxrwx 1 root root 15 May 24 11:19 juniper-r600--.bc -> cedar-r600--.bc
lrwxrwxrwx 1 root root 18 May 24 11:19 kabini-amdgcn--.bc -> tahiti-amdgcn--.bc
lrwxrwxrwx 1 root root 18 May 24 11:19 kaveri-amdgcn--.bc -> tahiti-amdgcn--.bc
lrwxrwxrwx 1 root root 18 May 24 11:19 mullins-amdgcn--.bc -> tahiti-amdgcn--.bc
lrwxrwxrwx 1 root root 18 May 24 11:19 oland-amdgcn--.bc -> tahiti-amdgcn--.bc
lrwxrwxrwx 1 root root 15 May 24 11:19 palm-r600--.bc -> cedar-r600--.bc
lrwxrwxrwx 1 root root 18 May 24 11:19 pitcairn-amdgcn--.bc -> tahiti-amdgcn--.bc
lrwxrwxrwx 1 root root 15 May 24 11:19 redwood-r600--.bc -> cedar-r600--.bc
lrwxrwxrwx 1 root root 18 May 24 11:19 stoney-amdgcn--.bc -> tahiti-amdgcn--.bc
lrwxrwxrwx 1 root root 15 May 24 11:19 sumo2-r600--.bc -> cedar-r600--.bc
lrwxrwxrwx 1 root root 15 May 24 11:19 sumo-r600--.bc -> cedar-r600--.bc
lrwxrwxrwx 1 root root 18 May 24 11:19 tonga-amdgcn--.bc -> tahiti-amdgcn--.bc
lrwxrwxrwx 1 root root 15 May 24 11:19 turks-r600--.bc -> barts-r600--.bc
lrwxrwxrwx 1 root root 18 May 24 11:19 verde-amdgcn--.bc -> tahiti-amdgcn--.bc
-rw-r--r-- 1 root root 3847152 May 24 09:29 tahiti-amdgcn--.bc
-rw-r--r-- 1 root root 3853232 May 24 09:29 cayman-r600--.bc
-rw-r--r-- 1 root root 2254060 May 24 09:29 barts-r600--.bc
-rw-r--r-- 1 root root 3853244 May 24 09:29 cypress-r600--.bc
-rw-r--r-- 1 root root 2254060 May 24 09:29 cedar-r600--.bc
-rw-r--r-- 1 root root 3676824 May 24 09:29 nvptx64--nvidiacl.bc
-rw-r--r-- 1 root root 3654600 May 24 09:29 nvptx--nvidiacl.bc
-rw-r--r-- 1 root root 668 May 24 09:29 subnormal_use_default.bc
-rw-r--r-- 1 root root 668 May 24 09:29 subnormal_disable.bc
...Maybe a clue there!
I now notice that there is
)
I now notice that there is also a folder /usr/lib/clc, where ls -ltu gives...
total 67404
-rw-r--r-- 1 root root 23022304 May 24 12:05 barts-r600--.bc
-rw-r--r-- 1 root root 23022312 May 24 12:05 cayman-r600--.bc
-rw-r--r-- 1 root root 22971936 May 24 07:41 tahiti-amdgcn--.bc
lrwxrwxrwx 1 root root 16 May 23 18:50 aruba-r600--.bc -> cayman-r600--.bc
lrwxrwxrwx 1 root root 18 May 23 18:50 bonaire-amdgcn--.bc -> tahiti-amdgcn--.bc
lrwxrwxrwx 1 root root 15 May 23 18:50 caicos-r600--.bc -> barts-r600--.bc
lrwxrwxrwx 1 root root 15 May 23 18:50 cedar-r600--.bc -> barts-r600--.bc
lrwxrwxrwx 1 root root 16 May 23 18:50 cypress-r600--.bc -> cayman-r600--.bc
lrwxrwxrwx 1 root root 18 May 23 18:50 hainan-amdgcn--.bc -> tahiti-amdgcn--.bc
lrwxrwxrwx 1 root root 18 May 23 18:50 hawaii-amdgcn--.bc -> tahiti-amdgcn--.bc
lrwxrwxrwx 1 root root 17 May 23 18:50 hemlock-r600--.bc -> cypress-r600--.bc
lrwxrwxrwx 1 root root 15 May 23 18:50 juniper-r600--.bc -> cedar-r600--.bc
lrwxrwxrwx 1 root root 18 May 23 18:50 kabini-amdgcn--.bc -> tahiti-amdgcn--.bc
lrwxrwxrwx 1 root root 18 May 23 18:50 kaveri-amdgcn--.bc -> tahiti-amdgcn--.bc
lrwxrwxrwx 1 root root 18 May 23 18:50 mullins-amdgcn--.bc -> tahiti-amdgcn--.bc
lrwxrwxrwx 1 root root 18 May 23 18:50 oland-amdgcn--.bc -> tahiti-amdgcn--.bc
lrwxrwxrwx 1 root root 15 May 23 18:50 palm-r600--.bc -> cedar-r600--.bc
lrwxrwxrwx 1 root root 18 May 23 18:50 pitcairn-amdgcn--.bc -> tahiti-amdgcn--.bc
lrwxrwxrwx 1 root root 15 May 23 18:50 redwood-r600--.bc -> cedar-r600--.bc
lrwxrwxrwx 1 root root 15 May 23 18:50 sumo2-r600--.bc -> cedar-r600--.bc
lrwxrwxrwx 1 root root 15 May 23 18:50 sumo-r600--.bc -> cedar-r600--.bc
lrwxrwxrwx 1 root root 15 May 23 18:50 turks-r600--.bc -> barts-r600--.bc
lrwxrwxrwx 1 root root 18 May 23 18:50 verde-amdgcn--.bc -> tahiti-amdgcn--.bc
...These are older files, from Oct last year.
It seems the files in
)
It seems the files in '/usr/local/lib/clc' are being used (these are the ones you compiled yourself), but the files in '/usr/lib/clc' do also have recent access dates. (These are the ones from the system package.) So this didn't help much.
I hope I have time to come back with a better idea soon.
Some progress from
)
Some progress from AMD
AMDGPU Release Beta for Ubuntu 16.04 supports OpenCL a day or so ago
Note
and only GCN 1.2 compatibility. Fury, 380X, Nano etc.
Still interesting...
To Aaron Puchet: What you say
)
To Aaron Puchet: What you say in 157944 is correct, but I didn't realise that until after I'd posted about it. Actually, there's a second pair of folders, /usr/local/include/clc/ & /usr/include/clc where the libclc-dev files are found.
Now, I've been giving all this a break for a few days so as to test out what seems to be a (temporary?) working solution. It's a bit of a story, so I'd just like to recap a little.
At the start, Synaptic only showed the system packages that OpenCL had been using at startup, but not the new ones created by your 'git clone' procedure, which explains why that procedure had not made any difference. Clearly those files needed to be made into packages to show up in Synaptic.
To achieve this my next step used 'sudo checkinstall' instead of 'sudo make install', hoping to create deb packages that I could install. I was only able to do this with libclc-amdgcn since the other two only produced conflicts. But I did create libclc-amdgcn_20160525-1_amd64.deb successfully. I reasoned that missing the other two packages didn't matter since all the needed folders and files were in this new deb package. I then use Gdebi to install the new libclc-amdgcn package.
Back to Synaptic, and sure enough it now showed the two package versions so it seemed like a simple 'Force version...' to bring my new libclc-amdgcn into play. Not so.
Perversely, clinfo now showed errors, that OpenCL was still looking for the system packages and not 'seeing' my new package. Getting around this is where the kludge came in.
First, I went to the two system packages folders, /usr/lib & /usr/include, and renamed the two clc folders there to get them out of the way. Next, I copied the two new clc folders from the */local/* folders into the system package folders. Now, I honestly don't know how this last trick could possibly work, but it seems to have done since I'm now receiving and processing amd/ati gpu WU's from einstein@home.
I did say it's a bit of a story!
Naturally, I have no idea whether this might help any other users experiencing the same problem, or not. Is the above a temporary working solution, or just a lucky fluke?
I'll be happy to read any comments.
To AgentB: I've had a look at
)
To AgentB: I've had a look at your link. Since this is from AMD I suppose it refers to their own fglrx based packages, which are deprecated in Ubuntu 16.04. However, it does at least show that people are starting to look seriously at AMD and OpenCL compatibility.
As an afterthought to my post
)
As an afterthought to my post 158100 I decided that the copy/paste trick wasn't a good idea, so I've created two symlinks to the new clc folders in /usr/local/*. This works just as well, and is probably better.
RE: To AgentB: I've had a
)
That link is an update of the the original link posted.
It refers to amdgpu-pro (aka Vulkan) driver release.
amdgpu-pro replaces fgrlx
amdgpu-pro runs on 16.04 Ubuntu
amdgpu-pro supports only GCN 1.2 Volcanic island cards (currently)
This link refers to the new beta release of amdgpu-pro which is 16.20.3-294842
The original post referred to the first(?) beta release amdgpu-pro which was 16.15.2-277429
Edit: I see you have managed to get a few tasks validated, so that is very good news.
Looking at this task https://einsteinathome.org/task/560485815 for example
Each task is starting with some erros, which don't seem to cause a problem.
I don't know if this is a common problem.
How do these times compare with other versions / OS etc?
Nice, it seems to work now. A
)
Nice, it seems to work now. A couple of tasks have been validated already. I'm glad to see you could fix it.
I had already suspected a problem like that. By the FHS (Filesystem hierarchy standard), the /usr/ tree contains basically most system packages (except for a few in the root tree), while /usr/local/ contains locally-made stuff, like when you compiled something on your own. Normally, /usr/local/ should have precedence over /usr/, but sometimes distros don't look there in the first place. Sometimes you have to convince them by setting LD_LIBRARY_PATH. I hoped the access times would give us some insight here, which they didn't. But apparently you did the right thing anyway. (Seemingly contradictory to what I said, it's completely legitimate to install user-compiled packages to /usr/ instead of /usr/local/. But beware when there are updates coming, they might overwrite your hand-crafted package.)
Note that I'm not using Ubuntu myself, but we Linux users mostly have the same problems. I'm happy for every user switching to the open source drivers, because that is giving them more weight in the developer community. Which is good for all of us in the end.
RE: Nice, it seems to work
)
Aaron i noticed your host has exactly the same problem in the first few lines
https://einsteinathome.org/task/559489119
So at least consistent.
Is this something that might be fixed with ldconfig and ld.so.conf?
Almost certainly. Hopefully the updates, when they arrive will work better.
Not many users are skilled or patient to work through this, and vendors will try to preserve the status quo. Hopefully the distros will pick up these issues quickly.