On 3/16/23 23:22, Sebastian Wick wrote: > On Thu, Mar 16, 2023 at 5:29 PM Rob Clark <robdclark@xxxxxxxxx> wrote: >> On Thu, Mar 16, 2023 at 2:26 AM Jonas Ådahl <jadahl@xxxxxxxxx> wrote: >>> On Wed, Mar 15, 2023 at 09:19:49AM -0700, Rob Clark wrote: >>>> On Wed, Mar 15, 2023 at 6:53 AM Jonas Ådahl <jadahl@xxxxxxxxx> wrote: >>>>> On Fri, Mar 10, 2023 at 09:38:18AM -0800, Rob Clark wrote: >>>>>> On Fri, Mar 10, 2023 at 7:45 AM Jonas Ådahl <jadahl@xxxxxxxxx> wrote: >>>>>>> >>>>>>>> + * >>>>>>>> + * To this end, deadline hint(s) can be set on a &dma_fence via &dma_fence_set_deadline. >>>>>>>> + * The deadline hint provides a way for the waiting driver, or userspace, to >>>>>>>> + * convey an appropriate sense of urgency to the signaling driver. >>>>>>>> + * >>>>>>>> + * A deadline hint is given in absolute ktime (CLOCK_MONOTONIC for userspace >>>>>>>> + * facing APIs). The time could either be some point in the future (such as >>>>>>>> + * the vblank based deadline for page-flipping, or the start of a compositor's >>>>>>>> + * composition cycle), or the current time to indicate an immediate deadline >>>>>>>> + * hint (Ie. forward progress cannot be made until this fence is signaled). >>>>>>> >>>>>>> Is it guaranteed that a GPU driver will use the actual start of the >>>>>>> vblank as the effective deadline? I have some memories of seing >>>>>>> something about vblank evasion browsing driver code, which I might have >>>>>>> misunderstood, but I have yet to find whether this is something >>>>>>> userspace can actually expect to be something it can rely on. >>>>>> >>>>>> I guess you mean s/GPU driver/display driver/ ? It makes things more >>>>>> clear if we talk about them separately even if they happen to be the >>>>>> same device. >>>>> >>>>> Sure, sorry about being unclear about that. >>>>> >>>>>> >>>>>> Assuming that is what you mean, nothing strongly defines what the >>>>>> deadline is. In practice there is probably some buffering in the >>>>>> display controller. For ex, block based (including bandwidth >>>>>> compressed) formats, you need to buffer up a row of blocks to >>>>>> efficiently linearize for scanout. So you probably need to latch some >>>>>> time before you start sending pixel data to the display. But details >>>>>> like this are heavily implementation dependent. I think the most >>>>>> reasonable thing to target is start of vblank. >>>>> >>>>> The driver exposing those details would be quite useful for userspace >>>>> though, so that it can delay committing updates to late, but not too >>>>> late. Setting a deadline to be the vblank seems easy enough, but it >>>>> isn't enough for scheduling the actual commit. >>>> >>>> I'm not entirely sure how that would even work.. but OTOH I think you >>>> are talking about something on the order of 100us? But that is a bit >>>> of another topic. >>> >>> Yes, something like that. But yea, it's not really related. Scheduling >>> commits closer to the deadline has more complex behavior than that too, >>> e.g. the need for real time scheduling, and knowing how long it usually >>> takes to create and commit and for the kernel to process. > > Vblank can be really long, especially with VRR where the additional > time you get to finish the frame comes from making vblank longer. > Using the start of vblank as a deadline makes VRR useless. Not really. We normally still want to aim for start of vblank with VRR, which would result in the maximum refresh rate. Missing that target just incurs less of a penalty than with fixed refresh rate. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
