11:27doras: In the world of atomic KMS, how are updates to individual planes expected to behave? For example, if two planes are submitted in a single atomic commit: the primary and the cursor plane, and the FB backing the primary plane has a significant rendering pipeline and is expected to miss the next vblank, while the cursor plane update can easily happen in the next vblank, will the cursor update also be delayed and miss the
11:31doras: And if the above is indeed the expected behavior, how can one allow the cursor plane update to happen regardless of the primary plane using the atomic API in such a scenario?
11:41vsyrjala: everything gets updated atomically, as the name suggests
11:42vsyrjala: the only way to get as unthrottled/unsynced cursor updates is via the legacy cursor ioctl
11:45doras: Is it possible to perform two atomic commits targeting the same vblank to get this behavior?
11:49vsyrjala: not currently. there has been some discussion about such "mailbox" type stuff, but it's a bit tricky to shoehorn into the current atomic implementation
11:50doras: This question also applies to more complex scenarios involving overlay planes. For example, an overlay plane dedicated for presenting a video while heavier OpenGL-based rendering is done on the primary plane which cause it to would miss the next blank. One would want the video to play smoothly and never miss its vblank targets regardless of the primary plane.
11:51doras: which can cause it to miss*
11:53vsyrjala: i think atm you'd probalby need to wait for the fences in userland, and schedule the atomic commits only after the fences signalled
11:54doras: I guess explicit synchronization can be done by the compositor to make sure that every FB submitted for an atomic commit is "ready".
11:54doras: Yes, that :)
11:58doras: I was afraid that this would be the conclusion here. A lot of work seems to be required to allow the behavior which was previously possible using the legacy API fairly easily, at least for the cursor plane case.
12:01vsyrjala: cursor was the only thing that allowed it using the leagcy api. and the implementation of that is a hack that mostly works by luck (at least in the case of i915)
12:21doras: Perhaps introducing some synchronization/dependency definition between planes along with a new flag on the atomic commit itself to take those into consideration could allow something like this to work without having to explicitly wait on signals in user space.
12:28doras: Actually, it seems that there's already some fencing capability related to planes, but I'm not sure if it's enough to accomplish this.
15:07feaneron: karolherbst: uh, sorry for the back and forth with the function name
16:51ric96: karolherbst: Is this something you recognise?
16:51ric96: I'm getting this on the jetson nano, running fedora 33 running glmark2 on xterm directly, no gnome3 involved.
16:51ric96: [ 1275.766191] nouveau 57000000.gpu: gr: DATA_ERROR 00000003 [INVALID_OPERATION] ch 4 [0400323000 glmark2] subc 0 class b197 mthd 19d0 data 0000003d
16:53karolherbst: ric96: I think that's the error you get if you don't have modifier aware compositors
16:53karolherbst: so you need xorg-1.21 and I think a semi recent kernel
17:16ric96: karolherbst: gotcha, f33 seems to have 1.20, I'll update and try
17:16karolherbst: ric96: that won't really help
17:17karolherbst: what you could do is to use my copr: https://copr.fedorainfracloud.org/coprs/karolherbst/tegra_testing/ and just use mutter as a wayland compositor. That's the closes you should get to something working out of the box
17:17karolherbst: eh.. the f33 build failed.. f32 is fine though
17:21ric96: Cool, looks like then its the same solution to the gnome3 patch for mutter.
17:21ric96: I was wondering if plain xorg based setup was going to work.
17:21ric96: I'll try that copr, although f32 requires some patch boot on Jetson nano so I haven't even tried that.
17:22karolherbst: ric96: in theory 1.21 should work out of the box
17:23karolherbst: but nothing packages it afaik
17:24ric96: I'll build