mesa-git - latest videodrivers & issues

lordheavy · 2017-06-10 19:04:15

gee wrote:

Thank you for trying so quickly!
Hmmm, have you used -N when applying the patch? if not I'd guess that would allow it to pass like on my computer.

Tried this also, still fail!

gee · 2017-06-11 05:18:14

Oh

Well thanks for trying!

nannerpussy · 2017-06-11 05:48:15

gee wrote:

Oh
Well thanks for trying!

Been following this and now I'm curious about getting this for myself. Were you using the linux-amd-staging git and just patched over from the upstream official?

gee · 2017-06-11 07:06:47

Correct!

lordheavy · 2017-06-11 09:33:22

nannerpussy wrote:

gee wrote:
Oh
Well thanks for trying!
Been following this and now I'm curious about getting this for myself. Were you using the linux-amd-staging git and just patched over from the upstream official?

You can find the PKGBUILD here: http://pkgbuild.com/~lcarlier/mesa-git/ … d-staging/

skeevy420 · 2017-06-17 13:13:53

Not sure where to post this, but this seems to be the best place...but I've been having some issues with the amd-staging kernel from both the aur and the mesa-git repo from a little over a week ago. My first issue was if "amdgpu" was added as a module in "/etc/mkinitcpio.conf", my system wouldn't boot past systemd udev. Without that added, my system gets stuck in init a little farther down in the process and my driver never changes to amdgpu (every other kernel my screen flickers for a second when the gpu's driver is changed, doesn't happen anymore with amd-staging). Stock, LTS, and Zen all work as expected with those settings. At a minimum, every Arch install I do has those 3 kernels. Unfortunately, I don't have any logs to provide (didn't think to back it up last time it happened, been tweaking my xorg conf lately so lots of reboots, no conf has the same result). When the system would get stuck, the only command I could get to work was crtl+alt+del.

I'll add that I'm using the testing repos, all the mesa-git packages from your repository, and that my GPU is an R7 260x. I'm wondering\speculating if something is breaking AMDGPU on the staging kernel for CIK users such as myself. I haven't tried using the radeon driver with AMD staging. Other than that, I haven't had any issues whatsoever and can say that I've been able to enjoy the best open source gaming solution available thanks to your repository and work.

I don't think CIK users really need to use the AMD staging kernel....do they?

If you're curious, I added the amdgpu module to mkinitcpio.conf because I was hoping that it would speed up grub2 when using themes. It didn't. And I still use an xorg config to run at 50hz instead of 60hz. My monitor supports it and since most games run between 45-60fps on my system, I run at 50hz and cap my FPS to 50 when possible (an experiment I started yesterday, works great with KSP...10 less graphics frames is more time for physics calculations).

nannerpussy · 2017-06-17 13:46:34

skeevy420 wrote:

Not sure where to post this, but this seems to be the best place...but I've been having some issues with the amd-staging kernel from both the aur and the mesa-git repo from a little over a week ago. My first issue was if "amdgpu" was added as a module in "/etc/mkinitcpio.conf", my system wouldn't boot past systemd udev. Without that added, my system gets stuck in init a little farther down in the process and my driver never changes to amdgpu (every other kernel my screen flickers for a second when the gpu's driver is changed, doesn't happen anymore with amd-staging). Stock, LTS, and Zen all work as expected with those settings. At a minimum, every Arch install I do has those 3 kernels. Unfortunately, I don't have any logs to provide (didn't think to back it up last time it happened, been tweaking my xorg conf lately so lots of reboots, no conf has the same result). When the system would get stuck, the only command I could get to work was crtl+alt+del.
I'll add that I'm using the testing repos, all the mesa-git packages from your repository, and that my GPU is an R7 260x. I'm wondering\speculating if something is breaking AMDGPU on the staging kernel for CIK users such as myself. I haven't tried using the radeon driver with AMD staging. Other than that, I haven't had any issues whatsoever and can say that I've been able to enjoy the best open source gaming solution available thanks to your repository and work.
I don't think CIK users really need to use the AMD staging kernel....do they?
If you're curious, I added the amdgpu module to mkinitcpio.conf because I was hoping that it would speed up grub2 when using themes. It didn't. And I still use an xorg config to run at 50hz instead of 60hz. My monitor supports it and since most games run between 45-60fps on my system, I run at 50hz and cap my FPS to 50 when possible (an experiment I started yesterday, works great with KSP...10 less graphics frames is more time for physics calculations).

