OpenGL/Vulkan clients hang on FreeBSD

[jbeich]

Regressed by #9807. Non-accelerated clients (e.g., foot, wlroots/pixman) aren't affected.

Hyprland itself starts and seems to use OpenGL rendering fine but any OpenGL clients hang almost immediately. At least in Alacritty it's possible to type 1 or 2 letters before ANR dialog appears. However, ANR dialog itself isn't responsive because Qt6 uses OpenGL rendering by default.

See debug log

[vaxerski]

@ikalco as regressor. My guess would be some syncobj op fails and thus we never release the buffer (or signal with explicit)

[vaxerski]

if we want to push this further, does it still happen if you set render:explicit_sync to false?

[jbeich]

Sorry for the long wait. render:explicit_sync=false didn't help on v0.49.0 and v0.49.0-105-ge999ad664 snapshot. #9807 seems to have removed the fallback unless I'm reading the code wrong.

[vaxerski]

ah, right. Well, generally I don't see anything suspicious there in that MR - maybe BSD has some quirks wrt. duplicating sync fds?

[ikalco]

try patch.txt

[jbeich]

With your patch Vulkan apps run fine but OpenGL apps still hang.

[gulafaran]

@ikalco actually even vkcube --wsi wayland on linux is broken

[gulafaran]

@ikalco actually even vulkan --wsi wayland on linux is broken

not related, went back to WAY back before all bufferings 8 months ago. still broken, lol so something else have recently broke vkcube

[tekstryder]

vkcube --wsi wayland on linux is broken

OT, but this isn't strictly true.

Works fine at native display resolution on Hyprland with both nVidia and Nouveau drivers.

 vkcube --wsi wayland --width 3840 --height 2160

Other resolutions, including the default, don't render.

But vkcube doesn't crash, and Esc still exits cleanly.

[tekstryder]

Further, with a simple window rule...

windowrulev2 = float, $title:^(vkcube)$

...vkcube works at all available resolutions, including default.

or with..

hyprctl dispatch exec [floating] vkcube

However, when launched in a tiled window it gets angry:

$ VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation vkcube
Selected WSI platform: wayland
Selected GPU 0: NVIDIA GeForce GTX 1050 Ti, type: DiscreteGpu
Validation Error: [ VUID-VkRenderPassBeginInfo-pNext-02852 ] | MessageID = 0xdb2c5767
vkCmdBeginRenderPass(): pRenderPassBegin->renderArea offset.x (0) + extent.width (1440) is greater than framebuffer width (500).
The Vulkan spec states: If the pNext chain does not contain VkDeviceGroupRenderPassBeginInfo or its deviceRenderAreaCount member is equal to 0, renderArea.offset.x + renderArea.extent.width must be less than or equal to VkFramebufferCreateInfo::width the framebuffer was created with (https://docs.vulkan.org/spec/latest/chapters/renderpass.html#VUID-VkRenderPassBeginInfo-pNext-02852)
Objects: 2
    [0] VkRenderPass 0xd000000000d
    [1] VkFramebuffer 0x270000000027

Validation Error: [ VUID-VkRenderPassBeginInfo-pNext-02853 ] | MessageID = 0x1bd44466
vkCmdBeginRenderPass(): pRenderPassBegin->renderArea offset.y (0) + extent.height (1620) is greater than framebuffer height (500).
The Vulkan spec states: If the pNext chain does not contain VkDeviceGroupRenderPassBeginInfo or its deviceRenderAreaCount member is equal to 0, renderArea.offset.y + renderArea.extent.height must be less than or equal to VkFramebufferCreateInfo::height the framebuffer was created with (https://docs.vulkan.org/spec/latest/chapters/renderpass.html#VUID-VkRenderPassBeginInfo-pNext-02853)
Objects: 2
    [0] VkRenderPass 0xd000000000d
    [1] VkFramebuffer 0x270000000027

[tagattie]

I tried to dig into this issue a bit.

I have applied a small patch (attached to this message) to the source at commit 2ee5118 and followed the value of nLocks (of class IHLBuffer).

• In case of foot (non-accelerated client), the value of nLocks is around 0 or 1. (hyprland-foot.log)
• On the other hand, in case of alacritty, the value keeps increasing, which I don't think should be the case. (hyprland-alacritty.log)

I guess this is relevant to the hang of alacritty but I don't know why nLocks increases.

Do you have any ideas why? It would be greatly appreciated it if you share how I can help debug this issue.

patch.txt
hyprland-foot.log
hyprland-alacritty.log

[tagattie]

I did some research on exlicit sync on FreeBSD and found the following URLs. It appears an ioctl (DRM_IOCTL_SYNCOBJ_EVENTFD) required for supporting explicit sync is missing on FreeBSD. So currently disabling explicit sync seems the only solution for FreeBSD...

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286311#c3
freebsd/drm-kmod#278
https://github.com/freebsd/drm-kmod/blob/drm_v6.6.25_5/drivers/gpu/drm/drm_ioctl.c#L718-L722

[vaxerski]

bop, and we found the culprit.
patch.txt

this patch should disable explicit sync at compile time for anything non-linux.

[tagattie]

With the patch, I can pleasantly use any accelerated and non-accelerated clients. Thanks a lot for all the efforts and time you have put into this!! 🎉

[vaxerski]

I'll commit it to main, I don't think it will hurt.

[vaxerski]

I've committed the patch, cheers. Thanks for testing.