Installing AMDGPU-PRO Ubuntu Driver under Slackware 14.2?
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
If you don't need the extra stuff from the pro driver (I think opencl and vulkan?) you may try with mesa.
Here some benchmarks, difference is often small sometimes is even faster: http://openbenchmarking.org/result/1...LO-AMDGPUVSM87
rx480 works fine here with slackware current, I only installed a newer Kernel (4.8.0rc5)
But if you play TF2 there is a crash problem with the mesa drivers it seems: https://github.com/ValveSoftware/Sou...es/issues/1943
If you don't need the extra stuff from the pro driver (I think opencl and vulkan?) you may try with mesa.
Here some benchmarks, difference is often small sometimes is even faster: http://openbenchmarking.org/result/1...LO-AMDGPUVSM87
rx480 works fine here with slackware current, I only installed a newer Kernel (4.8.0rc5)
But if you play TF2 there is a crash problem with the mesa drivers it seems: https://github.com/ValveSoftware/Sou...es/issues/1943
mkdir -p work/pkg
cd work
ar -x /path/to/SpaceChem-i386.deb
cd pkg
tar xvf ../data.tar.gz
Then, as root, you run makepkg in the work/pkg directory, like
makepkg -l y -c n /tmp/SpaceChem-i386.txz
is there a way to do this in a batch mode so all .deb files are properly converted and respectively named?
What you want to do is take the .deb files, batch extract them to a /temp/directory, then use appropriate Slackbuild style scripts, use a SlackBuild script to repackage everything as needed.
You might also want to consider cloning the SlackBuild.org nvidia-driver package's nvidia-switch script and reformulate it for amdgpupro to backup the existing system Mesa package.
If you need help, look at the Slackware install media's /extras directory and see how Google-Chrome is installed. It uses a .deb package also.
What you want to do is take the .deb files, batch extract them to a /temp/directory, then use appropriate Slackbuild style scripts, use a SlackBuild script to repackage everything as needed.
You might also want to consider cloning the SlackBuild.org nvidia-driver package's nvidia-switch script and reformulate it for amdgpupro to backup the existing system Mesa package.
If you need help, look at the Slackware install media's /extras directory and see how Google-Chrome is installed. It uses a .deb package also.
Honestly, except for the bit about the Nvidia driver, that is exactly the approach is as going to take. Just was wondering about a batch extraction because 44 files is a lot to sift through.
EDIT: This doesn't work yet... I'm trying to tweak it on my phone while ssh'ed in to my desktop. Progress is a bit slow. Figured it out. They were using xz compression instead of gzip like most the archives I've dealt with in the past. This will create etc/, lib/, and usr/ folders under $TMP, so it is then just a matter of going through those folders and see what needs tweaking and what needs removal.
You could do something like the following (not at home, so I can't check how well this works... if at all -- it might need some tweaking):
Code:
CWD=$(pwd)
TMP=${TMP:-tmp_amdgpu-pro}
if [ -z "$ARCH" ]; then
case "$( uname -m )" in
i?86) ARCH=i586 ;;
arm*) ARCH=arm ;;
*) ARCH=$( uname -m ) ;;
esac
fi
if [ "$ARCH" = "i586" ]; then
DEBARCH="i386"
LIBDIRSUFFIX=""
elif [ "$ARCH" = "x86_64" ]; then
DEBARCH="amd64"
LIBDIRSUFFIX="64"
fi
rm -rf $TMP
mkdir $TMP
cd $TMP
for i in $CWD/*_{$DEBARCH,all}.deb; do
ar p $i data.tar.gz | unxz | tar xv
done
This should extract all the debs for your architecture (and the "all" arch) into a amdgpu-pro_tmp directory... if I did it properly. From there, you'd need to see what is needed for Slackware and you could then work on removing/changing the things that are needed, finally culminating in creating a Slackware package using makepkg. Basically, you could use this code as the basis to start a SlackBuild for this (if you feel so inclined).
Last edited by bassmadrigal; 09-16-2016 at 08:22 AM.
Ok, so I was bored at work (don't tell my boss) and I decided to try and work out a full SlackBuild. This results in a created package, however, I don't have the hardware to test if this works or not. I also haven't had a chance to dig through the files to see if anything overwrites anything important or if we should be adding any .new extensions to the end of conf files and use a doinst.sh. I also don't know if there should be any xorg.conf type files created, but the package doesn't create any (I'm guessing the xorg portion is covered by the opensource amdgpu driver, but that's just a guess).
Feel free to try it out, but you might want to check through the /tmp/SBo/package-amdgpu-pro-driver/ folder to see if it seems like it might clobber something important. If it does, we can adjust the script if needed to take that into account. Feel free to leave me any feedback, positive or negative.
Now that I'm home (and not doing everything through my phone), I did a more thorough check. It seems that everything should install without clobbering anything else. There is a 01-amdgpu-pro.conf file under /usr/share/X11/xorg.conf.d/, so that will be where X loads its information (and should mean we shouldn't need a custom conf file for xorg).
If anyone wants to peruse the ~1300 line file tree, check it out here.
I have to say, other than only providing us a ton of .deb packages, this seems to be pretty well put together. I'm not noticing anything that should conflict with files in existing packages (like with the Nvidia blob clobbering some of mesa's files).
But still, this hasn't been tested by me, only perused, so I'd love to hear some feedback
For vulkan I think you'd need to get the vulkan SDK. There is radv on github. But @ReaperX7 gave good advice to use amdgpu and Mesa. Oh in any case make sure you get the latest firmware for your driver.
Out of curiosity why do you want to use the proprietary driver?
Also, the reasoning behind the reworking nvidia-switch to become an amd-switch script is to preserve mesa equally in the system alongside amdgpu-pro's OpenGL libraries.
The proprietary driver does have a few features like built-in firmware, s3tc support natively, config tools, etc. but mostly the amdgpu and amdgpu-pro drivers are fairly equal. Libtxc-dxtn and driconf can supplement you nicely enough.
Oh in any case make sure you get the latest firmware for your driver.
If you use amdgpu-pro, it includes firmware. But Slackware includes almost all that firmware anyway (there's only 6 new files -- see below).
Out of curiosity why do you want to use the proprietary driver?[/QUOTE]
Performance is typically a bit better... if you're willing to deal with the binary aspect of it. (But regular opensource performance is still pretty good.)
Quote:
Originally Posted by ReaperX7
Also, the reasoning behind the reworking nvidia-switch to become an amd-switch script is to preserve mesa equally in the system alongside amdgpu-pro's OpenGL libraries.
If you read my last post, you'd see that it doesn't seem to clobber any of mesa. There should be no need for an amd-switch script. However, after finally building it on a 14.2 machine (all the previous work was done on a 14.1 machine that is easily accessible from outside my network), I was able to run installpkg --warn on the package, and it looks like it will overwrite some firmware, however, after comparing filesizes, there's only two (fiji_sdma1.bin and tonga_sdma1.bin) that are actually different from what's included in 14.2's firmware package (and those two files are both only 20 bytes larger). It does include 6 new firmware files (although, according to various web reports, the Amur project was cancelled):
If it uses Mesa then this is a welcome sign. However, did you check for any symlinks created by the .deb post-install scripts, if there were any? Amdgpu-pro should support s3tc and by so, have it's own libGL.so.xxx files that are then relinked as libGL.so.# and libGL.so, and so forth for vulkan, etc.
Yes, but it's still not anywhere near Nvidia as well.
It packages it's own xorg-server-1.15 binary, several Mesa, libdrm, libvdpau, and OpenCL files. Why not just source release the kernel module like Nvidia and the main xorg driver components to avoid an ABI issue? Mostly it's nothing but a full binary only package.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