I just recently finished a long stretch of messing and experimenting with AMDGPU and radeon (radeonsi) drivers, specifically to get early KMS setup on my wonky AMD board and GCN 1.0 mATX-profile Radeon 7750 Sapphire card. AFAIK the CIK kernel is deprecated, those AMDGPU flags are stock since ~3.9 (?) or so. So definitely don't use the specific -cik AUR package, regardless of your card. If your card is a couple years old like mine, I'm having success right now with the standard vanilla kernel, using both AMDGPU and radeon (radeonsi) drivers. I use the "radeon" "amdgpu" module with initcpio, with the "kms" hook for early mode-setting. ~~Oddly, amdgpu takes control and the kms sets in early and without error, without the amdgpu module specifically listed.~~ I am honestly not well-versed with all of this AMDGPU stuff like most others here are though. But:

  1.066979] [drm] amdgpu kernel modesetting enabled.
[    1.067789] checking generic (c0000000 300000) vs hw (c0000000 10000000)
[    1.067790] fb: switching to amdgpudrmfb from EFI VGA
[    1.067812] Console: switching to colour dummy device 80x25
[    1.068114] [drm] initializing kernel modesetting (VERDE 0x1002:0x683F 0x174B:0xE231 0x00).

lsmod snippet:

amdgpu               1507328  23
i2c_algo_bit           16384  2 amdgpu,radeon
drm_kms_helper        126976  2 amdgpu,radeon
ttm                    86016  2 amdgpu,radeon
drm                   299008  9 amdgpu,radeon,ttm,drm_kms_helper

All that said, if you are using the amdgpu module for kms, you also need to load the kms early mode-setting hook. Get that from the AUR. AFAIK that module is not going to load properly without the hook also enabled, but like I said, that's with the vanilla kernel. I have no experience with amd-staging, but from what I've read I probably won't switch because of the precarious drivers and modules and AMD firmware/software I use with the gallium and wine staging stuff I also run for mesa and opengl. I've gotten every single Wine and Steam (native or wine) game installed and working perfectly with native d3d gallium, FWIW. The open source and vanilla kernel are solid gaming choices for GCN 1 or 2 radeon cards, if that's what you have. That's my three cents.

Edit: Correction: I use the 'amdgpu' module in my mkinitcpio.conf NOT the 'radeon' module. "kms" hook is there as noted.

Last edited by nannerpussy (2017-06-17 14:08:36)

skeevy420 · 2017-06-17 14:39:18

nannerpussy wrote:

I just recently finished a long stretch of messing and experimenting with AMDGPU and radeon (radeonsi) drivers, specifically to get early KMS setup on my wonky AMD board and GCN 1.0 mATX-profile Radeon 7750 Sapphire card. AFAIK the CIK kernel is deprecated, those AMDGPU flags are stock since ~3.9 (?) or so. So definitely don't use the specific -cik AUR package, regardless of your card. If your card is a couple years old like mine, I'm having success right now with the standard vanilla kernel, using both AMDGPU and radeon (radeonsi) drivers. I use the "radeon" "amdgpu" module with initcpio, with the "kms" hook for early mode-setting. ~~Oddly, amdgpu takes control and the kms sets in early and without error, without the amdgpu module specifically listed.~~ I am honestly not well-versed with all of this AMDGPU stuff like most others here are though. But:
  1.066979] [drm] amdgpu kernel modesetting enabled.
[    1.067789] checking generic (c0000000 300000) vs hw (c0000000 10000000)
[    1.067790] fb: switching to amdgpudrmfb from EFI VGA
[    1.067812] Console: switching to colour dummy device 80x25
[    1.068114] [drm] initializing kernel modesetting (VERDE 0x1002:0x683F 0x174B:0xE231 0x00).

lsmod snippet:

amdgpu               1507328  23
i2c_algo_bit           16384  2 amdgpu,radeon
drm_kms_helper        126976  2 amdgpu,radeon
ttm                    86016  2 amdgpu,radeon
drm                   299008  9 amdgpu,radeon,ttm,drm_kms_helper
All that said, if you are using the amdgpu module for kms, you also need to load the kms early mode-setting hook. Get that from the AUR. AFAIK that module is not going to load properly without the hook also enabled, but like I said, that's with the vanilla kernel. I have no experience with amd-staging, but from what I've read I probably won't switch because of the precarious drivers and modules and AMD firmware/software I use with the gallium and wine staging stuff I also run for mesa and opengl. I've gotten every single Wine and Steam (native or wine) game installed and working perfectly with native d3d gallium, FWIW. The open source and vanilla kernel are solid gaming choices for GCN 1 or 2 radeon cards, if that's what you have. That's my three cents.
Edit: Correction: I use the 'amdgpu' module in my mkinitcpio.conf NOT the 'radeon' module. "kms" hook is there as noted.

