Don't know about this. I don't see it in every task, and it seems not to be fatal. The error message is also not really saying what is wrong.
Quote:
Quote:
Sometimes you have to convince them by setting LD_LIBRARY_PATH.
Is this something that might be fixed with ldconfig and ld.so.conf?
That could work, try it out. On openSUSE I had no problem, but Ubuntu might behave differently there. This is something where every distro has their own way.
Quote:
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.
That I hope too.
I was trying to say that once a certain critical mass of people uses the open source drivers, developers can't just ignore them. But if only a handful of people use these drivers, developers won't care. Many users mean that releases would likely also get tested with the open source drivers, and we're unlikely to catch regressions. This is a chicken-and-egg problem, and we're trying to lay a few eggs here. ;)
I got my AMD APU A10-7850K to work with Einstein ATI GPU applications on Ubunt 16.04 64 bit.
This is what I did:
First, download the AMDGPU-Pro Driver and install. You find the driver at
interesting that the AMDGPU-Pro Driver works on ur APU, as it shouldnt according to AMD...i've got a r7-250 and a r9-270..maybe i should give it a shot installing the amdgpu-Pro driver then. How's the performance compared to Windows or old fglrx ?
thx in advance
The amdgpupro driver now does support Kaveri. - see previous posts in this thread. AMD are progressing at sub-glacial speed to to get older cards on the new driver. Looking what has been written it will be middle of next year earliest for GCN 1.0 cards.
How does it compare - is a good question, there are some links in this thread to Phoronix - i do not have a AMD hardware which runs both fglrx and amdgpupro, so can't say personally. Try it and report back.
Released this week adds CentOS, and looks like stating support for Cape Verde & Pitcairn / still not Tahiti yet. (I think 16.50 may have supported them as well)
I tried to update from 16.50 to 16.60 but gave up after several attempts. Couldn't get OpenCL/GL to show up. Linux Mint 18 + kernel 4.4.0-59 + R9 390. inxi -Fx said there was no Open GLX renderer, glxrenderer | grep OpenGL said the same and Boinc said GPU missing. I did everything the same way as installing 16.50. That one works again but 16.60 didn't. Conclusion: I don't have required skills.
I updated kernel to 4.8.0-34 and v16.60 installed then fine. FGRPB1Gv1.18 Beta tasks seem to be running fine. I tried also kernel 4.9.8 but v16.60 installation refused to proceed to end with that.
I had a couple of RX 460s arrive recently so I thought I'd see if I could get them crunching using my distro of choice - PCLinuxOS. I keep a local copy of the PCLOS repo and a quick check showed that the FOSS driver amdgpu was there but nothing for the proprietary driver. I decided to do a fresh install of the latest available live USB (Jan 2017) on a retired machine (Q6600 CPU) just to see if I could work out how to crunch on an RX 460. All my machines have three disk partitions, root, swap and /home. Reinstalling the OS doesn't touch any of the user files or configuration so is quite quick and relatively painless. After installation, I added the FOSS driver from the repo, as it wasn't on the live USB. After configuring the machine to use the amdgpu driver, a reboot encountered no problems.
PCLinuxOS packages are in rpm format so I decided to download the Red Hat version of AMDGPU-PRO 16.60 with a view to seeing how the OpenCL stuff was packaged. The first pleasant surprise was the new --compute option in the install script which kindly identified what sub-set of packages was needed just for OpenCL computing. So I extracted the packages in question and moved the contents to /opt/amdgpu-pro/. There were three sub-dirs - bin/ (clinfo), lib64/ (shared libs) and share/ (some docs). There were two other bits in directories lib/ and etc/ for installation elsewhere - /lib/udev/rules.d/91-drm_pro-modeset.rules and /etc/OpenCL/vendors/amdocl64.icd.
After moving all this stuff into place, I ran ldd on clinfo to see what libs that app would be needing. The only one not found was libamdocl64.so. A check on the contents of /opt/amdocl-pro/lib64 showed it was there so I realised I just needed to add /opt/amdocl-pro/lib64 to $LD_LIBRARY_PATH. I was then quite excited to see clinfo run without error and produce a whole bunch of output :-).
So now onto BOINC. When the client starts, at least for V7.2.42 which I'm using, GPU detection depends on the client finding the OpenCL libs as /usr/lib64/libOpenCL.so. With the old fglrx driver, PCLOS installs everything under /usr/lib/fglrx-current/. I've always needed to add a symbolic link in /usr/lib64 pointing to fglrx-current/libOpenCL.so. I presumed I would need to do a similar thing for the new OpenCL stuff in /opt/amdgpu-pro/lib64. The contents of the .icd file that I'd installed in /etc above pointed to the OpenCL lib being libamdocl64.so so I just created the link libOpenCL.so -> libamdocl64.so.
I have a small shell script that launches BOINC. It checks a couple of things and launches the client as a daemon. So I modified the script on the test machine to prefix the command to launch the client with LD_LIBRARY_PATH=/opt/amdgpu-pro/lib64. This machine had never been restarted after a storm last December had taken out the entire fleet. I had progressively brought most hosts with GPUs back to crunching but had retired most of rest - including 6 similar Q6600 CPU machines. I knew there would be expired CPU tasks to clean up but otherwise the BOINC installation should all be there ready to go.
So I just inserted the new GPU in the PCI-e slot and used the supplied 6-pin <-> molex power cable to get GPU power from the existing 300W PSU (270W available at 12V). I knew from previous experience that these PSUs will run a HD7850 in a similar setup so the new card should use less and so should be fine. I'll get around to doing some proper power measurements at some point :-).
When I was running the live USB to reinstall PCLOS in the root partition, I mounted /home temporarily and added all the apps and other files needed (eg. app_config.xml for x2 GPU crunching) to the existing BOINC stuff. I also edited client_state.xml to add the tag <dont_request_more_work/> so that BOINC wouldn't try to fetch anything when first launched.
BOINC launched just fine with warnings about the 'long overdue' tasks. I was very pleased to see the following in the event log
... Data directory: /home/gary/BOINC
... OpenCL: AMD/ATI GPU 0: Baffin (driver version 2264.10, device version OpenCL 1.2 AMD-APP
(2264.10), 2001MB, 2001MB available, 1366 GFLOPS peak)
... OpenCL CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (OpenCL driver vendor:
Advanced Micro Devices, Inc., driver version 2264.10 (sse2), device version OpenCL 1.2
AMD-APP (2264.10))
After aborting the expired CPU tasks, I allowed new work and watched as BOINC downloaded both CPU and GPU tasks. It was very nice to see GPU crunching take off. I only had one GPU task initially and it took a few retries to get some more so I had the opportunity to get a feel for a single task crunch time - probably would have ended around 24 mins. It has been crunching for the best part of 2 days now with no errors or invalids. A look at the list of validated tasks shows close to 100 so far, with each pair finishing in about 36-37 mins, so a nice improvement over the single task crunch time. Based on the results so far, the theoretical RAC should be around 270K - not too shabby for a $US100 upgrade to a previously retired host :-).
RE: Aaron i noticed your
)
Don't know about this. I don't see it in every task, and it seems not to be fatal. The error message is also not really saying what is wrong.
That could work, try it out. On openSUSE I had no problem, but Ubuntu might behave differently there. This is something where every distro has their own way.
That I hope too.
I was trying to say that once a certain critical mass of people uses the open source drivers, developers can't just ignore them. But if only a handful of people use these drivers, developers won't care. Many users mean that releases would likely also get tested with the open source drivers, and we're unlikely to catch regressions. This is a chicken-and-egg problem, and we're trying to lay a few eggs here. ;)
AgentB wrote:amdgpu-pro
)
AMD have released a new beta AMDGPU 16.30.3-315407, now supports Hawaii.
See Release-Notes
A couple of things i have
)
A couple of things i have noticed about the new drivers
AMDGPU-Pro Driver Version 16.30 supports Ubuntu 14.04.4
and Linux 4.9-rc1 has been released, and that will be needed for GCN 1.0 cards see Phoronix
edit: New drivers releaseda
)
New drivers released a few days ago.
AMDGPU-Pro Driver Version 16.40 supports Ubuntu and Red Hat
AMDGPU-Pro Driver Version 16.40 for RHEL 7.2 AMDGPU-Pro Driver Version 16.40 for RHEL 6.8
A work around the problem of Xorg.0.log filling up with many errors (about 500K / day)
(WW) AMDGPU(0): amdgpu_dri2_flip_event_handler: Pageflip completion event has impossible msc 1163 < target_msc 1164is now found here
SSD is now happy...
Happyl (from the mesa thread)
)
The amdgpupro driver now does support Kaveri. - see previous posts in this thread. AMD are progressing at sub-glacial speed to to get older cards on the new driver. Looking what has been written it will be middle of next year earliest for GCN 1.0 cards.
How does it compare - is a good question, there are some links in this thread to Phoronix - i do not have a AMD hardware which runs both fglrx and amdgpupro, so can't say personally. Try it and report back.
AMDGPU-PRO-Driver-for-Linux-R
)
AMDGPU-PRO-Driver-for-Linux-Release 16.60
Released this week adds CentOS, and looks like stating support for Cape Verde & Pitcairn / still not Tahiti yet. (I think 16.50 may have supported them as well)
Some comments here on Phoronix
AgentB
)
I tried to update from 16.50 to 16.60 but gave up after several attempts. Couldn't get OpenCL/GL to show up. Linux Mint 18 + kernel 4.4.0-59 + R9 390. inxi -Fx said there was no Open GLX renderer, glxrenderer | grep OpenGL said the same and Boinc said GPU missing. I did everything the same way as installing 16.50. That one works again but 16.60 didn't. Conclusion: I don't have required skills.
Richie_9 wrote:I tried to
)
Looks like you're not the only one.. good luck.
see https://forums.linuxmint.com/viewtopic.php?t=229229&start=40
AgentB wrote:Richie_9 wrote:I
)
I updated kernel to 4.8.0-34 and v16.60 installed then fine. FGRPB1G v1.18 Beta tasks seem to be running fine. I tried also kernel 4.9.8 but v16.60 installation refused to proceed to end with that.
AgentB
)
I had a couple of RX 460s arrive recently so I thought I'd see if I could get them crunching using my distro of choice - PCLinuxOS. I keep a local copy of the PCLOS repo and a quick check showed that the FOSS driver amdgpu was there but nothing for the proprietary driver. I decided to do a fresh install of the latest available live USB (Jan 2017) on a retired machine (Q6600 CPU) just to see if I could work out how to crunch on an RX 460. All my machines have three disk partitions, root, swap and /home. Reinstalling the OS doesn't touch any of the user files or configuration so is quite quick and relatively painless. After installation, I added the FOSS driver from the repo, as it wasn't on the live USB. After configuring the machine to use the amdgpu driver, a reboot encountered no problems.
PCLinuxOS packages are in rpm format so I decided to download the Red Hat version of AMDGPU-PRO 16.60 with a view to seeing how the OpenCL stuff was packaged. The first pleasant surprise was the new --compute option in the install script which kindly identified what sub-set of packages was needed just for OpenCL computing. So I extracted the packages in question and moved the contents to /opt/amdgpu-pro/. There were three sub-dirs - bin/ (clinfo), lib64/ (shared libs) and share/ (some docs). There were two other bits in directories lib/ and etc/ for installation elsewhere - /lib/udev/rules.d/91-drm_pro-modeset.rules and /etc/OpenCL/vendors/amdocl64.icd.
After moving all this stuff into place, I ran ldd on clinfo to see what libs that app would be needing. The only one not found was libamdocl64.so. A check on the contents of /opt/amdocl-pro/lib64 showed it was there so I realised I just needed to add /opt/amdocl-pro/lib64 to $LD_LIBRARY_PATH. I was then quite excited to see clinfo run without error and produce a whole bunch of output :-).
So now onto BOINC. When the client starts, at least for V7.2.42 which I'm using, GPU detection depends on the client finding the OpenCL libs as /usr/lib64/libOpenCL.so. With the old fglrx driver, PCLOS installs everything under /usr/lib/fglrx-current/. I've always needed to add a symbolic link in /usr/lib64 pointing to fglrx-current/libOpenCL.so. I presumed I would need to do a similar thing for the new OpenCL stuff in /opt/amdgpu-pro/lib64. The contents of the .icd file that I'd installed in /etc above pointed to the OpenCL lib being libamdocl64.so so I just created the link libOpenCL.so -> libamdocl64.so.
I have a small shell script that launches BOINC. It checks a couple of things and launches the client as a daemon. So I modified the script on the test machine to prefix the command to launch the client with LD_LIBRARY_PATH=/opt/amdgpu-pro/lib64. This machine had never been restarted after a storm last December had taken out the entire fleet. I had progressively brought most hosts with GPUs back to crunching but had retired most of rest - including 6 similar Q6600 CPU machines. I knew there would be expired CPU tasks to clean up but otherwise the BOINC installation should all be there ready to go.
So I just inserted the new GPU in the PCI-e slot and used the supplied 6-pin <-> molex power cable to get GPU power from the existing 300W PSU (270W available at 12V). I knew from previous experience that these PSUs will run a HD7850 in a similar setup so the new card should use less and so should be fine. I'll get around to doing some proper power measurements at some point :-).
When I was running the live USB to reinstall PCLOS in the root partition, I mounted /home temporarily and added all the apps and other files needed (eg. app_config.xml for x2 GPU crunching) to the existing BOINC stuff. I also edited client_state.xml to add the tag <dont_request_more_work/> so that BOINC wouldn't try to fetch anything when first launched.
BOINC launched just fine with warnings about the 'long overdue' tasks. I was very pleased to see the following in the event log
After aborting the expired CPU tasks, I allowed new work and watched as BOINC downloaded both CPU and GPU tasks. It was very nice to see GPU crunching take off. I only had one GPU task initially and it took a few retries to get some more so I had the opportunity to get a feel for a single task crunch time - probably would have ended around 24 mins. It has been crunching for the best part of 2 days now with no errors or invalids. A look at the list of validated tasks shows close to 100 so far, with each pair finishing in about 36-37 mins, so a nice improvement over the single task crunch time. Based on the results so far, the theoretical RAC should be around 270K - not too shabby for a $US100 upgrade to a previously retired host :-).
Cheers,
Gary.