search

swaywm / sway

i3-compatible Wayland compositor
https://swaywm.org
MIT License
14.69k stars 1.11k forks source link

No hardware accelection after commit 7e69a70 #7897

Closed Billli11 closed 9 months ago

Billli11 commented 10 months ago

Please fill out the following:

emersion commented 10 months ago

This is a Mesa bug.

ppascher commented 10 months ago

Steam does not start either with this commit (black splash screen after "loading user data"). Reverting the mentioned commit fixes it. Is there an open issue for this with mesa already? Was this introduced recently or did it just work until now because wlroots and sway used wl_drm instead of liunx-dmabuf? I do not really understand what the issue is and what to look for.

emersion commented 10 months ago

Hm, actually might be an Xwayland bug.

pablo-888 commented 10 months ago

Just tested this on River since they too dropped wl_drm recently and have the exact same problem (intel iGPU). With mesa-amber I get softpipe renderer and with normal mesa (crocus) I get llvmpipe. (no xwayland involved).

slonkazoid commented 10 months ago

getting this on sway 1.9-dev-7e69a7076 as well, reverting the commit fixed it

slonkazoid commented 10 months ago

Hm, actually might be an Xwayland bug.

both vainfo and gamescope nested mode don't work so might not be the case

RobertMueller2 commented 10 months ago

As an end user without a clue about graphics stacks and wayland protocols, I just heard about linux-dmabuf superseding wl_drm for the first time. I understand that considerable work has gone into this, and clients need to catch up.

If the developers of these clients didn't make them catch up yet, it's obviously their responsibility. But I'll say this: as an end user I also need a fighting chance. At the very least, that would be a transition period where a big red warning is displayed in a log when I start these clients, so I can at least poke the developers in advance. Rather than letting the clients break and leaving me puzzled for an hour. I cannot run full regression tests of everything after applying a change to my systems, sometimes I discover breakages a lot later and then it's tricky to immediately point at the software that caused it, let alone a specific commit.

I think it might be too early to pull the rug. I assume that wlroots would be the place where a runtime warning has to be placed. If I can help with that with minimal C skills, I'm happy to.

So unless I'm wrong about all this and missed an existing warning, my suggestion is to:

RobertMueller2 commented 10 months ago

Apparently, the logging situation is not as straight-forward as I thought. I added some error messages to wlroots (types/wlr_drm.c, drm_handle_authenticate and drm_handle_create_prime_buffer) and expected to see them when starting Steam, but that was not the case.

~So I suppose something else must be going on here, and the logging I asked for wouldn't have prevented anything.~

EDIT: I've found out now that the client (Xwayland in this case) gets the registry and binds "wl_drm". A possible logging place would therefore be types/wlr_drm.c in drm_bind.

I'll observe this for a bit and try and get a feeling for whether this could be useful as an addition to wlroots. I have no idea yet how to log a client specific identifier. If I decide to pursue this, I might try and get help via IRC in the next days.

hurricane-dorian commented 10 months ago

So unless I'm wrong about all this and missed an existing warning, my suggestion is to:

* revert [7e69a70](https://github.com/swaywm/sway/commit/7e69a7076fc8a4eb788e0229b1c99dd0b7b04bb7)

* add a warning to wlroots

* in a few months time, come back to [7e69a70](https://github.com/swaywm/sway/commit

If you are unwilling to test or at least put up with bugs then you should not be using a unreleased master-git build. In-fact the commit is not even a bug. As the wlroots commit states this was done intentionally so they can discover what breaks and yes the warning are there. In the meantime either go to the stable 1.8 release or revert the commit on your local branch. Please do be more respectful to the developers, they do care a lot about us, the clueless users even thou they owe us nothing!

RobertMueller2 commented 10 months ago

So unless I'm wrong about all this and missed an existing warning, my suggestion is to:

* revert [7e69a70](https://github.com/swaywm/sway/commit/7e69a7076fc8a4eb788e0229b1c99dd0b7b04bb7)

* add a warning to wlroots

* in a few months time, come back to [7e69a70](https://github.com/swaywm/sway/commit

If you are unwilling to test or at least put up with bugs then you should not be using a unreleased master-git build. In-fact the commit is not even a bug. As the wlroots commit states this was done intentionally so they can discover what breaks and yes the warning are there. In the meantime either go to the stable 1.8 release or revert the commit on your local branch. Please do be more respectful to the developers, they do care a lot about us, the clueless users even thou they owe us nothing!

Yes, it would be nice to just use stable, but then I can't report issues as they show up. That kinda requires ongoing usage as well. Of course moderate pain is expected when using bleeding edge software. I don't mind it.

This is about what I think could have been avoidable pain. I understand the approach, I just think there would have been a a more gentle way. I don't think it's disrespectful to voice that opinion and I didn't mean to be disrespectful.

But reading it again I can understand why it comes across that way. I should try and be less upset when writing such things. I apologise for the bad style.

emersion commented 10 months ago

https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1236 should help.

Billli11 commented 10 months ago

Tested with upstream sway and upsteam xwayland in nest mode. The bug seem to be fixed by applying the xserver!1236 to xwayland.

GreyXor commented 10 months ago

I confirm that https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1236 fix https://github.com/swaywm/sway/issues/7899

slonkazoid commented 10 months ago

vainfo still segfaults with 1236, unless you also revert 7e69a70, then it fails with unknown libva error

emersion commented 10 months ago

The libva segfault is fixed by https://github.com/intel/libva/pull/789, and the fact that libva doesn't use the GPU is fixed by https://github.com/intel/libva/pull/790.

Zenzi0 commented 10 months ago

Sorry to barge in with a short question: Are these commits in xwayland and libva already in if one installs the respective git versions? I'm not very familiar with these things and installing libva-git, xorg-xwayland-git, wlroots-git and sway-git doesn't make a difference in my case. Or am I right to assume that these commits aren't in yet?

emersion commented 10 months ago

None of the commits are merged yet.

Quackdoc commented 10 months ago

maybe worth nothing this also breaks amdvlk 2023-q3-3-1 for me

warning: queue 0x74c575c7c110 destroyed while proxies still attached:
  wl_registry@41 still attached
[vo/gpu-next/libplacebo] vk->GetPhysicalDeviceSurfaceCapabilitiesKHR(vk->physd, p->surf, &caps): VK_ERROR_UNKNOWN (../libplacebo/src/vulkan/swapchain.c:448)
warning: queue 0x74c575c8d0e0 destroyed while proxies still attached:
  wl_registry@42 still attached
[vo/gpu-next/libplacebo] vk->GetPhysicalDeviceSurfaceCapabilitiesKHR(vk->physd, p->surf, &caps): VK_ERROR_UNKNOWN (../libplacebo/src/vulkan/swapchain.c:448)
LaserEyess commented 10 months ago

If you are unwilling to test or at least put up with bugs then you should not be using a unreleased master-git build. In-fact the commit is not even a bug.

I agree with this argument in principle, but in this case the commit breaks functionality on an otherwise working system. The wlroots commit is just a deprecation, not a removal. I can revert the sway commit easily myself, but it seems like it's premature to drop wl_drm before the libva commits are in. I don't think I've seen someone ask: would reverting this commit on master be acceptable to sway devs? At least until libva master has those commits in?

Billli11 commented 10 months ago

Xwayland MR 1236 has been merged.
The 2 PR for libva (789, 790) are still not merged yet.

May be we allow setting drop/create wl_drm behind env , command option or build option?
Look like flatpak do not use system libva library. 

/var/lib/flatpak/runtime/org.gnome.Platform.Compat.i386/x86_64/45/e855ba3225addb0cd67ecf7838cf5665ed905cb1254355ec39071cf37f7dd3c0/files/libva-wayland.so.2.1900.0
emersion commented 10 months ago

See #7916 for an attempt at a middle ground.

bl4ckb0ne commented 9 months ago

Merged it, @Billli11 i let you close the issue if everything is good on your end

Billli11 commented 9 months ago

@bl4ckb0ne
-Dlegacy-wl-drm work. Have hardware acceleration with Xwayland version 23.2.4.
Without debug flag work with upsteam Xwayland.

vaapi need more testing.

Edit 1: With patched libva, everthing seem to be working fine except vlc with VA-API video decoder via DRM.

With stable libva version 2.20.0

With debug flag anything work.