AMD Unleashes Initial AMDGPU Driver Support For GCN 1.0 / Southern Islands GPUs

[haagch]

If you are still seeing that problem repo with current kernels can you please update the ticket accordingly ?

They know, because it is probably (?) the same as https://bugzilla.kernel.org/show_bug.cgi?id=103561 which I did update a couple of times.
There's another maybe related bug linked that is also still open: https://bugs.freedesktop.org/show_bug.cgi?id=92258

OK, that is something more then year old with old kernel,etc... but I spotted something even older there like BIOS 4.6.5 08/22/2012

Is there newer BIOS version avalable for that laptop? I guess, you might have some general stability problems with it or so... if that is a problem then you might get all range of false positives with software you use, etc...

Maybe. But I don't dare updating the BIOS. When I first got that laptop, I prepared a bios update USB flash disk, put it in, power off, power on - and the mainboard was bricked. Before I even started. I found a recovery procedure somewhere with google, but that also didn't work. The shop was friendly enough to replace it for free, but damn. Also this is just not a simple bios update, you need separate "firmware" and "bios" update files and they need to match or you will brick the mainboard. And if I brick it, where do I get a new Clevo P170EM mainboard? The shop where I got it from doesn't sell that model anymore...

Mainboard manufacturers should be required by law to include not only a flashable bios, but also a hardcoded read only bios that you can switch to with a physical switch in order to recover a broken bios. Seriously, how is that not a standard by now?

Edit: Cool, they changed the update procedure to run under dos

How to flash EC firmware:

1. Plug in AC adaptor.
2. Run ECFlash.bat under pure DOS to start EC flash procedure, the system will shut down automatically when the procedure is finished.
3. Plug off AC adapter for 5 seconds then plug in AC adapter.
4. Power on system and enter CMOS setup to check EC firmware version.

How to flash BIOS ROM:

1. Plug in AC adaptor.
2. Enter CMOS setup to disable "Intel Anti-Theft Technology" if the item is available.
3. Enter CMOS setup to check the EC firmware version, if the version is 1.00.xx then it is necessary to update EC firmware at first.
4. Run Meset.exe under pure DOS environment, system will restart automatically.
5. Run flashme.bat under pure DOS, system will shut down automatically.
6. Plug off AC adapter for 5 seconds then plug in AC adapter.
7. Power on system, the system will restart automatically.
8. Enter CMOS setup to check BIOS version and load system default, save changes and reboot.
9. If the original BIOS settings are different from system default, please enter CMOS setup to change BIOS settings before system loads Windows.

That doesn't sound so scary.

Maybe I'll do that. It's from April 2013. Not much newer, but still a bit.

[Kano]

Well best do a firmware dump before you flash it as you already know it could break. Then you could recover it if needed with a reprogrammed firmware chip or via a spi flash programmer directly on the board.

[haagch]

If I knew how to do that...
Also I have zero equipment here to flash a bios chip "manually".

[Amarildo]

Got everything to build on Arch. LLVM-4.0 prevented SDDM (my login manager) to start so I compiled Mesa against LLVM 3.8.

If anyone's interested in a tutorial: https://www.wilderssecurity.com/thre...ux-4-8.387441/
Let's all test this and report back to AMD.

bridgman Does the Mesa repo used have Vulkan for SI? I couldn't find it, but I also didn't look too hard.

[amarildo@amarildo mesa-devel]$ find -name '*vulkan*'
./src/mesa/lib/libvulkan_intel.so
./src/mesa/src/intel/vulkan
./src/mesa/src/intel/vulkan/libvulkan_intel.la
./src/mesa/src/intel/vulkan/libvulkan_common.la
./src/mesa/src/intel/vulkan/.libs/libvulkan_intel.la
./src/mesa/src/intel/vulkan/.libs/libvulkan_common.la
./src/mesa/src/intel/vulkan/.libs/libvulkan_intel.lai
./src/mesa/src/intel/vulkan/.libs/libvulkan_intel.so
./src/mesa/src/intel/vulkan/.libs/libvulkan_common.a
./src/mesa/include/vulkan
./src/mesa/include/vulkan/vulkan.h
./src/mesa/include/vulkan/vulkan_intel.h
./src/fakeinstall/etc/vulkan
./src/fakeinstall/usr/lib/libvulkan_intel.la
./src/fakeinstall/usr/include/vulkan
./src/fakeinstall/usr/include/vulkan/vulkan.h                                                                               
./vulkan-intel-12.1.0-0-x86_64.pkg.tar.xz                                                                                   
./pkg/vulkan-intel                                                                                                          
./pkg/vulkan-intel/usr/lib/libvulkan_intel.so                                                                               
./pkg/vulkan-intel/usr/share/licenses/vulkan-intel                                                                          
./pkg/vulkan-intel/usr/share/vulkan                                                                                         
./pkg/vulkan-intel/usr/include/vulkan                                                                                       
./pkg/vulkan-intel/usr/include/vulkan/vulkan_intel.h

[haagch]

Amd has no open source Vulkan. You can try to use amdgpu-pro without dkms driver to see if opengl 4.5 and vulkan works. Amdgpu-pro user level software uses amdgpu kernel driver if dkms hybrid driver initialization fails. In Debian it is easy to leave dkms out from amdgpu-pro-installer script.

At least Vulkan doesn't:
vulkaninfo: symbol lookup error: /amdgpu//usr/lib/x86_64-linux-gnu/amdvlk64.so: undefined symbol: amdgpu_get_marketing_name

AMD has yet to open up their slightly modified libdrm and xf86-video-amdgpu from amdgpu-pro so there's no way to merge the SI support into the amdgpu-pro libraries that their Vulkan driver requires.

[haagch]

Did you have libdrm-amdgpu-pro-amdgpu1_16.30.3-306809_amd64, libdrm-amdgpu-pro-amdgpu1_16.30.3-306809_i386, libdrm2-amdgpu-pro_16.30.3-306809_i386, libdrm2-amdgpu-pro_16.30.3-306809_amd64 and xserver-xorg-video-amdgpu-pro_16.30.3-306809_amd64 packages installed?

Hm, I thought it doesn't have SI support, but the patch looks more like it is rather disabling something for SI that all other gens on amdgpu can do: https://cgit.freedesktop.org/~mareko...4702c984e05bf1
Maybe it's worth a try.

I think you are lost when using Arch packages. Use Debian, steamos or ubuntu. I did check amdgpu_get_marketing_name function from amdgpu-pro dkms driver sources, no such function there, so it is in the amdgpu-pro libdrm package.

Leaving the dkms driver out means leaving the amdgpu-pro-dkms_16.30.3-306809_all package out. See the original package list from:
http://repo.steampowered.com/steamos...pro-installer/

I actually took the PKGBUILD for amdgpu-pro and modified it to install in /amdgpu/: https://gist.github.com/ChristophHaa...192d6f153822b9
And my intention was to use LD_LIBRARY_PATH etc. as needed.

This error message was created with

VK_ICD_FILENAMES=/amdgpu/etc/vulkan/icd.d/amd_icd64.json vulkaninfo

after editing amd_icd64.json to point to the driver in /amdgpu/...../ of course.
And to use amdgpu-pro's libdrm would then simply be

VK_ICD_FILENAMES=/amdgpu/etc/vulkan/icd.d/amd_icd64.json LD_LIBRARY_PATH=/amdgpu/usr/lib/x86_64-linux-gnu/amdgpu-pro/ vulkaninfo

Maybe I will try that later.

I see agd5f is active on the mailing list again, so hopefully he gets to this soon.

[Amarildo]

Lightdm and Xfce has no problems with Mesa 12.1.0-devel - padoka PPA and llvm 4.0

I tried lightdm as well, same as my other thread here: didn't work.
But I don't think they're the problem, though. I don't think support for my specific card is here yet.

[Amarildo]

Or Arch Linux is unstable. Packages in the Linux system should match and Debian has the best packaging system and more tested packages.

Bullshit. Debian Unstable/Testing can be unstable as hell, are more often than not a dependency hell, and are very far behind on version updates compared to Arch, despite having hundreds of developers (if not thousands). Arch, on the other hand, only has around 37 developers, but delivers the latest packages for almost every package on it's repos, and is way more stable than Debian. I never had one big problem running Arch for almost 3 years, but on Debian I've had many.
And don't even get me started on package management. Debian is slow as f*** to install things and can easily be 10x slower to install things than Arch. While it's "Selecting Previously Unselected bla bla bla", "Unpacking bla bla bla", Configuring bla bla bla", "Setting Up bla bla bla", Arch already made it's way around it numerous times.

[haagch]

To be fair, archlinux's package manager does less work. Partial upgrades are not "supported" on Archlinux. You are supposed to only have the most recent version of any package in the repositories installed and if you don't, dependencies are allowed to arbitrarily break. On apt distributions they try really hard to allow this...

[Amarildo]

To be fair, archlinux's package manager does less work. Partial upgrades are not "supported" on Archlinux. You are supposed to only have the most recent version of any package in the repositories installed and if you don't, dependencies are allowed to arbitrarily break. On apt distributions they try really hard to allow this...

There could be a few packages that require always the latest of a few other packages, but I personally never used one of these and never even seen them. Even right now, if I want to install Linux 3.10 (the oldest in the archive) I can do so.

[root@amarildo ~]# pacman -U linux-3.10.10-1-x86_64.pkg.tar.xz
loading packages...
warning: downgrading package linux (4.6.4-1 => 3.10.10-1)
resolving dependencies...
looking for conflicting packages...

Packages (1) linux-3.10.10-1

Total Installed Size:   64.98 MiB
Net Upgrade Size:      -10.87 MiB

:: Proceed with installation? [Y/n]

What I usually see is packages that require a non-bleeding-edge package, like the AMD Catalyst driver which doesn't work with Xorg 1.18, so in the PKGBUILD there's a requirement "Xorg < 1.18".

Also, what I only see in the PKGBUILD's are the names of the dependencies, but not the versions, so I think it's possible to never update a dependency (not that the dependant package will work, though).