summaryrefslogtreecommitdiffstats
path: root/video/out/present_sync.h
Commit message (Collapse)AuthorAgeFilesLines
* present_sync: remove unneeded clear_values functionDudemanguy2023-11-071-3/+0
| | | | | | | | | This was specifically special logic for drm. Before present_sync, it would also clear out all of its vsync values like this. The old drm code would save a bunch of samples which would confuse vo.c when unpausing since it got old, bogus values. Since we make sure to match successive vsync samples with the swapchain depth and that present sync samples also match the swapchain depth, this is unneeded.
* present_sync: only save as many entries as the swapchain depthDudemanguy2023-11-071-1/+2
| | | | | | Saving more than the swapchain depth is just wasteful. We can just save a copy of the vo_opts here and check the value whenever we're updating values.
* drm: use present_sync mechanism for presentation feedbackDudemanguy2023-11-061-0/+3
| | | | | | | | | | | A ton of code and drm-specific abstractions can be dropped with this. One important thing to note is that the usage of sbc is completely dropped here. The utility of that is not particularly clear since the sbc value was manually incremented before the flip and it's not as if the drm page flip event gives it to us like it does with the msec and ust. It can be reintroduced later if there is a need. For drm, we also add a present_sync_clear_values helper since all presentation feedback needs to be cleared on pause/resume for it.
* present_sync: rename function to present_sync_update_valuesDudemanguy2023-11-061-1/+1
| | | | This had to have been a mistake. It was just confusing.
* present_sync: rewrite around linked listDudemanguy2023-11-061-7/+15
| | | | | | | | | | | | | | | | | | | | | | | | | When this was originally written, the queuing/list approach was deliberately removed since it adds more complication and xorg/wayland don't really use it anyway. In practice, you only really have one frame in flight with presentation timestamps. However, one slight annoyance is that the drm code has its own thing which is almost exactly the same and does its own calculations. Ideally, we'd port drm to this instead, but the implementation there takes into account N-frames in flight which probably does actually work. So we need to make present_sync smarter and be able to handle this. mpv does actually have its own linked list implementation already which is a good fit for this. mp_present becomes the list and each mp_present_entry has its own set of timestamps. During initialization, we create all the entries we need and then simply treat it like a queue during the lifecycle of the VO. When an entry is fully used (present_sync_get_info), then we remove it from the list, zero it out, and append it to the end for future use. This avoids needing to allocate memory on every frame (which is what drm currently does) and allows for a reasonable number of in flight frames at the same time as this should never grow to some obscene number. The nice thing is that current users of present_sync don't need to change anything besides the initialization step.
* vo: move wayland presentation to separate filesDudemanguy2022-06-191-0/+48
Wayland had some specific code that it used for implementing the presentation time protocol. It turns out that xorg's present extension is extremely similar, so it would be silly to duplicate this whole mess again. Factor this out to separate, independent code and introduce the mp_present struct which is used for handling the ust/msc values and some other associated values. Also, add in some helper functions so all the dirty details live specifically in present_sync. The only wayland-specific part is actually obtaining ust/msc values. Since only wayland or xorg are expected to use this, add a conditional to the build that only adds this file when either one of those are present. You may observe that sbc is completely omitted. This field existed in wayland, but was completely unused (presentation time doesn't return this). Xorg's present extension also doesn't use this so just get rid of it all together. The actual calculation is slightly altered so it is correct for our purposes. We want to get the presentation event of the last frame that was just occured (this function executes right after the buffer swap). The adjustment is to just remove the vsync_duration subtraction. Also, The overly-complicated queue approach is removed. This has no actual use in practice (on wayland or xorg). Presentation statistics are only ever used after the immediate preceding swap to update vsync timings or thrown away.