ERROR jay::backends::metal::video] Could not present

[cwegener]

This is on a PRIME system (Asus Zephyrus G14 2023) with the NVidia dGPU set to always enabled in BIOS.
Driver is latest nvidia-open

Log attached.
jay-2024-04-10T04:46:17.149Z-0.txt

[mahkoh]

Does journalctl have any related logs?

What is the output of lsmod?

Does sway work on the same system? If so, please post sway logs.

[cwegener]

Does journalctl have any related logs?

I haven't seen anything suspicious, but I'll keep looking.

What is the output of lsmod?

Attached.
lsmod.txt

Does sway work on the same system? If so, please post sway logs.

Yes it does (stable release .. no explicit sync yet). Debug log attached.

Launched with env WLR_NO_HARDWARE_CURSORS=1 XDG_CURRENT_DESKTOP=wlr sway --unsupported-gpu --debug

sway.log

[mahkoh]

Unfortunately the sway logs are a bit bare. In that case it might be easiest to enable KMS debug logging.

Be warned that this will create very verbose logs.

Step 1: Enable logging: echo 0x19F | sudo tee /sys/module/drm/parameters/debug
Step 2: Switch to a different VT, start jay, wait for a few seconds, exit jay.
Step 3: Disable logging: echo 0x0 | sudo tee /sys/module/drm/parameters/debug

journalctl should then contain logs describing in detail why the operation fails. You can use journalctl --since <time> > logs to dump these logs to a file. Where <time> should be shortly before you started jay.

[cwegener]

The effect of the 'Could not present' is mainly noticeable in these terminal emulators:

• foot
• alacritty
• rio

Due to the fact that a missed present actually is immediately noticeable as a missing character or the terminal screen output being 'one stroke behind'.

Firefox renderer works just fine.

I think that GTK (i.e. Firefox menu bar) is also impacted by the 'Could not present' error. I.e. when I click the menu bar, the menus don't open. But the 'hamburger' menu in Firefox (which is not GTK?) works without issues.

[mahkoh]

The effect of the 'Could not present' is mainly noticeable in these terminal emulators:

Huh, I was assuming that you got no output at all. If you do get output, then this might be just a case of presentation on some (?) outputs not working but working on the main ones. This might be related to PRIME as you said.

The logs will probably give us the definitive answer but could you also post the output of jay randr?

[cwegener]

In that case it might be easiest to enable KMS debug logging.

TZ=UTC sudo journalctl -S 2024-04-10T08:17 -k -o short-iso-precise > dmesg.txt

dmesg.txt

[cwegener]

could you also post the output of jay randr?

jayrandr.txt

[cwegener]

Huh, I was assuming that you got no output at all. If you do get output, then this might be just a case of presentation on some (?) outputs not working but working on the main ones. This might be related to PRIME as you said.

In addition to only using the internal display, I now have also tested the HDMI port (and disabled eDP-1 with jay randr output eDP-1 disable). On the HDMI display, the issue still persists.

I suspect using only the external DP-1 port might produce similar results.

[mahkoh]

I think this is https://invent.kde.org/plasma/kwin/-/merge_requests/4770. The Operation not permitted (os error 1) is a red herring. Nvidia just always returns -1 in this case instead of a proper error code.

I'll try to create a patch that disables IN_FENCE_FD if nvidia is being used. But then I'm not sure how explicit sync is supposed to work on nvidia since we have no way to synchronize presentation with rendering.

[mahkoh]

Please test #160

[cwegener]

From Xaver:

I already contacted NVidia about this and will follow up with them as needed.

https://bugs.kde.org/show_bug.cgi?id=478246#c9

I can't recall this topic being discussed anywhere else.

Do you think I should be able to observe the symptoms (i.e. output lagging behind the keystrokes in terminal emulator) when using wlroots explicit sync patch? Or does this comment mean I wouldn't notice the issue in wlroots?

Joshua Ashton
You are passing that to the eventfd though too?

Is wlroots still doing gpu side buffer latching and stalling itself...

Simon Ser
Yes, this patch is not supposed to change the how the frame scheduling works. It just adds explicit sync without behavioral changes.

https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4262#note_2353397

[cwegener]

Please test #160

I'm away from the test machine. I'll be back in front of it and test it in 12 hours (Wed 21:00 UTC)

[mahkoh]

Do you think I should be able to observe the symptoms (i.e. output lagging behind the keystrokes in terminal emulator) when using wlroots explicit sync patch?

There are several issues here:

1. There are no nvidia drivers that support explicit sync. Nvidia has said that drivers 555 (for X applications) and 560 (for wayland applications) will support explicit sync.
2. The nvidia driver does not support the IN_FENCE_FD property. This causes the commits to fail.
3. For some reason, you're still seeing output. This indicates a serious bug in the nvidia driver. I think the only way that this is possible is for the nvidia driver to partially apply commits. I wouldn't bother debugging this further until nvidia has fixed this issue in their driver.

As far as I know, support for explicit sync in wlroots and sway is incomplete.

Or does this comment mean I wouldn't notice the issue in wlroots?

That comment is unrelated.

[mahkoh]

For some reason, you're still seeing output. This indicates a serious bug in the nvidia driver. I think the only way that this is possible is for the nvidia driver to partially apply commits. I wouldn't bother debugging this further until nvidia has fixed this issue in their driver.

That might have been a bug in Jay that should also be fixed in the PR.

[cwegener]

Please test #160

That patch works for me.

Error messages are gone.

And the symptoms have disappeared.

[mahkoh]

I've released 1.0.3 with these changes.