Michel Dänzer <mic...@daenzer.net> writes: > Instead of rounding to the nearest upcoming frame, should it round to > the earliest frame after the specified period has passed? As written, it > seems to contradict the next paragraph below:
Sorry for the poor wording; let me describe what I want informally here. For nanosecond periods to be easy to use on fixed-refresh-rate monitors, I want the näive computation to "just work". For a given refresh period, 'r', I want to select a period of 'n' frames using: computed_period = n * r Because of clock skew and rounding problems, it's quite possible that the period could easily end up being just slightly smaller than that: actual_period = n * r - ε When I said 'nearest', what I intended to describe was that the target frame would be as close as possible to the specified time. > (I'm not ruling out that rounding to nearest might be better, but there > should be a rationale for it, which also justifies being inconsistent > with GOOGLE_display_timing) Yes, this is intentionally inconsistent with GOOGLE_display_timing, which I believe is hard to use correctly. By specifying not before semantics, GOOGLE_display_timing requires applications compute a fake time guaranteed to be not after the actual target frame time. This really messes things up when you might have variable refresh rate monitors. I just went and read the time-based stuff from the X Present extension. That uses 'nearest' semantics too, when supported by the driver. When not supported, the server gets to do whatever it likes (oops!). > I like this extension in general. Thanks! I've been trying to get this posted for a few months now. > However, I think allowing the period to be specified in frames might be > a mistake, because it won't work well with variable refresh rate. But > it'll be tempting for application / toolkit developers not to bother > with proper time calculations but to just use frames instead. (It would > be good to seek feedback on this from AMD DC developers and the larger > DRM kernel driver community as well) Yeah, given that the application will need the refresh period to know what to display, it certainly doesn't provide much technical benefit here. I stuck it in to make the extension feel like GL's swap interval stuff (although it isn't the same), and because it seemed like a 'nice' thing to offer applications. > P.S. It would be good to create a WIP merge request for this in the main > Mesa project, to have a central place for gathering feedback and > tracking progress. Done, thanks for the suggestion. -- -keith
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev