Vega 64 on Debian 9

[Particle]

Has anyone played around with a Vega 64 video card on Debian 9? I've not had any luck getting hardware 3D to work.

I have the latest kernel (4.15.0 release), latest kernel firmware, and latest mesa (18.0.0-rc3). Unfortunately, I seem to be missing something. When I run glxinfo I see that my renderer is llvmpipe. If I put my Radeon 390 back in, everything works. It's something I'm missing specifically required for Vega it seems.

Edit for future searchers:
The answer seems to be that a newer llvm is required for Vega support. Debian 9 comes with llvm 3.9. Building mesa with llvm 5.0, 6.0 or 7.0 all produced working 3D libraries with Vega. Newer versions of llvm are available from the repositories at llvm.org, and it also looks like Debian stretch backports contains llvm 5.0.

[smoki]

Vega require CONFIGURE_DRM_AMD_DC enabled in your kernel, so make sure you have that would be my first guess.
Mesa also needs to builded against minimum LLVM 5 would be my second guess.
etc..

But newer the better there, since it is new gen hardware.

[Particle]

I do have CONFIGURE_DRM_AMD_DC toggled on in my kernel build, but I built mesa against LLVM 3.9. I'll see if I can get LLVM 5.0 from buster ported in. I've avoided that in the past because it has deep dependencies like libc that must also be pulled.

[bw123]

I'll see if I can get LLVM 5.0 from buster ported in. I've avoided that in the past..

Instead of creating a frankendebian, why not just use testing? How did you get mesa 18 working on stretch?

[Particle]

I'll see if I can get LLVM 5.0 from buster ported in. I've avoided that in the past..

Instead of creating a frankendebian, why not just use testing? How did you get mesa 18 working on stretch?

Indeed, I'm not fond of going down the Frakendebian path either. I like the predictability of stable, but I do require some graphics components to be up to date.

Mesa 18 builds and runs alright so long as you update libdrm2 to 2.4.87 or better, so I've pulled 2.4.89 and its associated driver packages from buster in the past. The same requirement existed for 17.4 and maybe a few branches before that as well. The rest of the deps and build requirements are the same as they are for the 17.0 branch.

Final note: Building Mesa 18.0.0-rc3 against LLVM 5.0.1 seems to result in my Vega card working. =) I had to pull in llvm5 from buster (libllvm5.0, llvm-5.0, llvm-5.0-dev, llvm-5.0-runtime) and update the llvm-config symlink to point to llvm-config-5.0 instead of llvm-config-3.9. Unfortunately, I've never figured out how to do a successful cross-compile of mesa for i386 so that I could update the runtime used for the Steam client and 32-bit games. That hunt continues.

