Re: [Mesa-dev] What use do swap interval 1 and OML_sync_control divisor and remainder have?
On Fri, Jan 24, 2014 at 4:32 AM, Pekka Paalanen ppaala...@gmail.com wrote: Hi, I am investigating what kind of Wayland protocol extensions would be needed to support proper presentation timing. Looking at existing works, I am wondering about two things whether they have any real use. Where is swap interval (e.g. eglSwapInterval) greater than one useful? Intervals 0 and 1 I understand, and Mesa EGL Wayland already supports those. But when would you like to make your framerate a fraction of the display's? To save power. To target 30 Hz when you can't hit 60 Hz and would otherwise get 45 Hz (and the corresponding jitter because you alternate 1 vblank per frame - 2 vblanks per frame). When are the target-MSC related remainder and divisor parameters as defined in the GLX_OML_sync_control useful? Why does also X11 Present protocol include remainder and divisor? GLX_OML_sync_control defines that for interlaced displays MSC is incremented for each field. With divisor and remainder you could then target only top or bottom fields. Is that useful, and do we care about interlaced displays anymore? 1080i, which is the preferred resolution for a lot of TVs. I am contemplating on not supporting these, because I am going to propose using an UST-like clock as the standard clock language in Wayland present extension. Supporting MSC-based timings would add complexity. Therefore I would like to know where and how the above mentioned are useful, because I cannot imagine it myself. You can look in Chrome for an interesting use of GLX_OML_sync_control (look for sync_control_vsync_provider.cc) . It is used to schedule the rendering of the next frame without incurring too much latency, while keeping a constant swap delay (to avoid the 45 Hz phenomenon, and to buffer as many updates as possible before starting to draw without missing the frame). Granted, there are some shortcomings (multi-monitor is one, as the extension doesn't support those) but overall it helps. Stéphane Please, let me know of real actual use cases and existing software, where these features offer a visible benefit and what that benefit is exactly. I am not interested in what one might do in theory, I am interested in real-world examples where they have proved useful. Well, maybe also theories if they allow taking advantage of some new cool technology. Btw. if you think that using UST for presentation timing and feedback is nonsense, and MSC is the only right way, let me know and I can start another email thread about that detail after preparing my material. Thanks, pq ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] What use do swap interval 1 and OML_sync_control divisor and remainder have?
[Just for the sake of argument] 2014-01-28 Pekka Paalanen ppaala...@gmail.com: Hi Ian and Jason On Mon, 27 Jan 2014 12:26:23 -0700 Ian Romanick i...@freedesktop.org wrote: There are a number of theoretical uses, but I don't know that we've ever seen any in the wild. One is video playback. You likely want 30fps there. I would hope that no video player will use swap interval as a means of target timing, because the buffer queueing protocol I'm planning is supposed to be superior for accurately timed video presentation. The protocol will also be usable with EGL provided content, if the EGL implementation can cope with buffers being reserved by the display server for longer than usual. One more argument would be that video players actually don't want 30fps here, and do that only because of constrained resources. Every Smart TV sold nowadays has the motion-interpolation feature, which is (unlike frame-doubling, and at least from the viewpoint of some people) the proper way to display low-fps content on high-fps panels. PC-based video players don't have this feature because nobody so far has written the code that works on anything else than NVidia GPUs. -- Alexander E. Patrakov ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] What use do swap interval 1 and OML_sync_control divisor and remainder have?
Hi Ian and Jason On Mon, 27 Jan 2014 12:26:23 -0700 Ian Romanick i...@freedesktop.org wrote: On 01/24/2014 04:32 AM, Pekka Paalanen wrote: Hi, I am investigating what kind of Wayland protocol extensions would be needed to support proper presentation timing. Looking at existing works, I am wondering about two things whether they have any real use. Where is swap interval (e.g. eglSwapInterval) greater than one useful? Intervals 0 and 1 I understand, and Mesa EGL Wayland already supports those. But when would you like to make your framerate a fraction of the display's? There are a number of theoretical uses, but I don't know that we've ever seen any in the wild. One is video playback. You likely want 30fps there. I would hope that no video player will use swap interval as a means of target timing, because the buffer queueing protocol I'm planning is supposed to be superior for accurately timed video presentation. The protocol will also be usable with EGL provided content, if the EGL implementation can cope with buffers being reserved by the display server for longer than usual. Imagine that you have a game that only needs 30fps to be playable. When you're running on battery, you may want the system to throttle you to a lower framerate to save battery. You could also have a game that can always hit at least 30fps, but sometimes it may go higher. Using a swap interval of 2 gives the the game a consistent framerate. Sometimes that is better. 120Hz monitors. These are good points. I can easily come up with a counter argument for at least the first and last, how something else would be better than the application itself setting swap interval. I can even see a compositor user option limit this window/application to a fraction of the refresh rate Hz which is already possible in Wayland without any protocol changes. Whether that would be a good UI is another question. After this and the discussion on #xorg-devel, I am now fairly confident, that I do not have to design for swap interval 1 support at this time. If such support really is needed, I see two possibilies already. - Use the buffer queueing protocol to target presentation at last realized presentation time plus two frame periods. EGL internally could keep on waiting for the usual frame callback (a Wayland protocol feature) like it does now for swap interval = 1. Enabling this occurred to me yesterday, and I have it in my buffer queue plans now. - Add a new request alike wl_surface.frame, which has a parameter of how many output refresh cycles should pass since the last presentation before this presentation is executed. When are the target-MSC related remainder and divisor parameters as defined in the GLX_OML_sync_control useful? Why does also X11 Present protocol include remainder and divisor? X11 Present has it to support GLX_OML_sync_control. I believe that GLX_OML_sync_control has it to support playback of content on monitors that aren't 60Hz. There used to be these things called CRTs, and some of them had wonkey refresh rates... like 72Hz. But the divisor and remainder apply only if the original target-MSC is missed, causing the presentation to be postponed to a later point in time determined by matching the modulus of MSC. I still don't really understand when that was useful, or how it was even used. Are you saying that these were used to pretend that the monitor refresh rate was something lower than what it really was? Did that really work better than just presenting the content update at the earliest possible refresh? On Fri, 24 Jan 2014 12:27:11 -0600 Jason Ekstrand ja...@jlekstrand.net wrote: On Jan 24, 2014 6:32 AM, Pekka Paalanen ppaala...@gmail.com wrote: GLX_OML_sync_control defines that for interlaced displays MSC is incremented for each field. With divisor and remainder you could then target only top or bottom fields. Is that useful, and do we care about interlaced displays anymore? I think we do. In particular, we should care about TV set-top boxes. Even though most TVs are LCD, DLP, or similar, hdmi does support interlacing and it is still used (particularly in HDTV). I have no idea what implications this has for a present extension, but I think we could still handle it in a sane way without going for MSC. Right, there was quite some discussion on #xorg-devel about interlacing. All that lead me to write down the following in my notes: Supporting interlaced material and displays is punted for a later extension. Presumably the protocol supporting interlaced content would be as simple as having an extra wl_surface-like request to say on which of the two fields the content should be displayed first. The field designation would be an additional restriction on when a content update should initially hit the screen. I.e. if both field and target timestamp are given, both conditions must pass. This means that giving a field may delay the
Re: [Mesa-dev] What use do swap interval 1 and OML_sync_control divisor and remainder have?
On 01/24/2014 04:32 AM, Pekka Paalanen wrote: Hi, I am investigating what kind of Wayland protocol extensions would be needed to support proper presentation timing. Looking at existing works, I am wondering about two things whether they have any real use. Where is swap interval (e.g. eglSwapInterval) greater than one useful? Intervals 0 and 1 I understand, and Mesa EGL Wayland already supports those. But when would you like to make your framerate a fraction of the display's? There are a number of theoretical uses, but I don't know that we've ever seen any in the wild. One is video playback. You likely want 30fps there. Imagine that you have a game that only needs 30fps to be playable. When you're running on battery, you may want the system to throttle you to a lower framerate to save battery. You could also have a game that can always hit at least 30fps, but sometimes it may go higher. Using a swap interval of 2 gives the the game a consistent framerate. Sometimes that is better. 120Hz monitors. When are the target-MSC related remainder and divisor parameters as defined in the GLX_OML_sync_control useful? Why does also X11 Present protocol include remainder and divisor? X11 Present has it to support GLX_OML_sync_control. I believe that GLX_OML_sync_control has it to support playback of content on monitors that aren't 60Hz. There used to be these things called CRTs, and some of them had wonkey refresh rates... like 72Hz. GLX_OML_sync_control defines that for interlaced displays MSC is incremented for each field. With divisor and remainder you could then target only top or bottom fields. Is that useful, and do we care about interlaced displays anymore? I am contemplating on not supporting these, because I am going to propose using an UST-like clock as the standard clock language in Wayland present extension. Supporting MSC-based timings would add complexity. Therefore I would like to know where and how the above mentioned are useful, because I cannot imagine it myself. Please, let me know of real actual use cases and existing software, where these features offer a visible benefit and what that benefit is exactly. I am not interested in what one might do in theory, I am interested in real-world examples where they have proved useful. Well, maybe also theories if they allow taking advantage of some new cool technology. Btw. if you think that using UST for presentation timing and feedback is nonsense, and MSC is the only right way, let me know and I can start another email thread about that detail after preparing my material. Thanks, pq ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] What use do swap interval 1 and OML_sync_control divisor and remainder have?
I'll just chip in one quick thought. On Jan 24, 2014 6:32 AM, Pekka Paalanen ppaala...@gmail.com wrote: Hi, I am investigating what kind of Wayland protocol extensions would be needed to support proper presentation timing. Looking at existing works, I am wondering about two things whether they have any real use. Where is swap interval (e.g. eglSwapInterval) greater than one useful? Intervals 0 and 1 I understand, and Mesa EGL Wayland already supports those. But when would you like to make your framerate a fraction of the display's? When are the target-MSC related remainder and divisor parameters as defined in the GLX_OML_sync_control useful? Why does also X11 Present protocol include remainder and divisor? GLX_OML_sync_control defines that for interlaced displays MSC is incremented for each field. With divisor and remainder you could then target only top or bottom fields. Is that useful, and do we care about interlaced displays anymore? I think we do. In particular, we should care about TV set-top boxes. Even though most TVs are LCD, DLP, or similar, hdmi does support interlacing and it is still used (particularly in HDTV). I have no idea what implications this has for a present extension, but I think we could still handle it in a sane way without going for MSC. I am contemplating on not supporting these, because I am going to propose using an UST-like clock as the standard clock language in Wayland present extension. Supporting MSC-based timings would add complexity. Therefore I would like to know where and how the above mentioned are useful, because I cannot imagine it myself. Please, let me know of real actual use cases and existing software, where these features offer a visible benefit and what that benefit is exactly. I am not interested in what one might do in theory, I am interested in real-world examples where they have proved useful. Well, maybe also theories if they allow taking advantage of some new cool technology. Btw. if you think that using UST for presentation timing and feedback is nonsense, and MSC is the only right way, let me know and I can start another email thread about that detail after preparing my material. Thanks, pq I hope that's helpful, --Jason Ekstrand ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] What use do swap interval 1 and OML_sync_control divisor and remainder have?
Hi, I am investigating what kind of Wayland protocol extensions would be needed to support proper presentation timing. Looking at existing works, I am wondering about two things whether they have any real use. Where is swap interval (e.g. eglSwapInterval) greater than one useful? Intervals 0 and 1 I understand, and Mesa EGL Wayland already supports those. But when would you like to make your framerate a fraction of the display's? When are the target-MSC related remainder and divisor parameters as defined in the GLX_OML_sync_control useful? Why does also X11 Present protocol include remainder and divisor? GLX_OML_sync_control defines that for interlaced displays MSC is incremented for each field. With divisor and remainder you could then target only top or bottom fields. Is that useful, and do we care about interlaced displays anymore? I am contemplating on not supporting these, because I am going to propose using an UST-like clock as the standard clock language in Wayland present extension. Supporting MSC-based timings would add complexity. Therefore I would like to know where and how the above mentioned are useful, because I cannot imagine it myself. Please, let me know of real actual use cases and existing software, where these features offer a visible benefit and what that benefit is exactly. I am not interested in what one might do in theory, I am interested in real-world examples where they have proved useful. Well, maybe also theories if they allow taking advantage of some new cool technology. Btw. if you think that using UST for presentation timing and feedback is nonsense, and MSC is the only right way, let me know and I can start another email thread about that detail after preparing my material. Thanks, pq ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
