LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 09-24-2018, 10:33 PM   #1
ScrambledLogic
LQ Newbie
 
Registered: Aug 2015
Distribution: Slackware
Posts: 13

Rep: Reputation: 0
Question Unable to run Vulkan in Slackware64-current with amdgpu


I'm having an issue getting Vulkan to work on a new system with a Slackware64-current installation installed using AlienBob's 09-18-2018 -current iso.
CPU is a Ryzen 5 2600, GPU is an RX 580
The system is up-to-date, using slackpkg+ and a greylist to ensure that I'm updating with multilib packages where appropriate.

vulkaninfo results in the following:
Code:
Vulkan Instance Version: 1.1.73

/tmp/Vulkan-LoaderAndValidationLayers-sdk-1.1.73.0/demos/vulkaninfo.c:3141: failed with VK_ERROR_INITIALIZATION_FAILED
running ls | grep vulkan in both /usr/lib and /usr/lib64 show the following:
Code:
libvulkan.so -> libvulkan.so.1*
libvulkan.so.1 -> libvulkan.so.1.173*
libvulkan.so..1.1.73*
libvulkan_intel.so*
libvulkan_radeon.so*
running lspci | grep VGA gives this:
Code:
2e:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Ellesmere [Radeon RX 470/470/570/580] (rec e7)
running cat/var/log/Xorg.0.log outputs:
Code:
[   303.559] (II) LoadModule: "amdgpu"
[   303.581] (II) Loading /usr/lib64/xorg/modules/drivers/amdgpu_drv.so
[   303.598] (II) Module amdgpu: vendor="X.Org Foundation"
        All GPUs supported by the amdgpu kernel driver
Multilib was installed with slackpkgplus's multilib install script. I'm running the 4.18.9 kernel compiled with this config: https://dusk.idlemoor.tk/config/conf...ric-4.18.9.x64
The only change I made to the kernel config file was enabling Automatic Process Group Scheduling.

As far as I understand, the presence of the libvulkan_radeon.so library files means I should have the radv Vulkan api installed and usable.

Other than the vulkaninfo error above, I also am unable to run Vulkan games.
Rise of the Tomb Raider installed from Steam claims I have no Vulkan API installed.
The Talos Principle simply crashed when I attempt to switch from OpenGL to Vulkan.

I apologize if I'm missing some simple line in a config file somewhere, but I haven't been able to find a solution.

Anybody have any ideas?

Last edited by ScrambledLogic; 09-24-2018 at 10:41 PM.
 
Old 09-25-2018, 12:50 AM   #2
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 7,101

Rep: Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773
What vulkan packages do you have installed? Do you have both 32bit and 64bit versions installed?
 
Old 09-25-2018, 01:18 AM   #3
ScrambledLogic
LQ Newbie
 
Registered: Aug 2015
Distribution: Slackware
Posts: 13

Original Poster
Rep: Reputation: 0
@bassmadrigal
The only Vulkan packages that appear to be installed are the following via ls /var/log/packages/ | grep vulkan:
Code:
vulkan-sdk-1.1.73.0-x86_64-1
vulkan-sdk-compat-32-1.1.73.0-x86_64-1compat32
 
Old 09-25-2018, 01:49 AM   #4
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 7,101

Rep: Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773
Based on this bug report, you may be able to solve this by forcing the system to not use the older radeon driver (it might be trying to load both and causing conflicts). Maybe the same will work for you. Add the following to your appends on your bootloader.

Code:
radeon.si_support=0 radeon.cik_support=0 amdgpu.si_support=1 amdgpu.cik_support=1
If that doesn't work, can you run vulkaninfo with the following variable set to enable full debug?

Code:
VK_LOADER_DEBUG=all vulkaninfo
 
Old 09-25-2018, 02:28 AM   #5
zuriel
Member
 
Registered: Aug 2012
Distribution: Slackware
Posts: 38

Rep: Reputation: 43
Try running
Code:
chmod a+rw /dev/dri/renderD*
and see if Vulkan works now. If it does, that's your problem.

Recent Slackware-current updates seem to have broken Vulkan. The issue seems to be new eudev rules setting incorrect permissions on /dev/dri/renderD128. I discovered by accident that running vulkaninfo as root still works. Vulkan programs running as a normal user attempt to access /dev/dri/renderD128 and die.

