Open ruineka opened 1 year ago
I managed to get a little more information after several attempts of tinkering.
lserver: [xwayland/server.c:108] Starting Xwayland on :0
wlserver: [xwayland/server.c:108] Starting Xwayland on :1
wlserver: [types/wlr_compositor.c:673] New wlr_surface 0x55ed237a6900 (res 0x55ed238f1030)
wlserver: [xwayland/server.c:273] Xserver is ready
wlserver: [types/wlr_compositor.c:673] New wlr_surface 0x55ed23628c60 (res 0x55ed238e7250)
wlserver: [xwayland/server.c:273] Xserver is ready
pipewire: stream state changed: connecting
pipewire: stream state changed: paused
pipewire: stream available on node ID: 76
wlserver: Updating mode for xwayland server #0: 3840x2160@120
pipewire: renegotiating stream params (size: 3840x2160)
wlserver: [types/wlr_compositor.c:673] New wlr_surface 0x55ed23601af0 (res 0x55ed238ac640)
xwm: Rejecting WM_CHANGE_STATE to ICONIC for window 0x400007
radv: Updated the per-vertex VRS rate to '0'.
xwm: error 3: BadWindow (invalid Window parameter) request 20 minor 0 serial 2435
xwm: error 3: BadWindow (invalid Window parameter) request 20 minor 0 serial 2436
wlserver: [types/wlr_compositor.c:673] New wlr_surface 0x55ed2398f0d0 (res 0x55ed239264a0)
Using a session it still fails (black screen with mangohud/mangoapp rendering), but I can get gamescope -- steam
to render from the desktop.
It would appear that mesa 23.0.0 introduces a problem similar to what I've reported here for Intel https://github.com/Plagman/gamescope/issues/803
If you use -w 1920 -h 1080
you can get gamescope to work. With the older mesa this wasn't necessary.
So this makes replicating the problem more difficult because if you don't have a 4k 120hz TV like I do you might not run into this issue.
I finally got around to bisecting the commit that causes this issue..
00da41e6c930e08e2de0c683c0be6393c03db647 is the first bad commit
commit 00da41e6c930e08e2de0c683c0be6393c03db647
Author: Marek Olšák <marek.olsak@amd.com>
Date: Thu Feb 2 18:21:39 2023 -0500
Revert "radeonsi: enable glthread by default"
This reverts commit d6fabe49cd72fb7f7087b12efd8a9e3371e36c01.
It has issues that are not worth fixing in this release branch in my opinion.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21087>
src/amd/ci/radeonsi-raven-fails.txt | 1 -
src/gallium/drivers/radeonsi/driinfo_radeonsi.h | 1 -
2 files changed, 2 deletions(-)```
I am not able to reproduce on 7900xtx on latest Mesa git.
I am not able to reproduce on 7900xtx on latest Mesa git.
I've done more testing and after shipping ChimeraOS v40 a lot of users systems broke and using mesa_glthread=true
fixes the issue. After bisecting I came to this commit that causes the regression. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21087#note_1847898
To summarize a lot of reports came in that 4K resolutions in particular were a problem and in some instances using steam resolution scaling instead of manually selecting the resolution in the gamepadui worked.
A side note os that by using mesa_glthread=true
fixes the issues I was having with Intel as well that I reported here https://github.com/ValveSoftware/gamescope/issues/803
@Joshua-Ashton I wonder if adding this to 00-mesa-defaults.conf would be the proper fix. Especially since this causes issues for Intel as well as AMD. We had many users of ChimeraOS who ran into issues when they were hooked up to 1440p/2160p displays with mesa_glthread=false
being the new default for radeonsi. I expect that this would be the same situation Valve would run into with SteamOS if they pull the upstream changes to their repo without patching mesa.
<application name="Gamescope" executable="gamescope">
<option name="mesa_glthread" value="true" />
</application>
https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/util/00-mesa-defaults.conf
I'll be reporting this over at the gitlabs as well, but mesa 23.0.0 breaks gamescope on a 6900 XT regardless if it's nested or not. When attempting to run from a TTY the screen loses signal entirely and if you try it from the desktop there will be no output.
Simply update to 23.0.0 and attempt to run
gamescope -- vkcube
to replicate the issue. It works fine on a 5800U handheld, so APUs or non RDNA2 devices might not be effected.There aren't any useful logs to provide unfortunately because the stdout looks normal and I'm not seeing anything out of the ordinary. Reverting back to mesa 22.3.4 makes gamescope work again.
Mesa gitlab issue: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8361