I've never actually used the CIK kernel from the AUR. I was manually patching Arch kernels with CIK for a good while before there was even a CIK kernel in the AUR and I switched back to the standard Arch kernels when it was enabled by default (i iz sad aboot abs). Currently, amd-staging-git is the only AUR kernel I'm using and amd-staging the only non-official Arch kernel. Figured I'd give the AUR version a shot since it was updated for 4.11, but it has the same issues the mesa-git repo version does with my card. And mine is a GCN 2 card. It's worked like a champ from day 1, radeon and amdgpu.

I'll have to give the KMS tip a try. There's so much information to read it's easy to miss stuff. Thanks.

gee · 2017-06-17 16:51:14

There's been a bad commit for me on SI about a week ago, and there's been a similar commit for CIK at the same time.
Maybe that is your issue?

Try building on this commit and see if it works for you:
https://cgit.freedesktop.org/~agd5f/lin … e92027b72e

It works for me.

raneon · 2017-06-26 20:34:09

I have a strange issue with my RX480... since the update of mesa-git on 24th June Tomb Raider shows only pink/purple colours in the start menu and in the game. Can anyone else confirm this issue?

I thought maybe it is related to shader cache. I tried to delete .cache/mesa but it didn't help. Any idea?

lordheavy · 2017-06-27 05:39:05

raneon wrote:

I have a strange issue with my RX480... since the update of mesa-git on 24th June Tomb Raider shows only pink/purple colours in the start menu and in the game. Can anyone else confirm this issue?
I thought maybe it is related to shader cache. I tried to delete .cache/mesa but it didn't help. Any idea?

Yes, same here with Bioshock Infinite and Borderlands 2

lordheavy · 2017-06-28 13:56:02

raneon wrote:

I have a strange issue with my RX480... since the update of mesa-git on 24th June Tomb Raider shows only pink/purple colours in the start menu and in the game. Can anyone else confirm this issue?
I thought maybe it is related to shader cache. I tried to delete .cache/mesa but it didn't help. Any idea?

...and now the bug is fixed with latest llvm-svn, see https://bugs.freedesktop.org/show_bug.cgi?id=101561

gee · 2017-07-05 02:47:55

@lordheavy is there anyway to install and use at the same time 2 different versions of LLVM?

I'd like to stay on llvm-svn for mesa, but RPCS3 needs llvm 4.0 ....

lordheavy · 2017-07-05 14:45:41

gee wrote:

@lordheavy is there anyway to install and use at the same time 2 different versions of LLVM?
I'd like to stay on llvm-svn for mesa, but RPCS3 needs llvm 4.0 ....

You can install both llvm-libs and llvm-libs-svn but not llvm and llvm-svn. You only need llvm to build RPCS3, it's not a runtime dependency.
So if you want to keep llvm-svn (for opencl as an example) you must build RPCS3 in a chroot to avoid a conflict.

gee · 2017-07-06 00:16:22

I see, thank you!

bernd_b · 2017-07-10 16:00:16

I am using a msi C847MS-E33 board with its builtin Intel® Celeron 847 including the HD2000 Intel graphic for video playback.

From update to update I came from "whow this works pretty well" to "this is unusable".

Things got worser or in between they were running again. Sometimes it helped to deinstall xf86-video-intel, sometimes not.

What I experience is a shuttering in video playback or a hang of the system meaning frozen picture and sound for around 2-3 seconds, than it continues for about a minute and so on. Every player seems to be affected in the same way, although I think to remember kodi to be sometimes the last ressort, but I cannot reproduce this at the moment. In windowed mode, things could be overseen, but the bigger the window, the clearer the problems, in Fullscreen, you don't want to watch anything this way.

What I have now:
I have an archlinux with a working playback saved on one installation medium
and
an update of yesterday of this installation on another medium.

So, now I have a working (older) archlinux regarding playback on this pc and a non working current state. I wonder if the software discussed here could be the culprit, so I want to ask if this would make sense to someone. I give the versions used:

working playback:

local/mesa 17.0.1-1
local/mesa-libgl 17.0.1-1
local/llvm-libs 3.9.1-2

current state - playback problems

local/mesa 17.1.4-1
local/llvm-libs 4.0.1-1

Could these updates make the differences? Or do I have to search elsewhere?

Last edited by bernd_b (2017-07-10 16:00:55)

Lone_Wolf · 2017-07-11 11:14:30

Apart from mesa, the kernel also has a big impact on graphics.
Are the kernel versions the same ?

The switch to libglvnd might be related, try the current installation with mesa-noglvnd from AUR .

bernd_b · 2017-07-13 15:46:25

No luck.
I installed

pacman -Qs noglvnd
local/mesa-libgl-noglvnd 17.1.4-1
 local/mesa-noglvnd 17.1.4-1
 local/opencl-mesa-noglvnd 17.1.4-1
  local/vulkan-intel-noglvnd 17.1.4-1

and then I downgraded to kernel

linux 4.9.11-1

Each step made no difference. Maybe I do another mistake and overlook something.

raneon · 2017-07-15 09:41:34

SDDM doesn't start with the latest mesa-git builds on my RX480 and I need to go back to mesa-git-93794.

nicman23 · 2017-07-18 15:06:48

same but i went to mesa-git-93730.a2b02c4948

gpu amd 7700m

lordheavy · 2017-07-18 15:59:27

I can confirm that mesa-git-92996.65d1e4d1eb-1 works fine, so i will see to bisect the problem then file a bug report upstream

After some testing, sddm was working with 93822, but fails since 93905

Last edited by lordheavy (2017-07-18 16:33:07)

lordheavy · 2017-07-18 23:10:00

I've bisected and file an upstream bug:
https://bugs.freedesktop.org/show_bug.cgi?id=101832

lordheavy · 2017-07-19 16:46:50

I pushed a new mesa-git version that workaround sddm segfault: i've disabled swr support

raneon · 2017-07-20 07:56:57

Great, now SDDM works again! Thank you for tracking this down and for providing this fix :-)

nicman23 · 2017-07-20 11:34:45

why does a sw rasteriser even start if there is a gpu :confused:

Arch Linux

#101 2017-06-10 19:04:15

Re: mesa-git - latest videodrivers & issues

#102 2017-06-11 05:18:14

Re: mesa-git - latest videodrivers & issues

#103 2017-06-11 05:48:15

Re: mesa-git - latest videodrivers & issues

#104 2017-06-11 07:06:47

Re: mesa-git - latest videodrivers & issues

#105 2017-06-11 09:33:22

Re: mesa-git - latest videodrivers & issues

#106 2017-06-17 13:13:53

Re: mesa-git - latest videodrivers & issues

#107 2017-06-17 13:46:34

Re: mesa-git - latest videodrivers & issues

#108 2017-06-17 14:39:18

Re: mesa-git - latest videodrivers & issues

#109 2017-06-17 16:51:14

Re: mesa-git - latest videodrivers & issues

#110 2017-06-26 20:34:09

Re: mesa-git - latest videodrivers & issues

#111 2017-06-27 05:39:05

Re: mesa-git - latest videodrivers & issues

#112 2017-06-28 13:56:02

Re: mesa-git - latest videodrivers & issues

#113 2017-07-05 02:47:55

Re: mesa-git - latest videodrivers & issues

#114 2017-07-05 14:45:41

Re: mesa-git - latest videodrivers & issues

#115 2017-07-06 00:16:22

Re: mesa-git - latest videodrivers & issues

#116 2017-07-10 16:00:16

Re: mesa-git - latest videodrivers & issues

#117 2017-07-11 11:14:30

Re: mesa-git - latest videodrivers & issues

#118 2017-07-13 15:46:25

Re: mesa-git - latest videodrivers & issues

#119 2017-07-15 09:41:34

Re: mesa-git - latest videodrivers & issues

#120 2017-07-18 15:06:48

Re: mesa-git - latest videodrivers & issues

#121 2017-07-18 15:59:27

Re: mesa-git - latest videodrivers & issues

#122 2017-07-18 23:10:00

Re: mesa-git - latest videodrivers & issues

#123 2017-07-19 16:46:50

Re: mesa-git - latest videodrivers & issues

#124 2017-07-20 07:56:57

Re: mesa-git - latest videodrivers & issues

#125 2017-07-20 11:34:45

Re: mesa-git - latest videodrivers & issues

Board footer