renderD128 used to have a non-root group, but is now only accessible to root:
Code:
crw------- 1 root root 226, 128 Sep 25 00:57 /dev/dri/renderD128
The issue seems to be udevd not recognising @GROUP_RENDER_MODE@. Dmesg shows:
Code:
udevd[771]: ignoring invalid mode '@GROUP_RENDER_MODE@'
I copied /lib/udev/rules.d/50-udev-default.rules to /etc/udev/rules.d/ and edited it:

Code:
--- /lib/udev/rules.d/50-udev-default.rules     2018-09-23 05:52:27.000000000 +1000
+++ /etc/udev/rules.d/50-udev-default.rules     2018-09-24 22:50:31.021935604 +1000
@@ -36,7 +36,7 @@
 SUBSYSTEM=="media", GROUP="video"
 SUBSYSTEM=="cec", GROUP="video"
 
-SUBSYSTEM=="drm", KERNEL=="renderD*", MODE="@GROUP_RENDER_MODE@"
+SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="video"
 SUBSYSTEM=="kfd", MODE="@GROUP_RENDER_MODE@"
 
 SUBSYSTEM=="sound", GROUP="audio", \
That leaves /dev/dri/renderD128 accessible by the 'video' group after a reboot.

Code:
crw-rw---- 1 root video 226, 128 Sep 25 16:25 /dev/dri/renderD128
Make sure your user account is a member of the video group and you should be good to go. Or just run that chmod command every time you restart.

I finished investigating this late last night, hadn't got around to posting anything yet.
 
2 members found this post helpful.
Old 09-25-2018, 03:30 AM   #6
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 8,063

Rep: Reputation: 6825Reputation: 6825Reputation: 6825Reputation: 6825Reputation: 6825Reputation: 6825Reputation: 6825Reputation: 6825Reputation: 6825Reputation: 6825Reputation: 6825
Yes, this is an issue caused by new systemd rules that are incompatible with non-systemd distros. Upstream bug report looks like this: https://github.com/gentoo/eudev/issues/160

I think this change that Patrick did needs to be altered: https://git.slackware.nl/current/dif...995715d0ddf23a

Instead of getting rid of the 'render' group completely, I believe the 'render' string should be replaced by 'video' so that the old behaviour of eudev in Slackware is restored.
 
1 members found this post helpful.
Old 09-25-2018, 07:57 AM   #7
rogan
Member
 
Registered: Aug 2004
Distribution: Slackware
Posts: 197

Rep: Reputation: 85
After the update two days ago I also got these problems on current64 (multilib) ...
udev spamming system logs.
Doom on vulkan stopped working (using amdgpu on a r9 fury x ).
It starts and seems to work on opengl, but that api is unusable
unless you have a 150Ghz single cpu system.

Last edited by rogan; 09-25-2018 at 08:03 AM.
 
Old 09-25-2018, 09:39 AM   #8
dive
Senior Member
 
Registered: Aug 2003
Location: UK
Distribution: Slackware
Posts: 3,417

Rep: Reputation: Disabled
If the ownership says 'root root' perhaps you can just chgrp and chmod it in rc.local:

/usr/bin/chgrp video /dev/dri/renderD*
/usr/bin/chmod g+rw /dev/dri/renderD*

And make sure that you're in the 'video' group.

A safer approach the a+rw.
 
Old 09-25-2018, 11:16 AM   #9
ScrambledLogic
LQ Newbie
 
Registered: Aug 2015
Distribution: Slackware
Posts: 13

Original Poster
Rep: Reputation: 0
Thanks for the input, everyone!
I tried zuriel's suggestion but that did not seem to change /dev/dri/renderD128's group. I do seem to have other issues with udev however, perhaps they're related, but I'll leave those for a another thread.
dive's solution changed renderD128's group to video after boot, and vulkaninfo now outputs as expected, Vulkan games run, radv seems to work now!
Thanks again, marking as solved.
 
Old 09-25-2018, 01:02 PM   #10
enorbet
Senior Member
 
Registered: Jun 2003
Location: Virginia
Distribution: Slackware = Main OpSys
Posts: 2,840

Rep: Reputation: 2925Reputation: 2925Reputation: 2925Reputation: 2925Reputation: 2925Reputation: 2925Reputation: 2925Reputation: 2925Reputation: 2925Reputation: 2925Reputation: 2925
I hope this isn't considered OT since this was posted.....


