No hardware accelection after commit 7e69a70

[Billli11]

Please fill out the following:

• Sway Version:

  • swaymsg -t get_version or sway -v
    sway version 1.9-dev-7e69a707 (Jan 4 2024, branch 'master')

• Debug Log:
  7e69a70. not working
  fa294a9. working
  https://gist.github.com/Billli11/04d8ccc0f9823002d4db78933613ce75

• Configuration File:
  Default configuration file

• Stack Trace:
  N/A

• Description:
  With commit 7e69a70. Vulkan application no longer run and opengl application run in software mode

  • vkcube:

  Selected GPU 0: AMD Radeon RX 7800 XT (RADV NAVI32), type: DiscreteGpu
  vulkan: No DRI3 support detected - required for presentation
  Note: you can probably enable DRI3 in your Xorg config
  vulkan: No DRI3 support detected - required for presentation
  Note: you can probably enable DRI3 in your Xorg config
  vulkan: No DRI3 support detected - required for presentation
  Note: you can probably enable DRI3 in your Xorg config
  vulkan: No DRI3 support detected - required for presentation
  Note: you can probably enable DRI3 in your Xorg config
  Could not find both graphics and present queues
  

  • glxgears -info

  DRI3 not available
  failed to load driver: zink
  GL_RENDERER   = llvmpipe (LLVM 16.0.6, 256 bits)
  GL_VERSION    = 4.5 (Compatibility Profile) Mesa 24.0.0-devel (git-b8e06fa48a)
  GL_VENDOR     = Mesa
  GL_EXTENSIONS = GL_ARB_multisample GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_copy_texture GL_EXT_subtexture GL_EXT_texture_object GL_EXT_vertex_array GL_EXT_compiled_vertex_array GL_EXT_texture GL_EXT_texture3D GL_IBM_rasterpos_clip GL_ARB_point_parameters GL_EXT_draw_range_elements GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_separate_specular_color GL_EXT_texture_edge_clamp GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_ARB_framebuffer_sRGB GL_ARB_multitexture GL_EXT_framebuffer_sRGB GL_IBM_multimode_draw_arrays GL_IBM_texture_mirrored_repeat GL_3DFX_texture_compression_FXT1 GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_transpose_matrix GL_EXT_blend_func_separate GL_EXT_fog_coord GL_EXT_multi_draw_arrays GL_EXT_secondary_color GL_EXT_texture_env_add GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_INGR_blend_func_separate GL_NV_blend_square GL_NV_light_max_exponent GL_NV_texgen_reflection GL_NV_texture_env_combine4 GL_S3_s3tc GL_SUN_multi_draw_arrays GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_EXT_framebuffer_object GL_EXT_texture_compression_s3tc GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_MESA_window_pos GL_NV_packed_depth_stencil GL_NV_texture_rectangle GL_ARB_depth_texture GL_ARB_occlusion_query GL_ARB_shadow GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_window_pos GL_ATI_fragment_shader GL_EXT_stencil_two_side GL_EXT_texture_cube_map GL_NV_copy_depth_to_color GL_NV_depth_clamp GL_NV_fog_distance GL_NV_half_float GL_APPLE_packed_pixels GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_shader GL_ARB_shader_objects GL_ARB_vertex_program GL_ARB_vertex_shader GL_ATI_draw_buffers GL_ATI_texture_env_combine3 GL_ATI_texture_float GL_EXT_shadow_funcs GL_EXT_stencil_wrap GL_MESA_pack_invert GL_MESA_ycbcr_texture GL_NV_primitive_restart GL_ARB_depth_clamp GL_ARB_fragment_program_shadow GL_ARB_half_float_pixel GL_ARB_occlusion_query2 GL_ARB_point_sprite GL_ARB_shading_language_100 GL_ARB_sync GL_ARB_texture_non_power_of_two GL_ARB_vertex_buffer_object GL_ATI_blend_equation_separate GL_EXT_blend_equation_separate GL_OES_read_format GL_ARB_color_buffer_float GL_ARB_pixel_buffer_object GL_ARB_texture_compression_rgtc GL_ARB_texture_float GL_ARB_texture_rectangle GL_ATI_texture_compression_3dc GL_EXT_packed_float GL_EXT_pixel_buffer_object GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_rgtc GL_EXT_texture_mirror_clamp GL_EXT_texture_rectangle GL_EXT_texture_sRGB GL_EXT_texture_shared_exponent GL_ARB_framebuffer_object GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_packed_depth_stencil GL_ARB_vertex_array_object GL_ATI_separate_stencil GL_ATI_texture_mirror_once GL_EXT_draw_buffers2 GL_EXT_draw_instanced GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_texture_array GL_EXT_texture_compression_latc GL_EXT_texture_integer GL_EXT_texture_sRGB_decode GL_EXT_timer_query GL_OES_EGL_image GL_EXT_texture_buffer_object GL_AMD_texture_texture4 GL_ARB_copy_buffer GL_ARB_depth_buffer_float GL_ARB_draw_instanced GL_ARB_half_float_vertex GL_ARB_instanced_arrays GL_ARB_map_buffer_range GL_ARB_texture_buffer_object GL_ARB_texture_rg GL_ARB_texture_swizzle GL_ARB_vertex_array_bgra GL_EXT_texture_swizzle GL_EXT_vertex_array_bgra GL_NV_conditional_render GL_AMD_conservative_depth GL_AMD_draw_buffers_blend GL_AMD_seamless_cubemap_per_texture GL_AMD_shader_stencil_export GL_ARB_ES2_compatibility GL_ARB_blend_func_extended GL_ARB_compatibility GL_ARB_debug_output GL_ARB_draw_buffers_blend GL_ARB_draw_elements_base_vertex GL_ARB_explicit_attrib_location GL_ARB_fragment_coord_conventions GL_ARB_provoking_vertex GL_ARB_sample_shading GL_ARB_sampler_objects GL_ARB_seamless_cube_map GL_ARB_shader_stencil_export GL_ARB_shad
  

[emersion]

This is a Mesa bug.

[ppascher]

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]

Hm, actually might be an Xwayland bug.

[pablo-888]

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]

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

[slonkazoid]

Hm, actually might be an Xwayland bug.

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

[RobertMueller2]

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:

• revert 7e69a70
• add a warning to wlroots
• in a few months time, come back to 7e69a70

[RobertMueller2]

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]

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]

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]

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

[Billli11]

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

[GreyXor]

I confirm that https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1236 fix #7899

[slonkazoid]

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

[emersion]

The libva segfault is fixed by intel/libva#789, and the fact that libva doesn't use the GPU is fixed by intel/libva#790.

[Zenzi0]

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]

None of the commits are merged yet.

[Quackdoc]

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]

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]

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]

See #7916 for an attempt at a middle ground.

[bl4ckb0ne]

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

[Billli11]

@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

• no debug flag
• • vainfo: seg fault
• • mpv:
• • • hwdec=vaapi: seg fault
• • • hwdec=vaapi-copy: working
• • vlc:(with upsteam Xwayland)
• • • VA-API video decoder via DRM: no hw decoding (This also do not work with libva patch)
• • • VA-API video decoder: working
• • vlc flatpak: (with upsteam Xwayland)
• • • VA-API video decoder via DRM: no hw decoding (This also do not work with libva patch)
• • • VA-API video decoder: working

With debug flag anything work.