07:20 <MrCooper> dottedmag pq: note that the degradation to half frame rate can happen with bare metal as well, if the GPU doesn't finish in time, in this case it just happens due to the mis-aligned compositor repaint cycles instead; if the guest compositor cycle could be synchronized to the host one, full frame rate could be sustained with lower latency than with a queue of flips to work around the mis-aligned cycles

08:22 <pq> MrCooper, of course.

08:23 <pq> MrCooper, right now, that synchronization is possible with using Weston on both sides and manually tuning repaint-window.

08:25 <pq> It's funny. Previously we have had the opposite problem with virtual KMS drivers, completing page flips ASAP without a fixed refresh cycle at all.

08:25 <pq> that is, completing much earlier that with bare metal

08:26 <pq> *than

10:33 <dottedmag> MrCooper: realtime scheduler for GPU is needed? :)

10:34 <dottedmag> There is some discussion in academic papers about this, related to cards and other environments where hard realtime is, well, quite desired.

10:35 <dottedmag> As a side note, "RT GPU" and "realtime GPU" search results are awash in "ray tracing" and "not-compile-time" noise.

10:40 <pq> dottedmag, I don't think we even talked that far. Being able to reschedule doesn't help if the compositor job depends on another job anyway.

11:58 <ishitatsuyuki> gpu schedulers are kinda enough in their current state

11:58 <ishitatsuyuki> you can preempt for the highest priority tasks

11:59 <ishitatsuyuki> beside that the scheduler is pretty limited (and it's pretty much won't be fair due to how the hardware is designed), but I think it's good enough for today's workload

12:16 <MrCooper> dottedmag: with the caveat mentioned by pq, current GPUs already have everything needed for the compositor's drawing to preempt that of clients (though it's not plumbed through for AMD GPUs yet)

12:18 <MrCooper> on my work laptop with an Intel GPU, with https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880 mutter runs at full frame rate even if a client is GPU limited much lower

12:23 <pq> oh that's nice, I thought hardware had problems preempting e.g. mid-primitive-batch

12:29 <MrCooper> not sure about the granularity, pathological clients might still be able to block the compositor

12:38 <zzag> out of curiosity, how?

12:42 <pq> maybe like rendering one triangle with a frag shader that takes ages

12:45 <zzag> but the dmabuf fds shouldn't be readable in that case, should they?

12:46 <pq> no, but also the GPU may not be able to switch to the compositor job

12:46 <MrCooper> yep

12:47 <pq> massively parallel deep pipelines are massively painful to preempt and switch jobs

12:49 <MrCooper> my gut feeling is AMD GPUs might be able to preempt even during a single primitive, but I'm not sure

12:51 <MrCooper> they can definitely process multiple primitives in parallel

12:56 <swick> what I've been told is that preempting graphics queues is just horribly slow because of all the FF stuff

12:57 <swick> it shouldn't be hard to do the actual compositing on compute queues though

13:02 <MrCooper> that would even work already with AMD GPUs as well

13:10 <MrCooper> (at least with Vulkan, not sure high priority compute is possible with OpenGL)

13:21 <swick> and I think bas also mentioned that eg the texture units understand high priority contexts so the compositor should not get starved by textuure accesses from other contexts

13:21 <swick> wait for buffer to be ready, use a high priority compute queue to composite and things should just work out

13:32 <swick> pq: both PQ and HLG can adjust the content based on the viewing environment. for HLG this adjusting is predefined in the OOTF and intentionally undefined in PQ.

13:34 <swick> the brightness/contrast adjustment using reference white and black levels would interfer with the display adjustment in both cases

13:35 <swick> in other words: if the display is in PQ or HLG mode we should probably not do any of that stuff and just fix the white and black levels according to the specific EOTF.

13:36 <swick> *fix the white and black level to a specific, fixed value

13:38 <pq> sounds plausible

13:38 <pq> swick, I'm also starting to wonder that OOTF is a different concept between the PQ and HLG approaches too. The HLG diagrams seem to forget the artistic/mastering adjustments completely, and since OOTF is in receiver, they are not in OOTF for HLG.

13:42 <swick> OOTFs can be in multiple places in the pipeline afaik

13:43 <pq> I haven't seen any diagram like that yet.

13:44 <swick> neither have I but some of those documents talk about this artistic/master process for HLG for TV operators

13:44 <swick> and OOTF is just a term for basically an arbitrary mapping from optical to optical values

13:45 <pq> Sure, and that is kind of my point: I got the feeling that with HLG, OOTF is from mastering display optical to end user display optical.

13:45 <pq> but all diagrams tell us that OOTF is the camera optical to end user display optical

13:47 <swick> well, the mastering display optical to end user display optical is an OOTF which is part of the overall OOTF which is from camera linear optical to end user display optical

13:47 <swick> at least that's my understanding

13:47 <pq> You'd think that OETF can only happen in a camera because it converts light into electrical signals, but if OOTF can be from display to display, not only camera to display, then why would OETF be limited to cameras?

13:47 <swick> tbh I also think that the specs are not really clear on this

13:48 <pq> remember my initial mistake thinking that OETF is just another name for the inverse function of EOTF?

13:49 <pq> the same confusion seems to be going on with OOTF

13:49 <pq> so in different specs, while the words are the same, their meaning is different

13:50 <pq> ..for some words

13:50 <swick> I definitely have the same feeling

13:51 <swick> I also really don't like how PQ and HLG are pretending to be much more different than they really are

13:51 <pq> heh, I started to get the same

13:52 <swick> the problem here seems to be that those terms were coined for live television

13:53 <swick> i.e. the OETF really was your camera system

13:53 <pq> one always does mastering/artistic in the camera/broadcaster side, and you always do adaptation to enviroment and display in the display side, because the broadcasting signal is the same for all receivers.

13:55 <swick> and you would also do the artistic stuff in the camera system, so from that POV it all makes sense

13:57 <swick> right. not only that, the absolute and relative TFs also are basically the same but nobody wants to admit it. there always is a reference viewing enviornment and reference display (sometimes really badly specified) which gives absolute values to all relative TFs.

14:03 <pq> I looked at BT.2100 again and my mind hurts.

14:23 <The_Observer> Hey, I wrote here yesterday about a problem with the touchpad on my new laptop, the Librem 14. I did figure out what the issue was now. libinputs 1.18.0 does not support any "Click methods", for my touchpad anymore ("none"). It does work fine with prior versions.

14:25 <The_Observer> Is this somehow intended, and if so, why? And again, if thats not the right place to ask such questions, I'd be glad if someone would tell me where else to ask. Opening a bug for this does currently not seem appropriate for me.

14:25 <jadahl> The_Observer: best might be to open a bug report

14:26 <jadahl> the libinput maintainer is very likely sleeping right now

14:27 <The_Observer> Thanks, I'll do that.

17:31 <ice9> guys, are you the dev of xwayland too?

21:02 <kennylevinsen> ice9: xwayland is just a part of the xorg-server project.