Quote:
Originally Posted by ScrambledLogic View Post
@bassmadrigal
The only Vulkan packages that appear to be installed are the following via ls /var/log/packages/ | grep vulkan:
Code:
vulkan-sdk-1.1.73.0-x86_64-1
vulkan-sdk-compat-32-1.1.73.0-x86_64-1compat32
...but how does one get compat32 from a 64bit package? I am under the impression that convertpkg is to be used on 32bit packages. Am I mistaken?
 
Old 09-25-2018, 01:21 PM   #11
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 7,101

Rep: Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773
Quote:
Originally Posted by enorbet View Post
...but how does one get compat32 from a 64bit package? I am under the impression that convertpkg is to be used on 32bit packages. Am I mistaken?
I believe the ARCH is for the ARCH it's to be installed on. If you look at the script, it uses uname -a to set the ARCH variable, and then that is used in the package name.

Code:
OUTPKG=${OUTPKG:-"${PKGNAM}-compat32-${VERSION}-${ARCH}-${BUILD}${TAG}.${PKGEXT}"}
All compat32 packages Eric provides have the x86_64 arch on them.
 
Old 09-25-2018, 01:54 PM   #12
enorbet
Senior Member
 
Registered: Jun 2003
Location: Virginia
Distribution: Slackware = Main OpSys
Posts: 2,840

Rep: Reputation: 2925Reputation: 2925Reputation: 2925Reputation: 2925Reputation: 2925Reputation: 2925Reputation: 2925Reputation: 2925Reputation: 2925Reputation: 2925Reputation: 2925
Thanks bassmadrigal but I'm still confused by these lines

Code:
  
24|# Convert a 32-bit Slackware package (s390 or x86)
25|# to a compatibility package for a 64bit multilib Slackware.
I have no problem with the x86_64 tag just with how a 32bit compatible package is derived from a 64bit package? What am I missing? Is it because SlackBuilds are compiled from source before being crafted into a package? If that's so why does it matter for any package to have a 32bit package to work from? If I'm being unusually dense just blame it on antihistamine.

Last edited by enorbet; 09-25-2018 at 01:57 PM.
 
Old 09-25-2018, 02:04 PM   #13
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 7,101

Rep: Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773Reputation: 4773
Quote:
Originally Posted by enorbet View Post
I have no problem with the x86_64 tag just with how a 32bit compatible package is derived from a 64bit package? What am I missing? Is it because SlackBuilds are compiled from source before being crafted into a package? If that's so why does it matter for any package to have a 32bit package to work from? If I'm being unusually dense just blame it on antihistamine.
No, it takes a 32bit package and converts it for installation on a 64bit system. The arch is listed as x86_64 on the package, because it is designed to be installed on a 64bit system.
 
1 members found this post helpful.
Old 09-25-2018, 02:53 PM   #14
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 8,063

Rep: Reputation: 6825Reputation: 6825Reputation: 6825Reputation: 6825Reputation: 6825Reputation: 6825Reputation: 6825Reputation: 6825Reputation: 6825Reputation: 6825Reputation: 6825
Quote:
Originally Posted by bassmadrigal View Post
No, it takes a 32bit package and converts it for installation on a 64bit system. The arch is listed as x86_64 on the package, because it is designed to be installed on a 64bit system.
That's the essence of it, thanks bassmadrigal.
 
Old 09-26-2018, 12:00 PM   #15
enorbet
Senior Member
 
Registered: Jun 2003
Location: Virginia
Distribution: Slackware = Main OpSys
Posts: 2,840

Rep: Reputation: 2925Reputation: 2925Reputation: 2925Reputation: 2925Reputation: 2925Reputation: 2925Reputation: 2925Reputation: 2925Reputation: 2925Reputation: 2925Reputation: 2925
OK guys, thank you, but that brings up my original concern - How does one get a 32 bit Vulkan package to convert?
 
  


Reply

Tags
amd, current, multilib, vulkan


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[Slackware64-current] newest kernel with better amdgpu support. drigohighlander Slackware 11 02-24-2018 10:03 AM
Pan does not run as user, but does as root with slackware64-current jkh2cpu Slackware 9 12-24-2017 11:17 AM
Slackware 14.2-current + AMDGPU-pro = unable to startx BattKajs Slackware 5 10-12-2017 11:43 PM
[SOLVED] Errors trying to build and run Clementine on Slackware64-current ahc_fan Slackware 17 01-16-2016 05:15 AM
VirtualBox won't run after upgrade to slackware64 current Ook Slackware 9 06-18-2011 07:13 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 07:56 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration