Hi Michel, > On 2021-08-10 10:30 a.m., Daniel Vetter wrote: > > On Tue, Aug 10, 2021 at 08:21:09AM +0000, Kasireddy, Vivek wrote: > >>> On Fri, Aug 06, 2021 at 07:27:13AM +0000, Kasireddy, Vivek wrote: > >>>>>>> > >>>>>>> Hence my gut feeling reaction that first we need to get these two > >>>>>>> compositors aligned in their timings, which propobably needs > >>>>>>> consistent vblank periods/timestamps across them (plus/minux > >>>>>>> guest/host clocksource fun ofc). Without this any of the next steps > >>>>>>> will simply not work because there's too much jitter by the time the > >>>>>>> guest compositor gets the flip completion events. > >>>>>> [Kasireddy, Vivek] Timings are not a problem and do not significantly > >>>>>> affect the repaint cycles from what I have seen so far. > >>>>>> > >>>>>>> > >>>>>>> Once we have solid events I think we should look into statically > >>>>>>> tuning guest/host compositor deadlines (like you've suggested in a > >>>>>>> bunch of places) to consisently make that deadline and hit 60 fps. > >>>>>>> With that we can then look into tuning this automatically and what to > >>>>>>> do when e.g. switching between copying and zero-copy on the host side > >>>>>>> (which might be needed in some cases) and how to handle all that. > >>>>>> [Kasireddy, Vivek] As I confirm here: > >>> https://gitlab.freedesktop.org/wayland/weston/- > >>>>> /issues/514#note_984065 > >>>>>> tweaking the deadlines works (i.e., we get 60 FPS) as we expect. > >>>>>> However, > >>>>>> I feel that this zero-copy solution I am trying to create should be > >>>>>> independent > >>>>>> of compositors' deadlines, delays or other scheduling parameters. > >>>>> > >>>>> That's not how compositors work nowadays. Your problem is that you don't > >>>>> have the guest/host compositor in sync. zero-copy only changes the > >>>>> timing, > >>>>> so it changes things from "rendering way too many frames" to "rendering > >>>>> way too few frames". > >>>>> > >>>>> We need to fix the timing/sync issue here first, not paper over it with > >>>>> hacks. > >>>> [Kasireddy, Vivek] What I really meant is that the zero-copy solution > >>>> should be > >>>> independent of the scheduling policies to ensure that it works with all > >>>> compositors. > >>>> IIUC, Weston for example uses the vblank/pageflip completion timestamp, > >>>> the > >>>> configurable repaint-window value, refresh-rate, etc to determine when > >>>> to start > >>>> its next repaint -- if there is any damage: > >>>> timespec_add_nsec(&output->next_repaint, stamp, refresh_nsec); > >>>> timespec_add_msec(&output->next_repaint, &output->next_repaint, > >>>> -compositor- > >>>> repaint_msec); > >>>> > >>>> And, in the case of VKMS, since there is no real hardware, the timestamp > >>>> is always: > >>>> now = ktime_get(); > >>>> send_vblank_event(dev, e, seq, now); > >>> > >>> vkms has been fixed since a while to fake high-precision timestamps like > >>> from a real display. > >> [Kasireddy, Vivek] IIUC, that might be one of the reasons why the Guest > >> does not need > >> to have the same timestamp as that of the Host -- to work as expected. > >> > >>> > >>>> When you say that the Guest/Host compositor need to stay in sync, are you > >>>> suggesting that we need to ensure that the vblank timestamp on the Host > >>>> needs to be shared and be the same on the Guest and a vblank/pageflip > >>>> completion for the Guest needs to be sent at exactly the same time it is > >>>> sent > >>>> on the Host? If yes, I'd say that we do send the pageflip completion to > >>>> Guest > >>>> around the same time a vblank is generated on the Host but it does not > >>>> help > >>>> because the Guest compositor would only have 9 ms to submit a new frame > >>>> and if the Host is running Mutter, the Guest would only have 2 ms. > >>>> (https://gitlab.freedesktop.org/wayland/weston/-/issues/514#note_984341) > >>> > >>> Not at the same time, but the same timestamp. And yes there is some fun > >>> there, which is I think the fundamental issue. Or at least some of the > >>> compositor experts seem to think so, and it makes sense to me. > >> [Kasireddy, Vivek] It is definitely possible that if the timestamp is > >> messed up, then > >> the Guest repaint cycle would be affected. However, I do not believe that > >> is the case > >> here given the debug and instrumentation data we collected and > >> scrutinized. Hopefully, > >> compositor experts could chime in to shed some light on this matter. > >> > >>> > >>>>> > >>>>> Only, and I really mean only, when that shows that it's simply > >>>>> impossible > >>>>> to hit 60fps with zero-copy and the guest/host fully aligned should we > >>>>> look into making the overall pipeline deeper. > >>>> [Kasireddy, Vivek] From all the experiments conducted so far and given > >>>> the > >>>> discussion associated with > >>>> https://gitlab.freedesktop.org/wayland/weston/- > /issues/514 > >>>> I think we have already established that in order for a zero-copy > >>>> solution to work > >>>> reliably, the Guest compositor needs to start its repaint cycle when the > >>>> Host > >>>> compositor sends a frame callback event to its clients. > >>>> > >>>>> > >>>>>>> Only when that all shows that we just can't hit 60fps consistently and > >>>>>>> really need 3 buffers in flight should we look at deeper kms queues. > >>>>>>> And then we really need to implement them properly and not with a > >>>>>>> mismatch between drm_event an out-fence signalling. These quick hacks > >>>>>>> are good for experiments, but there's a pile of other things we need > >>>>>>> to do first. At least that's how I understand the problem here right > >>>>>>> now. > >>>>>> [Kasireddy, Vivek] Experiments done so far indicate that we can hit 59 > >>>>>> FPS > >>> consistently > >>>>>> -- in a zero-copy way independent of compositors' delays/deadlines -- > >>>>>> with this > >>>>>> patch series + the Weston MR I linked in the cover letter. The main > >>>>>> reason why > this > >>>>>> works is because we relax the assumption that when the Guest > >>>>>> compositor gets a > >>>>>> pageflip completion event that it could reuse the old FB it submitted > >>>>>> in the > previous > >>>>>> atomic flip and instead force it to use a new one. And, we send the > >>>>>> pageflip > >>> completion > >>>>>> event to the Guest when the Host compositor sends a frame callback > >>>>>> event. > Lastly, > >>>>>> we use the (deferred) out_fence as just a mechanism to tell the Guest > >>>>>> compositor > >>> when > >>>>>> it can release references on old FBs so that they can be reused again. > >>>>>> > >>>>>> With that being said, the only question is how can we accomplish the > >>>>>> above in an > >>>>> upstream > >>>>>> acceptable way without regressing anything particularly on bare-metal. > >>>>>> Its not > clear > >>> if > >>>>> just > >>>>>> increasing the queue depth would work or not but I think the Guest > >>>>>> compositor > has to > >>> be > >>>>> told > >>>>>> when it can start its repaint cycle and when it can assume the old FB > >>>>>> is no longer > in > >>> use. > >>>>>> On bare-metal -- and also with VKMS as of today -- a pageflip > >>>>>> completion > indicates > >>>>> both. > >>>>>> In other words, Vblank event is the same as Flip done, which makes > >>>>>> sense on > bare- > >>> metal. > >>>>>> But if we were to have two events at-least for VKMS: vblank to > >>>>>> indicate to Guest > to > >>> start > >>>>>> repaint and flip_done to indicate to drop references on old FBs, I > >>>>>> think this > problem > >>> can > >>>>>> be solved even without increasing the queue depth. Can this be > >>>>>> acceptable? > >>>>> > >>>>> That's just another flavour of your "increase queue depth without > >>>>> increasing the atomic queue depth" approach. I still think the > >>>>> underlying > >>>>> fundamental issue is a timing confusion, and the fact that adjusting the > >>>>> timings fixes things too kinda proves that. So we need to fix that in a > >>>>> clean way, not by shuffling things around semi-randomly until the > >>>>> specific > >>>>> config we tests works. > >>>> [Kasireddy, Vivek] This issue is not due to a timing or timestamp > >>>> mismatch. We > >>>> have carefully instrumented both the Host and Guest compositors and > >>>> measured > >>>> the latencies at each step. The relevant debug data only points to the > >>>> scheduling > >>>> policy -- of both Host and Guest compositors -- playing a role in Guest > >>>> rendering > >>>> at 30 FPS. > >>> > >>> Hm but that essentially means that the events your passing around have an > >>> even more ad-hoc implementation specific meaning: Essentially it's the > >>> kick-off for the guest's repaint loop? That sounds even worse for a kms > >>> uapi extension. > >> [Kasireddy, Vivek] The pageflip completion event/vblank event indeed > >> serves as the > >> kick-off for a compositor's (both Guest and Host) repaint loop. AFAICT, > >> Weston > >> works that way and even if we increase the queue depth to solve this > >> problem, I don't > >> think it'll help because the arrival of this event always indicates to a > >> compositor to > >> start its repaint cycle again and assume that the previous buffers are all > >> free. > > > > I thought this is how simple compositors work, and weston has since a > > while it's own timer, which is based on the timestamp it gets (at on > > drivers with vblank support), so that it starts the repaint loop a few ms > > before the next vblank. And not immediately when it receives the old page > > flip completion event. > > As long as it's a fixed timer, there's still a risk that the guest compositor > repaint cycle runs > too late for the host one (unless the guest cycle happens to be scheduled > significantly > earlier than the host one). > > Note that current mutter Git main (to become the 41 release this autumn) uses > dynamic > scheduling of its repaint cycle based on how long the last 16 frames took to > draw and > present. In theory, this could automatically schedule the guest cycle early > enough for the > host one. [Kasireddy, Vivek] I'd like to try it out soon; it'd be very interesting to see how Mutter works in both Guest and Host with this new scheduling policy. Having said that, I think there is still a need to come up with a comprehensive solution that is independent of compositors' scheduling policies. To that end, I am thinking of splitting the pageflip completion event into two events: vblank event (to indicate to compositor to start repaint) and flip_done event (to indicate to release references on old FBs). Or, introduce two new signals/fences along similar lines. Thoughts?
Thanks, Vivek > > > -- > Earthling Michel Dänzer | https://redhat.com > Libre software enthusiast | Mesa and X developer
