On Wed, 8 Mar 2023 07:52:51 -0800 Rob Clark wrote: > From: Rob Clark > > This series adds a deadline hint to fences, so realtime deadlines > such as vblank can be communicated to the fence signaller for power/ > frequency management decisions. > > This is partially inspired by a trick i915 does, but implemented > via dma-fence for a couple of reasons: > > 1) To continue to be able to use the atomic helpers > 2) To support cases where display and gpu are different drivers > > This iteration adds a dma-fence ioctl to set a deadline (both to > support igt-tests, and compositors which delay decisions about which > client buffer to display), and a sw_sync ioctl to read back the > deadline. IGT tests utilizing these can be found at: > > https://gitlab.freedesktop.org/robclark/igt-gpu-tools/-/commits/fence-deadline > > > v1: https://patchwork.freedesktop.org/series/93035/ > v2: Move filtering out of later deadlines to fence implementation > to avoid increasing the size of dma_fence > v3: Add support in fence-array and fence-chain; Add some uabi to > support igt tests and userspace compositors. > v4: Rebase, address various comments, and add syncobj deadline > support, and sync_file EPOLLPRI based on experience with perf/ > freq issues with clvk compute workloads on i915 (anv) > v5: Clarify that this is a hint as opposed to a more hard deadline > guarantee, switch to using u64 ns values in UABI (still absolute > CLOCK_MONOTONIC values), drop syncobj related cap and driver > feature flag in favor of allowing count_handles==0 for probing > kernel support. > v6: Re-work vblank helper to calculate time of _start_ of vblank, > and work correctly if the last vblank event was more than a > frame ago. Add (mostly unrelated) drm/msm patch which also > uses the vblank helper. Use dma_fence_chain_contained(). More > verbose syncobj UABI comments. Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT. > v7: Fix kbuild complaints about vblank helper. Add more docs. > v8: Add patch to surface sync_file UAPI, and more docs updates. > v9: Drop (E)POLLPRI support.. I still like it, but not essential and > it can always be revived later. Fix doc build warning. > v10: Update 11/15 to handle multiple CRTCs Hi Rob, it is very nice to keep revision numbers and list the changes in each patch. If I looked at series v8 last, and I now see series v10, and I look at a patch that lists changes done in v7, how do I know if that change was made between series v8 and v10 or earlier? At least in some previous revision, series might have been v8 and a patch have new changes listed as v5 (because it was the 5th time that one patch was changed) instead of v8. Am I expected to keep track of vN of each individual patch independently? Thanks, pq