The cheat sheet version is:
sudo apt-get -y install build-essential
sudo apt-get -y install libdrm-dev libva-dev libvdpau-dev libclc-dev libxvmc-dev zlib1g zlib1g-dev
sudo apt-get -y build-dep mesa
autoreconf -vfi
./configure --prefix=/usr --libdir=/usr/lib/x86_64-linux-gnu/ --with-dri-driverdir=/usr/lib/x86_64-linux-gnu/dri --enable-driglx-direct --enable-gles1 --enable-gles2 --enable-glx-tls --with-platforms='drm x11' --with-gallium-drivers=radeonsi,swrast --enable-texture-float --enable-shared-glapi --enable-glx --enable-gbm --enable-xa --enable-osmesa --enable-vdpau --enable-xvmc --enable-nine --with-vulkan-drivers='radeon intel' --enable-opencl
time make -j16
(at this point, it would be best to package and install it that way, but I lack the knowledge for how to package it so I "sudo make install" in the knowledge that I'll have to do so again if mesa ever updates through apt)

[bw123]

I like the predictability of stable, but I do require some graphics components to be up to date.

I understand what you are saying, I read threads like this a lot on here. Mixing in pkgs from buster on stretch might not give you the "predictability" you like and expect on stable.

Let us all know how stable it is if you can though, after 30 days, 60 days, etc. after doing some upgrades of the system. I know a lot of people are struggling with this hardware.

[smoki]

I had to pull in llvm5 from buster...

Do not mix packages like that, if you want newer llvm in deb packages for Stretch currently of llvm 5, 6 or 7 there are repos on:

https://apt.llvm.org/

5 is released, 6 will be released this month, 7 is current development, etc... maybe you woud like to rebuild mesa 18.0 agains llvm 6 that that sounds more in line nowdays, track these stable branches for couple months if you prefer stability otherwise all git master

[stevepusser]

Ahem...let me butt in here: https://build.opensuse.org/project/show ... h-backport

The llvm-5.0 backport builds on vanilla Debian; the other backports in the repo were needed to backport Mesa 17.3 Be aware that if you do this on your own machine, llvm and mesa are quite heavy builds.

Let me see if Mesa 18 is upstream yet...well, there's an rc2 in Experimental.

[Particle]

I had to pull in llvm5 from buster...

Do not mix packages like that, if you want newer llvm in deb packages for Stretch currently of llvm 5, 6 or 7 there are repos on:

https://apt.llvm.org/

5 is released, 6 will be released this month, 7 is current development, etc... maybe you woud like to rebuild mesa 18.0 agains llvm 6 that that sounds more in line nowdays, track these stable branches for couple months if you prefer stability otherwise all git master

I'm never a fan of mixing packages, but it seemed to be a requirement as a gamer. That said, I can honestly say I never knew that the LLVM project maintained their own official repos for Debian. I'll switch to that. Thanks!

Ahem...let me butt in here: https://build.opensuse.org/project/show ... h-backport

The llvm-5.0 backport builds on vanilla Debian; the other backports in the repo were needed to backport Mesa 17.3 Be aware that if you do this on your own machine, llvm and mesa are quite heavy builds.

Let me see if Mesa 18 is upstream yet...well, there's an rc2 in Experimental.

I don't quite understand. Are you saying there is an official backports build of Mesa for Debian?

[smoki]

I don't quite understand. Are you saying there is an official backports build of Mesa for Debian?

Yes, but not quite yet... according to this stretch-backports will have mesa 17.3 and llvm 5 very soon:

http://debian.2.n7.nabble.com/Request-f ... 62373.html

So you will soon get mesa stack what is now in buster to stretch-backports or to say it will jump (as an option) from strong year 2016. era mesa drivers to strong year 2017. era drivers, but don't expect current so year 2018. era drivers for stretch-backports since even backports are conservative... aka - you won't get mesa 18 and llvm 6 there, etc...

Basically user of Debian 9 will have strong stock drivers from year 2016. and strong 2017. mesa drivers in backports as an option... but current one like mesa 18.x and llvm 6 or newer either you should build yourself or if you could find them in some unofficial repo.

That said if someone wanna do backport of current drivers via OBS for example like stevepusser seems wanna do, he should really focus now on mesa 18.x and llvm 6.x

[Particle]

Very interesting. I'll be glad to see that when it drops into backports. I'll update my base system to use that as soon as I find it is available, and that should let me stop doing make install on my own builds.

I'll continue to build and use my own mesa libs as necessary for high performance games and to address bugs that get fixed in later versions of mesa, but I can do that purely through exporting LIBGL_DRIVERS_PATH, LD_LIBRARY_PATH, EGL_DRIVERS_PATH to an uninstalled custom build for that specific application.

I'm not particularly demanding. This quest has been mostly about getting this new-release hardware to work at all.

Thanks for all of the information, by the way.

---

On a side note, I've discovered that the builds of llvm on the llvm.org repos aren't built multi-lib. As such, it's not possible to have both the amd64 and i386 versions installed simultaneously of any one version. I had a real need to have both so that I could run a 32-bit mesa for the Steam interface even though all of the games I actively play are 64-bit. As a work-around, I ended up installing llvm-6.0:i386 and llvm-7.0:amd64. That occurred to me since I had previously discovered that even llvm-5.0 was sufficient to get Vega working.

I used llvm-7.0 to build a 64-bit copy of mesa-18.0.0-rc3 and used llvm-6.0 to build a 32-bit copy of the same mesa. I used a virtual machine to build the 32-bit version, tar'd the result, and extracted it into a folder on my system for use. (I still have never figured out how to build an installable 32-bit version on a 64-bit machine due to multi-lib issues with some build dependencies.) The 64-bit build I simply installed. In this way I have a 64-bit mesa using the latest llvm-7.0 build for my system and all of my high performance games while Steam and any 32-bit games I may occasionally launch use a 32-bit mesa built against llvm-6.0.

Are there any good newbie resources on how to build a deb from compiled source? I'd really, really, really like to stop doing make install, but I lack any experience with packaging whatsoever.

[smoki]

Are there any good newbie resources on how to build a deb from compiled source? I'd really, really, really like to stop doing make install, but I lack any experience with packaging whatsoever.

Well, first guide about debian packaging is this:

https://www.debian.org/doc/manuals/maint-guide/

Maybe it is not really for newbies, but maybe it is as i dunno probably depends on who is the newbie ... hmm, maybe these then could help something:

https://raphaelhertzog.com/debian-packaging/

These are aimed for proper debian packaging if your aim is to be clear, optimal or to share these debs with others... but there are also many other more easy and more dirty ways like with using checkinstall. With that it will just package your 'make install' result in just one package and you can letter brute force overwrite installed mesa what is currently installed with 'dpkg --force-overwrite *.deb' and it is easy to be removed, just remove deb and do not forget to reinstall all of proper packaged mesa packages right after and so on:

https://manpages.debian.org/stretch/che ... .8.en.html

That is probably quickest and easiest to make dirty deb, but yeah it is dirty as hell so considered it as something just for you

Basically how time go you would realise that you don't need everything to even be compiled, you can comple your llvm for example - now, from llvm package you don't need clang just llvm is needed for radeonsi mesa dri driver, from mesa you don't need to compile every single driver just what you use... To the end, what to say - you can even ask on irc #radeon maybe some AMD dev will be kind to share some ideas or even scipts to be as fast as possible on doing this driver managment as a user, etc... as they are doing these drivers every single day that might force you to use Debian Sid and to also roll everything every day, but that is really not needed for an average Joe

There are just 2 actual releases of llvm per year and 4 of mesa, everything else is just development Same as linux kernel, there are just 5 releases of kernel out of which only 1 or 2 are longterm per year...

[Particle]

All of that is really helpful information. I really should take the time to figure out which pieces of mesa I actually use like you suggest. The good news though is that on my system compiling the whole thing takes less than three minutes so there isn't a big temporal cost. I love living in the glorious wide-processor future in which we find ourselves. =) The big attraction for me would be the reduction of dependencies which you hinted at.

[smoki]

Well, (also not to forgot to mention) not everything is really in mesa, you might wanna also try AMD official opensource amdvlk vulkan driver instead of radv:

https://github.com/GPUOpen-Drivers/AMDVLK

now they mention GCC there, so fully opensource official VK alternative is there. But, maybe even builded with AMD proprietary AOCC compiler (based upon LLVM) it would go even faster:

https://developer.amd.com/amd-aocc/

But that is just a guess, if i have Vega and Ryzen (as i both don't have) i would certainly try all that for myself... and their Radeon GPU Profiler too:

https://gpuopen.com/gaming-product/rade ... filer-rgp/

Now of course Debian won't package their blobby compiler/tools especially whatever, their GPUOpen-Tools sounds really interesting to me.

[TrevorKSmithKS]

Can i get a little bit of assistance with getting the full functionality of Vega 64 and Vega 64 Frontier on linux?

Currently on my Debian Stretch system, i am using kernel 4.15.12 which i compiled and installed myself. I went out and fetched the firmware files needed to be dropped in /lib/firmware/amdgpu. Rebooted, and was glad to experience full screen support. However, i notice when running glxinfo | grep OpenGL , i get OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.9, 128 bits).

To the best of my knowledge, this means the CPU is still picking up the load for rendering, and would explain my low FPS within the environment.

Reading around, and this thread, it seem i need to upgrade my LLVM to atleast 5.0 for support. I went ahead and enabled stretch-backports temporarly, install LLVM 6.0, disabled the backports, and rebooted. I can confirm the LLVM 6.0 installed correctly as far as the package is concerned, but it doesn't seem to be used, LLVM 3.9 is still in use.

Im unsure where i need to go from here, something with mesa? and comipiling my own LLVM similar like i did with the kernel? and i read something about a specific flag needing to be enabled in my Kernel?

I been trying to solve this myself for quite some time, but alot of this is going outside my scope of current skill.

Any guidance would be greatly appreciated on what i should be looking to do next to solve my issues.

Thanks!

--Trevor K Smith

Update

Ive read this from a friendly user above.

Edit for future searchers:
The answer seems to be that a newer llvm is required for Vega support. Debian 9 comes with llvm 3.9. Building mesa with llvm 5.0, 6.0 or 7.0 all produced working 3D libraries with Vega. Newer versions of llvm are available from the repositories at llvm.org, and it also looks like Debian stretch backports contains llvm 5.0.

Am i missing a command to enable llvm 5.0 so that it actually gets put in use? I believe i have the package installed correctly, however, it still uses 3.9.

Here is a command that may be helpful.

Code: Select all

root@M14EBR:~# dpkg-query -l | grep llvm
ii  libllvm3.9:amd64                              1:3.9.1-9                                  amd64        Modular compiler and toolchain technologies, runtime library
ii  libllvm6.0:amd64                              1:6.0-1~bpo9+1                             amd64        Modular compiler and toolchain technologies, runtime library
ii  llvm-6.0                                      1:6.0-1~bpo9+1                             amd64        Modular compiler and toolchain technologies
ii  llvm-6.0-dev                                  1:6.0-1~bpo9+1                             amd64        Modular compiler and toolchain technologies, libraries and headers
ii  llvm-6.0-runtime                              1:6.0-1~bpo9+1                             amd64        Modular compiler and toolchain technologies, IR interpreter