RE: [PATCH] Add freesync ioctl interface
This is somewhat easier to support on windows since windows has the concept of a fullscreen exclusive mode in the OS. Alex From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Ernst Sjöstrand Sent: Wednesday, August 10, 2016 4:25 AM To: Michel Dänzer Cc: Christian König; Dave Airlie; amd-gfx mailing list; Zhang, Hawking Subject: Re: [PATCH] Add freesync ioctl interface I thought I'd add some notes as a someone who also plays games on Windows with Freesync... I have a 4K monitor with Freesync, the range is 45 to 60 Hz. It might sounds narrow but it allows you to have a smooth experience even at very high resolutions and settings. If the game can't hit 60 fps exactly it's still fine, it seems smooth and you don't get tearing. This is shown in all games as a 60 Hz monitor even though Freesync is enabled. In the Windows gaming world there's a couple of different combinations at play: 1) Vsync disabled. The game renders frames simply as fast as it can. If the fps is below 45 I get tearing. If it's above 60 I get tearing. Not very good solution. 2) Vsync enabled. Fps stays capped to 60, so no tearing on that end. Also 50 fps is smooth and uses Freesync fine. This is AFAIK done behind the scene by the AMD DX11 implementation and not something the game is involved in. If fps goes below 45 it starts locking to 30 fps instead, not so nice. 3) Vsync disabled + AMD Frame Rate Target Control (FRTC). You set FRTC to 1-2 fps below your max refresh rate. That means that if fps goes below 45 you get tearing (at 45 Hz refresh or 60?), but at least it renders frames as fast as it can in that case still. This is a solution many people like. However FRTC doesn't work all the time. Regards //Ernst 2016-08-10 9:49 GMT+02:00 Michel Dänzer mailto:mic...@daenzer.net>>: On 10/08/16 12:19 PM, Michel Dänzer wrote: > On 09/08/16 07:44 PM, Christian König wrote: >> Am 09.08.2016 um 12:03 schrieb Michel Dänzer: >>> On 09/08/16 06:31 PM, Christian König wrote: >>>> >>>> When we add freesync support we just extend vblank_mode with a new enum >>>> to enable it optionally for existing applications. >>> "Just"... this will only be possible after the first 3 steps above. >> >> Checking the present extension again we already got PresentOptionAsync >> in there as well. >> >> So the whole thing boils down implementing a new vblank_mode enume which >> sets PresentOptionAsync and then doing the right thing on the X side >> with those information. > > PresentOptionAsync isn't for this. It's for not waiting for the vertical > blank period before performing a flip, which may result in tearing. This > distinction still applies with variable refresh rate, so this option > cannot be re-purposed to distinguish between variable and fixed refresh > rate. > > > BTW, the only presentation time we can use for the vblank_mode override > is "now" / "as soon as possible". So for that case (which is currently > the case for basically all games, and will likely continue to be for the > vast majority for a long time), the whole exercise doesn't provide any > net benefit over using the existing vblank-based presentation > infrastructure and just force-enabling variable refresh rate somehow. > > Note that I'm not questioning the value of time-based presentation for > video playback, and thus the need to implement it. I'm only questioning > the point of delaying variable refresh rate for games by gating it on > the time-based presentation infrastructure. Also, we still haven't covered how a variable refresh rate mode would actually get set in this case, assuming it can't be set all the time (because either there is no compositor, or it doesn't use OpenGL, or it doesn't work well with variable refresh rate). -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org> https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] Add freesync ioctl interface
Am 10.08.2016 um 05:19 schrieb Michel Dänzer: On 09/08/16 07:44 PM, Christian König wrote: Am 09.08.2016 um 12:03 schrieb Michel Dänzer: On 09/08/16 06:31 PM, Christian König wrote: Am 09.08.2016 um 10:27 schrieb Michel Dänzer: On 09/08/16 05:12 PM, Christian König wrote: [SNIP] This would require extensive changes across the stack though, when more or less the same result could be achieved by just letting the kernel know what the current refresh rate is supposed to be, e.g. via output properties. The problem is that you don't have a refresh rate any more. Maybe not below the video decoding API level, but the video player app certainly knows the refresh rate? Sure, but as I said that isn't a constant refresh rate any more. E.g. the refresh rate from the video header doesn't need to be a multiple of the time a vertical line takes to display. This results in sightly different display times for each frame. So you don't have a constant frame rate any more but rather alternate between two (or maybe more) different display times for each frame. And do you think we'll be able to program flips that accurately? Yes, why not? Even if the hardware can't do the flip at a specific vblank position (which as far as I know our hardware can) we can still use an HR timer for this. When we add freesync support we just extend vblank_mode with a new enum to enable it optionally for existing applications. "Just"... this will only be possible after the first 3 steps above. Checking the present extension again we already got PresentOptionAsync in there as well. So the whole thing boils down implementing a new vblank_mode enume which sets PresentOptionAsync and then doing the right thing on the X side with those information. PresentOptionAsync isn't for this. It's for not waiting for the vertical blank period before performing a flip, which may result in tearing. This distinction still applies with variable refresh rate, so this option cannot be re-purposed to distinguish between variable and fixed refresh rate. Ok that makes sense. But we can still use PresentOptionUst for controlling this. E.g. when you want to display a frame as fast as you can we send the PresentOptionUst flag and a zero timestamp (or in general something in the past/now). When we want a constant frame rate of some value we send the PresentOptionUst flag and a monotonic increasing timestamp when the frame should be displayed. BTW, the only presentation time we can use for the vblank_mode override is "now" / "as soon as possible". So for that case (which is currently the case for basically all games, and will likely continue to be for the vast majority for a long time), the whole exercise doesn't provide any net benefit over using the existing vblank-based presentation infrastructure and just force-enabling variable refresh rate somehow. Sure it does. My basic problem here is that just force-enabling it somehow is a really crude hack to just get it working fast and doesn't represent at all how the underlying hardware works. This surely will get us into problems when we move forward because of the required backward compatibility. Or isn't an output property something we want to keep for backward compatibility? Additional to that my fear is that when we allow such a flawed design in once at least the closed source driver will try to stick with that. Making things like DAL even harder to get merged upstream. Note that I'm not questioning the value of time-based presentation for video playback, and thus the need to implement it. I'm only questioning the point of delaying variable refresh rate for games by gating it on the time-based presentation infrastructure. I'm going to give the UST option a try with VDPAU, let's see how well that works and if it is implemented correctly or not. It's not implemented at all yet. Yeah, unfortunately. Leo already tried it and it is indeed not implemented at all. But at least we don't need to extend the spec in any way. BTW, it probably doesn't make sense to add support for time-based presentation to the pre-atomic KMS API. So another item to add to the list is adding support for the atomic KMS API to the DDX drivers. struct drm_mode_crtc_page_flip is used only as an IOCTL parameter with size checks as far as I can see. So we could extend the structure without breaking backward compatibility. But I agree that using the atomic API would indeed be a good idea here. Regards, Christian. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] Add freesync ioctl interface
I thought I'd add some notes as a someone who also plays games on Windows with Freesync... I have a 4K monitor with Freesync, the range is 45 to 60 Hz. It might sounds narrow but it allows you to have a smooth experience even at very high resolutions and settings. If the game can't hit 60 fps exactly it's still fine, it seems smooth and you don't get tearing. This is shown in all games as a 60 Hz monitor even though Freesync is enabled. In the Windows gaming world there's a couple of different combinations at play: 1) Vsync disabled. The game renders frames simply as fast as it can. If the fps is below 45 I get tearing. If it's above 60 I get tearing. Not very good solution. 2) Vsync enabled. Fps stays capped to 60, so no tearing on that end. Also 50 fps is smooth and uses Freesync fine. This is AFAIK done behind the scene by the AMD DX11 implementation and not something the game is involved in. If fps goes below 45 it starts locking to 30 fps instead, not so nice. 3) Vsync disabled + AMD Frame Rate Target Control (FRTC). You set FRTC to 1-2 fps below your max refresh rate. That means that if fps goes below 45 you get tearing (at 45 Hz refresh or 60?), but at least it renders frames as fast as it can in that case still. This is a solution many people like. However FRTC doesn't work all the time. Regards //Ernst 2016-08-10 9:49 GMT+02:00 Michel Dänzer : > On 10/08/16 12:19 PM, Michel Dänzer wrote: > > On 09/08/16 07:44 PM, Christian König wrote: > >> Am 09.08.2016 um 12:03 schrieb Michel Dänzer: > >>> On 09/08/16 06:31 PM, Christian König wrote: > > When we add freesync support we just extend vblank_mode with a new > enum > to enable it optionally for existing applications. > >>> "Just"... this will only be possible after the first 3 steps above. > >> > >> Checking the present extension again we already got PresentOptionAsync > >> in there as well. > >> > >> So the whole thing boils down implementing a new vblank_mode enume which > >> sets PresentOptionAsync and then doing the right thing on the X side > >> with those information. > > > > PresentOptionAsync isn't for this. It's for not waiting for the vertical > > blank period before performing a flip, which may result in tearing. This > > distinction still applies with variable refresh rate, so this option > > cannot be re-purposed to distinguish between variable and fixed refresh > > rate. > > > > > > BTW, the only presentation time we can use for the vblank_mode override > > is "now" / "as soon as possible". So for that case (which is currently > > the case for basically all games, and will likely continue to be for the > > vast majority for a long time), the whole exercise doesn't provide any > > net benefit over using the existing vblank-based presentation > > infrastructure and just force-enabling variable refresh rate somehow. > > > > Note that I'm not questioning the value of time-based presentation for > > video playback, and thus the need to implement it. I'm only questioning > > the point of delaying variable refresh rate for games by gating it on > > the time-based presentation infrastructure. > > Also, we still haven't covered how a variable refresh rate mode would > actually get set in this case, assuming it can't be set all the time > (because either there is no compositor, or it doesn't use OpenGL, or it > doesn't work well with variable refresh rate). > > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer > ___ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] Add freesync ioctl interface
On 10/08/16 12:19 PM, Michel Dänzer wrote: > On 09/08/16 07:44 PM, Christian König wrote: >> Am 09.08.2016 um 12:03 schrieb Michel Dänzer: >>> On 09/08/16 06:31 PM, Christian König wrote: When we add freesync support we just extend vblank_mode with a new enum to enable it optionally for existing applications. >>> "Just"... this will only be possible after the first 3 steps above. >> >> Checking the present extension again we already got PresentOptionAsync >> in there as well. >> >> So the whole thing boils down implementing a new vblank_mode enume which >> sets PresentOptionAsync and then doing the right thing on the X side >> with those information. > > PresentOptionAsync isn't for this. It's for not waiting for the vertical > blank period before performing a flip, which may result in tearing. This > distinction still applies with variable refresh rate, so this option > cannot be re-purposed to distinguish between variable and fixed refresh > rate. > > > BTW, the only presentation time we can use for the vblank_mode override > is "now" / "as soon as possible". So for that case (which is currently > the case for basically all games, and will likely continue to be for the > vast majority for a long time), the whole exercise doesn't provide any > net benefit over using the existing vblank-based presentation > infrastructure and just force-enabling variable refresh rate somehow. > > Note that I'm not questioning the value of time-based presentation for > video playback, and thus the need to implement it. I'm only questioning > the point of delaying variable refresh rate for games by gating it on > the time-based presentation infrastructure. Also, we still haven't covered how a variable refresh rate mode would actually get set in this case, assuming it can't be set all the time (because either there is no compositor, or it doesn't use OpenGL, or it doesn't work well with variable refresh rate). -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] Add freesync ioctl interface
On 09/08/16 07:44 PM, Christian König wrote: > Am 09.08.2016 um 12:03 schrieb Michel Dänzer: >> On 09/08/16 06:31 PM, Christian König wrote: >>> Am 09.08.2016 um 10:27 schrieb Michel Dänzer: On 09/08/16 05:12 PM, Christian König wrote: > Am 09.08.2016 um 04:44 schrieb Michel Dänzer: > >> I was basically thinking out loud that doing this via different modes >> might be quite natural, *if* games allowed choosing a specific mode. >> But unfortunately they don't. For the video playback case, how do you >> envision the video player app communicating the refresh rate of the >> currently playing video to the kernel? > Again the kernel doesn't need to know the refresh rate. All the kernel > needs to know is when to do the page flip. > > So coming back to my example of a mode with 1920x1080 and 20-100Hz > refresh rate a classic modeline would then look something like this: > > Modeline "1920x1080_dynamic" 302.50 1920 2072 2280 2640 1080 1083 > 1088 5735 -hsync +vsync > > Note the high vertical total scan lines. Those basically reduce the > refresh rate from 100Hz (which this mode normally would have) down to > only 20Hz. > > Now what userspace does on each page flip is specifying when this flip > should happen, e.g. when the frame should be started to be scanned > out. > We can either specify this as frame counter + vertical line of the > previous frame or as something like CLOCK_MONOTONIC (I think I would > prefer CLOCK_MONOTONIC, but that's not a strong opinion). > > In other words you put the whole concept upside down. It's no > longer the > kernel which tells userspace when a vblank happened, but rather > userspace tells the kernel when it should happen (together with the > frame that should be displayed then). I guess that could work. Do video players set the VDPAU presentation time accurately enough for this? >>> Yes, of course. We actually get a precise time stamp from the >>> application and need to calculate on which vblank to display it from >>> that. >>> This would require extensive changes across the stack though, when more or less the same result could be achieved by just letting the kernel know what the current refresh rate is supposed to be, e.g. via output properties. >>> The problem is that you don't have a refresh rate any more. >> Maybe not below the video decoding API level, but the video player app >> certainly knows the refresh rate? > > Sure, but as I said that isn't a constant refresh rate any more. > > E.g. the refresh rate from the video header doesn't need to be a > multiple of the time a vertical line takes to display. > > This results in sightly different display times for each frame. So you > don't have a constant frame rate any more but rather alternate between > two (or maybe more) different display times for each frame. And do you think we'll be able to program flips that accurately? >>> When we add freesync support we just extend vblank_mode with a new enum >>> to enable it optionally for existing applications. >> "Just"... this will only be possible after the first 3 steps above. > > Checking the present extension again we already got PresentOptionAsync > in there as well. > > So the whole thing boils down implementing a new vblank_mode enume which > sets PresentOptionAsync and then doing the right thing on the X side > with those information. PresentOptionAsync isn't for this. It's for not waiting for the vertical blank period before performing a flip, which may result in tearing. This distinction still applies with variable refresh rate, so this option cannot be re-purposed to distinguish between variable and fixed refresh rate. BTW, the only presentation time we can use for the vblank_mode override is "now" / "as soon as possible". So for that case (which is currently the case for basically all games, and will likely continue to be for the vast majority for a long time), the whole exercise doesn't provide any net benefit over using the existing vblank-based presentation infrastructure and just force-enabling variable refresh rate somehow. Note that I'm not questioning the value of time-based presentation for video playback, and thus the need to implement it. I'm only questioning the point of delaying variable refresh rate for games by gating it on the time-based presentation infrastructure. > I'm going to give the UST option a try with VDPAU, let's see how well > that works and if it is implemented correctly or not. It's not implemented at all yet. BTW, it probably doesn't make sense to add support for time-based presentation to the pre-atomic KMS API. So another item to add to the list is adding support for the atomic KMS API to the DDX drivers. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer __
Re: [PATCH] Add freesync ioctl interface
Am 09.08.2016 um 12:03 schrieb Michel Dänzer: On 09/08/16 06:31 PM, Christian König wrote: Am 09.08.2016 um 10:27 schrieb Michel Dänzer: On 09/08/16 05:12 PM, Christian König wrote: Am 09.08.2016 um 04:44 schrieb Michel Dänzer: I was basically thinking out loud that doing this via different modes might be quite natural, *if* games allowed choosing a specific mode. But unfortunately they don't. For the video playback case, how do you envision the video player app communicating the refresh rate of the currently playing video to the kernel? Again the kernel doesn't need to know the refresh rate. All the kernel needs to know is when to do the page flip. So coming back to my example of a mode with 1920x1080 and 20-100Hz refresh rate a classic modeline would then look something like this: Modeline "1920x1080_dynamic" 302.50 1920 2072 2280 2640 1080 1083 1088 5735 -hsync +vsync Note the high vertical total scan lines. Those basically reduce the refresh rate from 100Hz (which this mode normally would have) down to only 20Hz. Now what userspace does on each page flip is specifying when this flip should happen, e.g. when the frame should be started to be scanned out. We can either specify this as frame counter + vertical line of the previous frame or as something like CLOCK_MONOTONIC (I think I would prefer CLOCK_MONOTONIC, but that's not a strong opinion). In other words you put the whole concept upside down. It's no longer the kernel which tells userspace when a vblank happened, but rather userspace tells the kernel when it should happen (together with the frame that should be displayed then). I guess that could work. Do video players set the VDPAU presentation time accurately enough for this? Yes, of course. We actually get a precise time stamp from the application and need to calculate on which vblank to display it from that. This would require extensive changes across the stack though, when more or less the same result could be achieved by just letting the kernel know what the current refresh rate is supposed to be, e.g. via output properties. The problem is that you don't have a refresh rate any more. Maybe not below the video decoding API level, but the video player app certainly knows the refresh rate? Sure, but as I said that isn't a constant refresh rate any more. E.g. the refresh rate from the video header doesn't need to be a multiple of the time a vertical line takes to display. This results in sightly different display times for each frame. So you don't have a constant frame rate any more but rather alternate between two (or maybe more) different display times for each frame. I mean we could of course adjust the frame rate the kernel should display with each page flip as well, but that certainly isn't how the hardware is working now. Mostly the same applies for games as well, e.g. when you render a frame you usually render it for a certain timestamp. I can only find the EGL_ANDROID_presentation_time extension providing exactly this functionality. GLX_NV_present_video looks like it covers this as well, but it also includes a bunch of other stuff. I think 0 is a good first approximation of the number of applications used by an average Linux desktop user which make use of either of those extensions. Yeah, I agree that we don't have proper support for this on Linux desktop at the moment. But this is a chicken and egg problem. The comment that games render a frame for a certain timestamp was more on how games usually work internally. Additional to that are you sure it is such a hassle to implement this? I mean let us sum up what we need: 1. A representation for the new mode attributes, e.g. minimum and maximum vertical refresh rate. This is needed anyway to proper communicate the capabilities of the display device to userspace. 2. An extension to the page flip IOCTL to specify when exactly a flip should happen. As far as I can see that is what your patchset already did. The only difference is that you wanted to specify a certain vertical blank when the flip would happen while I would say we should use a monotonic timestamp (64bit ns since boot) for this. Right, the patch series you're referring to isn't directly related to this. 3. Expose this new functionality via the X11 Present extension and/or a corresponding Wayland extension. I unfortunately haven't pushed on this, but I already noted to Keith on an earlier version of the present extension that we should use a timestamps instead of vertical blank counters. But double checking the present extension, we indeed already have support for PresentOptionUST in it. So this should already be there. 4. Make use of 3. in the Gallium video state tracker code. Now we're done for the video playback case, phew! 5. Make use of 3. to implement EGL_ANDROID_presentation_time and/or GLX_NV_present_video. 6. Make game engines use 5. (A game engine can know when a frame will be ready for presentation when it
Re: [PATCH] Add freesync ioctl interface
On 09/08/16 06:31 PM, Christian König wrote: > Am 09.08.2016 um 10:27 schrieb Michel Dänzer: >> On 09/08/16 05:12 PM, Christian König wrote: >>> Am 09.08.2016 um 04:44 schrieb Michel Dänzer: >>> I was basically thinking out loud that doing this via different modes might be quite natural, *if* games allowed choosing a specific mode. But unfortunately they don't. For the video playback case, how do you envision the video player app communicating the refresh rate of the currently playing video to the kernel? >>> Again the kernel doesn't need to know the refresh rate. All the kernel >>> needs to know is when to do the page flip. >>> >>> So coming back to my example of a mode with 1920x1080 and 20-100Hz >>> refresh rate a classic modeline would then look something like this: >>> >>> Modeline "1920x1080_dynamic" 302.50 1920 2072 2280 2640 1080 1083 >>> 1088 5735 -hsync +vsync >>> >>> Note the high vertical total scan lines. Those basically reduce the >>> refresh rate from 100Hz (which this mode normally would have) down to >>> only 20Hz. >>> >>> Now what userspace does on each page flip is specifying when this flip >>> should happen, e.g. when the frame should be started to be scanned out. >>> We can either specify this as frame counter + vertical line of the >>> previous frame or as something like CLOCK_MONOTONIC (I think I would >>> prefer CLOCK_MONOTONIC, but that's not a strong opinion). >>> >>> In other words you put the whole concept upside down. It's no longer the >>> kernel which tells userspace when a vblank happened, but rather >>> userspace tells the kernel when it should happen (together with the >>> frame that should be displayed then). >> I guess that could work. Do video players set the VDPAU presentation >> time accurately enough for this? > > Yes, of course. We actually get a precise time stamp from the > application and need to calculate on which vblank to display it from that. > >> This would require extensive changes across the stack though, when more >> or less the same result could be achieved by just letting the kernel >> know what the current refresh rate is supposed to be, e.g. via output >> properties. > > The problem is that you don't have a refresh rate any more. Maybe not below the video decoding API level, but the video player app certainly knows the refresh rate? > Mostly the same applies for games as well, e.g. when you render a frame > you usually render it for a certain timestamp. I can only find the EGL_ANDROID_presentation_time extension providing exactly this functionality. GLX_NV_present_video looks like it covers this as well, but it also includes a bunch of other stuff. I think 0 is a good first approximation of the number of applications used by an average Linux desktop user which make use of either of those extensions. > Additional to that are you sure it is such a hassle to implement this? I > mean let us sum up what we need: > 1. A representation for the new mode attributes, e.g. minimum and > maximum vertical refresh rate. > > This is needed anyway to proper communicate the capabilities of the > display device to userspace. > > 2. An extension to the page flip IOCTL to specify when exactly a flip > should happen. > > As far as I can see that is what your patchset already did. The only > difference is that you wanted to specify a certain vertical blank when > the flip would happen while I would say we should use a monotonic > timestamp (64bit ns since boot) for this. Right, the patch series you're referring to isn't directly related to this. 3. Expose this new functionality via the X11 Present extension and/or a corresponding Wayland extension. 4. Make use of 3. in the Gallium video state tracker code. Now we're done for the video playback case, phew! 5. Make use of 3. to implement EGL_ANDROID_presentation_time and/or GLX_NV_present_video. 6. Make game engines use 5. (A game engine can know when a frame will be ready for presentation when it starts rendering it, so I'm not sure this functionality will be very useful for games) >> Also, this doesn't address the case of running (existing) games with >> variable refresh rate. > > Sure it does. For the current stack without any change a freesync > capable display device just looks like a normal monitor with a high > vertical refresh rate. You're saying current userspace would just see the maximum vertical refresh rate as the refresh rate? > When we add freesync support we just extend vblank_mode with a new enum > to enable it optionally for existing applications. "Just"... this will only be possible after the first 3 steps above. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] Add freesync ioctl interface
Am 09.08.2016 um 10:27 schrieb Michel Dänzer: On 09/08/16 05:12 PM, Christian König wrote: Am 09.08.2016 um 04:44 schrieb Michel Dänzer: I was basically thinking out loud that doing this via different modes might be quite natural, *if* games allowed choosing a specific mode. But unfortunately they don't. For the video playback case, how do you envision the video player app communicating the refresh rate of the currently playing video to the kernel? Again the kernel doesn't need to know the refresh rate. All the kernel needs to know is when to do the page flip. So coming back to my example of a mode with 1920x1080 and 20-100Hz refresh rate a classic modeline would then look something like this: Modeline "1920x1080_dynamic" 302.50 1920 2072 2280 2640 1080 1083 1088 5735 -hsync +vsync Note the high vertical total scan lines. Those basically reduce the refresh rate from 100Hz (which this mode normally would have) down to only 20Hz. Now what userspace does on each page flip is specifying when this flip should happen, e.g. when the frame should be started to be scanned out. We can either specify this as frame counter + vertical line of the previous frame or as something like CLOCK_MONOTONIC (I think I would prefer CLOCK_MONOTONIC, but that's not a strong opinion). In other words you put the whole concept upside down. It's no longer the kernel which tells userspace when a vblank happened, but rather userspace tells the kernel when it should happen (together with the frame that should be displayed then). I guess that could work. Do video players set the VDPAU presentation time accurately enough for this? Yes, of course. We actually get a precise time stamp from the application and need to calculate on which vblank to display it from that. This would require extensive changes across the stack though, when more or less the same result could be achieved by just letting the kernel know what the current refresh rate is supposed to be, e.g. via output properties. The problem is that you don't have a refresh rate any more. E.g. taking video playback as an example, the information you got here is that a certain frame should be displayed at a certain timestamp. Since our minimum granularity is still a vertical refresh line you usually alternate between two or three different vertical positions when you start with the next frame. Mostly the same applies for games as well, e.g. when you render a frame you usually render it for a certain timestamp. Additional to that are you sure it is such a hassle to implement this? I mean let us sum up what we need: 1. A representation for the new mode attributes, e.g. minimum and maximum vertical refresh rate. This is needed anyway to proper communicate the capabilities of the display device to userspace. 2. An extension to the page flip IOCTL to specify when exactly a flip should happen. As far as I can see that is what your patchset already did. The only difference is that you wanted to specify a certain vertical blank when the flip would happen while I would say we should use a monotonic timestamp (64bit ns since boot) for this. Also, this doesn't address the case of running (existing) games with variable refresh rate. Sure it does. For the current stack without any change a freesync capable display device just looks like a normal monitor with a high vertical refresh rate. When we add freesync support we just extend vblank_mode with a new enum to enable it optionally for existing applications. Regards, Christian. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] Add freesync ioctl interface
On 09/08/16 05:12 PM, Christian König wrote: > Am 09.08.2016 um 04:44 schrieb Michel Dänzer: > >> I was basically thinking out loud that doing this via different modes >> might be quite natural, *if* games allowed choosing a specific mode. >> But unfortunately they don't. For the video playback case, how do you >> envision the video player app communicating the refresh rate of the >> currently playing video to the kernel? > Again the kernel doesn't need to know the refresh rate. All the kernel > needs to know is when to do the page flip. > > So coming back to my example of a mode with 1920x1080 and 20-100Hz > refresh rate a classic modeline would then look something like this: > > Modeline "1920x1080_dynamic" 302.50 1920 2072 2280 2640 1080 1083 > 1088 5735 -hsync +vsync > > Note the high vertical total scan lines. Those basically reduce the > refresh rate from 100Hz (which this mode normally would have) down to > only 20Hz. > > Now what userspace does on each page flip is specifying when this flip > should happen, e.g. when the frame should be started to be scanned out. > We can either specify this as frame counter + vertical line of the > previous frame or as something like CLOCK_MONOTONIC (I think I would > prefer CLOCK_MONOTONIC, but that's not a strong opinion). > > In other words you put the whole concept upside down. It's no longer the > kernel which tells userspace when a vblank happened, but rather > userspace tells the kernel when it should happen (together with the > frame that should be displayed then). I guess that could work. Do video players set the VDPAU presentation time accurately enough for this? This would require extensive changes across the stack though, when more or less the same result could be achieved by just letting the kernel know what the current refresh rate is supposed to be, e.g. via output properties. Also, this doesn't address the case of running (existing) games with variable refresh rate. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] Add freesync ioctl interface
Am 09.08.2016 um 04:44 schrieb Michel Dänzer: On 08/08/16 06:55 PM, Christian König wrote: [SNIP] Who said that games need to be able to enable/disable it in the kernel side? The assumption is that some games (and maybe other apps, e.g. compositors) won't work correctly with variable refresh rate. So there needs to be some way for the user to decide whether or not to use it for a given app. Completely agree on that, but this wasn't what I wanted to say. My issue here is why does the kernel needs to know about this? As far as I can see userspace should be able to handle this perfectly fine on it's own. I was basically thinking out loud that doing this via different modes might be quite natural, *if* games allowed choosing a specific mode. But unfortunately they don't. For the video playback case, how do you envision the video player app communicating the refresh rate of the currently playing video to the kernel? Again the kernel doesn't need to know the refresh rate. All the kernel needs to know is when to do the page flip. So coming back to my example of a mode with 1920x1080 and 20-100Hz refresh rate a classic modeline would then look something like this: Modeline "1920x1080_dynamic" 302.50 1920 2072 2280 2640 1080 1083 1088 5735 -hsync +vsync Note the high vertical total scan lines. Those basically reduce the refresh rate from 100Hz (which this mode normally would have) down to only 20Hz. Now what userspace does on each page flip is specifying when this flip should happen, e.g. when the frame should be started to be scanned out. We can either specify this as frame counter + vertical line of the previous frame or as something like CLOCK_MONOTONIC (I think I would prefer CLOCK_MONOTONIC, but that's not a strong opinion). In other words you put the whole concept upside down. It's no longer the kernel which tells userspace when a vblank happened, but rather userspace tells the kernel when it should happen (together with the frame that should be displayed then). Regards, Christian. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] Add freesync ioctl interface
On 08/08/16 06:55 PM, Christian König wrote: > Am 08.08.2016 um 09:43 schrieb Michel Dänzer: >> On 04.08.2016 17:22, Christian König wrote: >>> Am 04.08.2016 um 08:41 schrieb Michel Dänzer: On 03.08.2016 10:04, Dave Airlie wrote: > The goal here is merely to allow running existing apps with variable refresh rate, which just requires some kind of toggle(s) to enable/disable it. That said, I also see some issues with this patch: There's a bit of a conflation between "FreeSync" and "fullscreen" concepts. I think at this point it's really about a sort of an "is FreeSync allowed?" state rather than about fullscreen. >>> I would say we first of all need a new flag for drm_mode_modeinfo to >>> note if a certain mode is a freesync mode or not and what the min/max >>> parameters are. >>> It might be nice to track the "is FreeSync allowed?" state per-CRTC, as I wonder if FreeSync might be useful e.g. for smoother TearFree operation. And if it's just a per-CRTC state, something like an output property might be more appropriate than a dedicated ioctl. >>> That will obvious work as well, but essentially freesync is a parameter >>> of the video mode in use if I'm not completely mistaken. >> Hmm, that's an interesting point. Enabling FreeSync via special modes >> sounds quite natural from a user POV. Unfortunately, games tend to only >> let the user choose a resolution, not a specific mode. > Who said that games need to be able to enable/disable it in the kernel > side? The assumption is that some games (and maybe other apps, e.g. compositors) won't work correctly with variable refresh rate. So there needs to be some way for the user to decide whether or not to use it for a given app. I was basically thinking out loud that doing this via different modes might be quite natural, *if* games allowed choosing a specific mode. But unfortunately they don't. For the video playback case, how do you envision the video player app communicating the refresh rate of the currently playing video to the kernel? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] Add freesync ioctl interface
Am 08.08.2016 um 09:43 schrieb Michel Dänzer:
On 04.08.2016 17:22, Christian König wrote:
Am 04.08.2016 um 08:41 schrieb Michel Dänzer:
On 03.08.2016 10:04, Dave Airlie wrote:
On 2 August 2016 at 12:26, Hawking Zhang wrote:
@@ -706,4 +708,17 @@ struct drm_amdgpu_virtual_range {
uint64_t start;
uint64_t end;
};
+
+/*
+ * Definition of free sync enter and exit signals
+ * We may have more options in the future
+ */
+#define AMDGPU_FREESYNC_FULLSCREEN_ENTER1
+#define AMDGPU_FREESYNC_FULLSCREEN_EXIT 2
+
+struct drm_amdgpu_freesync {
+__u32 op; /*
AMDGPU_FREESYNC_FULLSCREEN_ENTER or */
+/*
AMDGPU_FREESYNC_FULLSCREEN_ENTER */
+__u32 spare[7];
+};
#endif
Isn't freesync meant to be a generic non-driver useful thing?
This should be integrated with atomic modesetting API or just the KMS
APIs.
I don't see that as required or even particularly useful until there's
an API which apps can use to control variable refresh rate.
VDPAU already does this quite well [...]
By explicitly specifying the earliest presentation time for each frame
AFAICT? While that seems very flexible, I'm not sure it's particularly
good for smooth and stable playback. Seems like overriding the refresh
rate to (a multiple of) the video frame rate might be better for that.
That's what players like Kodi actually do at the moment.
But try to enable it and the do a bit zapping between PAL and NTSC TV
channels, believe me you are going to hate it with most current display
devices.
There are only a very few televisions which can do the frame rate switch
fast enough that you won't either get multiple seconds blackness or a
rather bad headache in between.
With freesync you can switch between 50Hz, 60Hz or whatever frame rate
you like without changing the video mode.
The goal
here is merely to allow running existing apps with variable refresh
rate, which just requires some kind of toggle(s) to enable/disable it.
That said, I also see some issues with this patch:
There's a bit of a conflation between "FreeSync" and "fullscreen"
concepts. I think at this point it's really about a sort of an "is
FreeSync allowed?" state rather than about fullscreen.
I would say we first of all need a new flag for drm_mode_modeinfo to
note if a certain mode is a freesync mode or not and what the min/max
parameters are.
It might be nice to track the "is FreeSync allowed?" state per-CRTC, as
I wonder if FreeSync might be useful e.g. for smoother TearFree
operation.
And if it's just a per-CRTC state, something like an output property
might be more appropriate than a dedicated ioctl.
That will obvious work as well, but essentially freesync is a parameter
of the video mode in use if I'm not completely mistaken.
Hmm, that's an interesting point. Enabling FreeSync via special modes
sounds quite natural from a user POV. Unfortunately, games tend to only
let the user choose a resolution, not a specific mode.
Who said that games need to be able to enable/disable it in the kernel side?
Maybe take a step back and look at how freesync works:
1. You have a video mode with a certain resolution and the maximum
refresh rate the display device can handle. Let's say for example
1920x1080@100.
2. Now the vertical blank period of this mode is extended which
practically lowers the refresh rate to the minimum the display device
can handle. E.g. you end up with a mode of 1920x1080@20 for example.
3. When a page flip arrives while we are in the vertical blank period
the blank is aborted and the video hardware starts pushing out the new
frame immediately.
This practically gives you a mode with a dynamic refresh rate between 20
and 100Hz.
Now when the game requests a fixed frame rate of 30Hz for example the
kernel doesn't need to know about that, all it needs to know is when to
do the next flip. E.g. you say always flip at vertical scan line X and
so you get 30fps.
Regards,
Christian.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] Add freesync ioctl interface
On 04.08.2016 17:22, Christian König wrote:
> Am 04.08.2016 um 08:41 schrieb Michel Dänzer:
>> On 03.08.2016 10:04, Dave Airlie wrote:
>>> On 2 August 2016 at 12:26, Hawking Zhang wrote:
@@ -706,4 +708,17 @@ struct drm_amdgpu_virtual_range {
uint64_t start;
uint64_t end;
};
+
+/*
+ * Definition of free sync enter and exit signals
+ * We may have more options in the future
+ */
+#define AMDGPU_FREESYNC_FULLSCREEN_ENTER1
+#define AMDGPU_FREESYNC_FULLSCREEN_EXIT 2
+
+struct drm_amdgpu_freesync {
+__u32 op; /*
AMDGPU_FREESYNC_FULLSCREEN_ENTER or */
+/*
AMDGPU_FREESYNC_FULLSCREEN_ENTER */
+__u32 spare[7];
+};
#endif
>>> Isn't freesync meant to be a generic non-driver useful thing?
>>>
>>> This should be integrated with atomic modesetting API or just the KMS
>>> APIs.
>> I don't see that as required or even particularly useful until there's
>> an API which apps can use to control variable refresh rate.
>
> VDPAU already does this quite well [...]
By explicitly specifying the earliest presentation time for each frame
AFAICT? While that seems very flexible, I'm not sure it's particularly
good for smooth and stable playback. Seems like overriding the refresh
rate to (a multiple of) the video frame rate might be better for that.
>> The goal
>> here is merely to allow running existing apps with variable refresh
>> rate, which just requires some kind of toggle(s) to enable/disable it.
>>
>>
>> That said, I also see some issues with this patch:
>>
>> There's a bit of a conflation between "FreeSync" and "fullscreen"
>> concepts. I think at this point it's really about a sort of an "is
>> FreeSync allowed?" state rather than about fullscreen.
>
> I would say we first of all need a new flag for drm_mode_modeinfo to
> note if a certain mode is a freesync mode or not and what the min/max
> parameters are.
>
>>
>> It might be nice to track the "is FreeSync allowed?" state per-CRTC, as
>> I wonder if FreeSync might be useful e.g. for smoother TearFree
>> operation.
>>
>> And if it's just a per-CRTC state, something like an output property
>> might be more appropriate than a dedicated ioctl.
>
> That will obvious work as well, but essentially freesync is a parameter
> of the video mode in use if I'm not completely mistaken.
Hmm, that's an interesting point. Enabling FreeSync via special modes
sounds quite natural from a user POV. Unfortunately, games tend to only
let the user choose a resolution, not a specific mode.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] Add freesync ioctl interface
Am 04.08.2016 um 08:41 schrieb Michel Dänzer:
On 03.08.2016 10:04, Dave Airlie wrote:
On 2 August 2016 at 12:26, Hawking Zhang wrote:
Change-Id: I38cb3a80e75a904cee875ae47bc0a39a3d471aca
Signed-off-by: Hawking Zhang
---
include/drm/amdgpu_drm.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index 46a3c40..a4f816c 100644
--- a/include/drm/amdgpu_drm.h
+++ b/include/drm/amdgpu_drm.h
@@ -48,6 +48,7 @@
#define DRM_AMDGPU_GEM_USERPTR 0x11
#define DRM_AMDGPU_WAIT_FENCES 0x12
#define DRM_AMDGPU_GEM_FIND_BO 0x13
+#define DRM_AMDGPU_FREESYNC 0x14
#define DRM_IOCTL_AMDGPU_GEM_CREATEDRM_IOWR(DRM_COMMAND_BASE +
DRM_AMDGPU_GEM_CREATE, union drm_amdgpu_gem_create)
#define DRM_IOCTL_AMDGPU_GEM_MMAP DRM_IOWR(DRM_COMMAND_BASE +
DRM_AMDGPU_GEM_MMAP, union drm_amdgpu_gem_mmap)
@@ -63,6 +64,7 @@
#define DRM_IOCTL_AMDGPU_GEM_USERPTR DRM_IOWR(DRM_COMMAND_BASE +
DRM_AMDGPU_GEM_USERPTR, struct drm_amdgpu_gem_userptr)
#define DRM_IOCTL_AMDGPU_WAIT_FENCES DRM_IOWR(DRM_COMMAND_BASE +
DRM_AMDGPU_WAIT_FENCES, union drm_amdgpu_wait_fences)
#define DRM_IOCTL_AMDGPU_GEM_FIND_BO DRM_IOWR(DRM_COMMAND_BASE +
DRM_AMDGPU_GEM_FIND_BO, struct drm_amdgpu_gem_find_bo)
+#define DRM_IOCTL_AMDGPU_FREESYNC DRM_IOWR(DRM_COMMAND_BASE +
DRM_AMDGPU_FREESYNC, struct drm_amdgpu_freesync)
#define AMDGPU_GEM_DOMAIN_CPU 0x1
#define AMDGPU_GEM_DOMAIN_GTT 0x2
@@ -706,4 +708,17 @@ struct drm_amdgpu_virtual_range {
uint64_t start;
uint64_t end;
};
+
+/*
+ * Definition of free sync enter and exit signals
+ * We may have more options in the future
+ */
+#define AMDGPU_FREESYNC_FULLSCREEN_ENTER1
+#define AMDGPU_FREESYNC_FULLSCREEN_EXIT 2
+
+struct drm_amdgpu_freesync {
+__u32 op; /* AMDGPU_FREESYNC_FULLSCREEN_ENTER or
*/
+/* AMDGPU_FREESYNC_FULLSCREEN_ENTER */
+__u32 spare[7];
+};
#endif
Isn't freesync meant to be a generic non-driver useful thing?
This should be integrated with atomic modesetting API or just the KMS APIs.
I don't see that as required or even particularly useful until there's
an API which apps can use to control variable refresh rate.
VDPAU already does this quite well and for OpenGL you usually say that
you want the next frame to be pushed out as fast as possible when you
don't use any additional extensions to set that.
The goal
here is merely to allow running existing apps with variable refresh
rate, which just requires some kind of toggle(s) to enable/disable it.
That said, I also see some issues with this patch:
There's a bit of a conflation between "FreeSync" and "fullscreen"
concepts. I think at this point it's really about a sort of an "is
FreeSync allowed?" state rather than about fullscreen.
I would say we first of all need a new flag for drm_mode_modeinfo to
note if a certain mode is a freesync mode or not and what the min/max
parameters are.
It might be nice to track the "is FreeSync allowed?" state per-CRTC, as
I wonder if FreeSync might be useful e.g. for smoother TearFree operation.
And if it's just a per-CRTC state, something like an output property
might be more appropriate than a dedicated ioctl.
That will obvious work as well, but essentially freesync is a parameter
of the video mode in use if I'm not completely mistaken.
Regards,
Christian.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] Add freesync ioctl interface
On 03.08.2016 10:04, Dave Airlie wrote:
> On 2 August 2016 at 12:26, Hawking Zhang wrote:
>> Change-Id: I38cb3a80e75a904cee875ae47bc0a39a3d471aca
>> Signed-off-by: Hawking Zhang
>> ---
>> include/drm/amdgpu_drm.h | 15 +++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
>> index 46a3c40..a4f816c 100644
>> --- a/include/drm/amdgpu_drm.h
>> +++ b/include/drm/amdgpu_drm.h
>> @@ -48,6 +48,7 @@
>> #define DRM_AMDGPU_GEM_USERPTR 0x11
>> #define DRM_AMDGPU_WAIT_FENCES 0x12
>> #define DRM_AMDGPU_GEM_FIND_BO 0x13
>> +#define DRM_AMDGPU_FREESYNC 0x14
>>
>> #define DRM_IOCTL_AMDGPU_GEM_CREATEDRM_IOWR(DRM_COMMAND_BASE +
>> DRM_AMDGPU_GEM_CREATE, union drm_amdgpu_gem_create)
>> #define DRM_IOCTL_AMDGPU_GEM_MMAP DRM_IOWR(DRM_COMMAND_BASE +
>> DRM_AMDGPU_GEM_MMAP, union drm_amdgpu_gem_mmap)
>> @@ -63,6 +64,7 @@
>> #define DRM_IOCTL_AMDGPU_GEM_USERPTR DRM_IOWR(DRM_COMMAND_BASE +
>> DRM_AMDGPU_GEM_USERPTR, struct drm_amdgpu_gem_userptr)
>> #define DRM_IOCTL_AMDGPU_WAIT_FENCES DRM_IOWR(DRM_COMMAND_BASE +
>> DRM_AMDGPU_WAIT_FENCES, union drm_amdgpu_wait_fences)
>> #define DRM_IOCTL_AMDGPU_GEM_FIND_BO DRM_IOWR(DRM_COMMAND_BASE +
>> DRM_AMDGPU_GEM_FIND_BO, struct drm_amdgpu_gem_find_bo)
>> +#define DRM_IOCTL_AMDGPU_FREESYNC DRM_IOWR(DRM_COMMAND_BASE +
>> DRM_AMDGPU_FREESYNC, struct drm_amdgpu_freesync)
>>
>> #define AMDGPU_GEM_DOMAIN_CPU 0x1
>> #define AMDGPU_GEM_DOMAIN_GTT 0x2
>> @@ -706,4 +708,17 @@ struct drm_amdgpu_virtual_range {
>> uint64_t start;
>> uint64_t end;
>> };
>> +
>> +/*
>> + * Definition of free sync enter and exit signals
>> + * We may have more options in the future
>> + */
>> +#define AMDGPU_FREESYNC_FULLSCREEN_ENTER1
>> +#define AMDGPU_FREESYNC_FULLSCREEN_EXIT 2
>> +
>> +struct drm_amdgpu_freesync {
>> +__u32 op; /* AMDGPU_FREESYNC_FULLSCREEN_ENTER
>> or */
>> +/* AMDGPU_FREESYNC_FULLSCREEN_ENTER
>> */
>> +__u32 spare[7];
>> +};
>> #endif
>
> Isn't freesync meant to be a generic non-driver useful thing?
>
> This should be integrated with atomic modesetting API or just the KMS APIs.
I don't see that as required or even particularly useful until there's
an API which apps can use to control variable refresh rate. The goal
here is merely to allow running existing apps with variable refresh
rate, which just requires some kind of toggle(s) to enable/disable it.
That said, I also see some issues with this patch:
There's a bit of a conflation between "FreeSync" and "fullscreen"
concepts. I think at this point it's really about a sort of an "is
FreeSync allowed?" state rather than about fullscreen.
It might be nice to track the "is FreeSync allowed?" state per-CRTC, as
I wonder if FreeSync might be useful e.g. for smoother TearFree operation.
And if it's just a per-CRTC state, something like an output property
might be more appropriate than a dedicated ioctl.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] Add freesync ioctl interface
Am 03.08.2016 um 03:04 schrieb Dave Airlie:
On 2 August 2016 at 12:26, Hawking Zhang wrote:
Change-Id: I38cb3a80e75a904cee875ae47bc0a39a3d471aca
Signed-off-by: Hawking Zhang
---
include/drm/amdgpu_drm.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index 46a3c40..a4f816c 100644
--- a/include/drm/amdgpu_drm.h
+++ b/include/drm/amdgpu_drm.h
@@ -48,6 +48,7 @@
#define DRM_AMDGPU_GEM_USERPTR 0x11
#define DRM_AMDGPU_WAIT_FENCES 0x12
#define DRM_AMDGPU_GEM_FIND_BO 0x13
+#define DRM_AMDGPU_FREESYNC 0x14
#define DRM_IOCTL_AMDGPU_GEM_CREATEDRM_IOWR(DRM_COMMAND_BASE +
DRM_AMDGPU_GEM_CREATE, union drm_amdgpu_gem_create)
#define DRM_IOCTL_AMDGPU_GEM_MMAP DRM_IOWR(DRM_COMMAND_BASE +
DRM_AMDGPU_GEM_MMAP, union drm_amdgpu_gem_mmap)
@@ -63,6 +64,7 @@
#define DRM_IOCTL_AMDGPU_GEM_USERPTR DRM_IOWR(DRM_COMMAND_BASE +
DRM_AMDGPU_GEM_USERPTR, struct drm_amdgpu_gem_userptr)
#define DRM_IOCTL_AMDGPU_WAIT_FENCES DRM_IOWR(DRM_COMMAND_BASE +
DRM_AMDGPU_WAIT_FENCES, union drm_amdgpu_wait_fences)
#define DRM_IOCTL_AMDGPU_GEM_FIND_BO DRM_IOWR(DRM_COMMAND_BASE +
DRM_AMDGPU_GEM_FIND_BO, struct drm_amdgpu_gem_find_bo)
+#define DRM_IOCTL_AMDGPU_FREESYNC DRM_IOWR(DRM_COMMAND_BASE +
DRM_AMDGPU_FREESYNC, struct drm_amdgpu_freesync)
#define AMDGPU_GEM_DOMAIN_CPU 0x1
#define AMDGPU_GEM_DOMAIN_GTT 0x2
@@ -706,4 +708,17 @@ struct drm_amdgpu_virtual_range {
uint64_t start;
uint64_t end;
};
+
+/*
+ * Definition of free sync enter and exit signals
+ * We may have more options in the future
+ */
+#define AMDGPU_FREESYNC_FULLSCREEN_ENTER1
+#define AMDGPU_FREESYNC_FULLSCREEN_EXIT 2
+
+struct drm_amdgpu_freesync {
+__u32 op; /* AMDGPU_FREESYNC_FULLSCREEN_ENTER or
*/
+/* AMDGPU_FREESYNC_FULLSCREEN_ENTER */
+__u32 spare[7];
+};
#endif
Isn't freesync meant to be a generic non-driver useful thing?
Yeah, agree. Actually the general idea is so old that I've done similar
things on the very first computer I had.
Basically instead of begin and end of the vertical blanking period
you've got begin and max/min end.
Every hardware which can a) generate an interrupt when vertical blanking
starts and b) adjust the vertical scan out position by the CPU should be
able to implement that.
Regards,
Christian.
This should be integrated with atomic modesetting API or just the KMS APIs.
Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] Add freesync ioctl interface
On 2 August 2016 at 12:26, Hawking Zhang wrote:
> Change-Id: I38cb3a80e75a904cee875ae47bc0a39a3d471aca
> Signed-off-by: Hawking Zhang
> ---
> include/drm/amdgpu_drm.h | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
> index 46a3c40..a4f816c 100644
> --- a/include/drm/amdgpu_drm.h
> +++ b/include/drm/amdgpu_drm.h
> @@ -48,6 +48,7 @@
> #define DRM_AMDGPU_GEM_USERPTR 0x11
> #define DRM_AMDGPU_WAIT_FENCES 0x12
> #define DRM_AMDGPU_GEM_FIND_BO 0x13
> +#define DRM_AMDGPU_FREESYNC 0x14
>
> #define DRM_IOCTL_AMDGPU_GEM_CREATEDRM_IOWR(DRM_COMMAND_BASE +
> DRM_AMDGPU_GEM_CREATE, union drm_amdgpu_gem_create)
> #define DRM_IOCTL_AMDGPU_GEM_MMAP DRM_IOWR(DRM_COMMAND_BASE +
> DRM_AMDGPU_GEM_MMAP, union drm_amdgpu_gem_mmap)
> @@ -63,6 +64,7 @@
> #define DRM_IOCTL_AMDGPU_GEM_USERPTR DRM_IOWR(DRM_COMMAND_BASE +
> DRM_AMDGPU_GEM_USERPTR, struct drm_amdgpu_gem_userptr)
> #define DRM_IOCTL_AMDGPU_WAIT_FENCES DRM_IOWR(DRM_COMMAND_BASE +
> DRM_AMDGPU_WAIT_FENCES, union drm_amdgpu_wait_fences)
> #define DRM_IOCTL_AMDGPU_GEM_FIND_BO DRM_IOWR(DRM_COMMAND_BASE +
> DRM_AMDGPU_GEM_FIND_BO, struct drm_amdgpu_gem_find_bo)
> +#define DRM_IOCTL_AMDGPU_FREESYNC DRM_IOWR(DRM_COMMAND_BASE +
> DRM_AMDGPU_FREESYNC, struct drm_amdgpu_freesync)
>
> #define AMDGPU_GEM_DOMAIN_CPU 0x1
> #define AMDGPU_GEM_DOMAIN_GTT 0x2
> @@ -706,4 +708,17 @@ struct drm_amdgpu_virtual_range {
> uint64_t start;
> uint64_t end;
> };
> +
> +/*
> + * Definition of free sync enter and exit signals
> + * We may have more options in the future
> + */
> +#define AMDGPU_FREESYNC_FULLSCREEN_ENTER1
> +#define AMDGPU_FREESYNC_FULLSCREEN_EXIT 2
> +
> +struct drm_amdgpu_freesync {
> +__u32 op; /* AMDGPU_FREESYNC_FULLSCREEN_ENTER
> or */
> +/* AMDGPU_FREESYNC_FULLSCREEN_ENTER
> */
> +__u32 spare[7];
> +};
> #endif
Isn't freesync meant to be a generic non-driver useful thing?
This should be integrated with atomic modesetting API or just the KMS APIs.
Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH] Add freesync ioctl interface
> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Zhang, Hawking > Sent: Tuesday, August 02, 2016 12:14 AM > To: Michel Dänzer > Cc: amd-gfx@lists.freedesktop.org > Subject: RE: [PATCH] Add freesync ioctl interface > > The kernel branch has already merged the ioctl implementation. I'm okay to > keep it internal although. The kernel bits are in dal. You can see them publically in my public mirror of amd-staging-4.6 IIRC. Alex > > > Regards, > Hawking > > -Original Message- > From: Michel Dänzer [mailto:mic...@daenzer.net] > Sent: Tuesday, August 02, 2016 11:32 > To: Zhang, Hawking > Cc: amd-gfx@lists.freedesktop.org > Subject: Re: [PATCH] Add freesync ioctl interface > > On 02.08.2016 12:12, Zhang, Hawking wrote: > > The implementation is as [PATCH] Enable/disable freesync when > > enter/exit fullscreen game. > > I mean an implementation of the ioctl in the kernel driver. > > > P.S. Please run the following command in each Git repository, so that the > [PATCH] prefix includes which repository a patch is for: > > git config format.subjectprefix "PATCH $(basename $PWD)" > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer > ___ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH] Add freesync ioctl interface
The kernel branch has already merged the ioctl implementation. I'm okay to keep it internal although. Regards, Hawking -Original Message- From: Michel Dänzer [mailto:mic...@daenzer.net] Sent: Tuesday, August 02, 2016 11:32 To: Zhang, Hawking Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] Add freesync ioctl interface On 02.08.2016 12:12, Zhang, Hawking wrote: > The implementation is as [PATCH] Enable/disable freesync when > enter/exit fullscreen game. I mean an implementation of the ioctl in the kernel driver. P.S. Please run the following command in each Git repository, so that the [PATCH] prefix includes which repository a patch is for: git config format.subjectprefix "PATCH $(basename $PWD)" -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] Add freesync ioctl interface
On 02.08.2016 12:12, Zhang, Hawking wrote: > The implementation is as [PATCH] Enable/disable freesync when > enter/exit fullscreen game. I mean an implementation of the ioctl in the kernel driver. P.S. Please run the following command in each Git repository, so that the [PATCH] prefix includes which repository a patch is for: git config format.subjectprefix "PATCH $(basename $PWD)" -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH] Add freesync ioctl interface
The implementation is as [PATCH] Enable/disable freesync when enter/exit fullscreen game. Please take a review Regards, Hawking -Original Message- From: Michel Dänzer [mailto:mic...@daenzer.net] Sent: Tuesday, August 02, 2016 11:11 To: Zhang, Hawking Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] Add freesync ioctl interface This cannot go upstream without an implementation making use of it. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH] Add freesync ioctl interface
The implementation is as [PATCH] Enable/disable freesync when enter/exit fullscreen game. Please take a review Regards, Hawking -Original Message- From: Michel Dänzer [mailto:mic...@daenzer.net] Sent: Tuesday, August 02, 2016 11:11 To: Zhang, Hawking Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] Add freesync ioctl interface This cannot go upstream without an implementation making use of it. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] Add freesync ioctl interface
This cannot go upstream without an implementation making use of it. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] Add freesync ioctl interface
Change-Id: I38cb3a80e75a904cee875ae47bc0a39a3d471aca
Signed-off-by: Hawking Zhang
---
include/drm/amdgpu_drm.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index 46a3c40..a4f816c 100644
--- a/include/drm/amdgpu_drm.h
+++ b/include/drm/amdgpu_drm.h
@@ -48,6 +48,7 @@
#define DRM_AMDGPU_GEM_USERPTR 0x11
#define DRM_AMDGPU_WAIT_FENCES 0x12
#define DRM_AMDGPU_GEM_FIND_BO 0x13
+#define DRM_AMDGPU_FREESYNC 0x14
#define DRM_IOCTL_AMDGPU_GEM_CREATEDRM_IOWR(DRM_COMMAND_BASE +
DRM_AMDGPU_GEM_CREATE, union drm_amdgpu_gem_create)
#define DRM_IOCTL_AMDGPU_GEM_MMAP DRM_IOWR(DRM_COMMAND_BASE +
DRM_AMDGPU_GEM_MMAP, union drm_amdgpu_gem_mmap)
@@ -63,6 +64,7 @@
#define DRM_IOCTL_AMDGPU_GEM_USERPTR DRM_IOWR(DRM_COMMAND_BASE +
DRM_AMDGPU_GEM_USERPTR, struct drm_amdgpu_gem_userptr)
#define DRM_IOCTL_AMDGPU_WAIT_FENCES DRM_IOWR(DRM_COMMAND_BASE +
DRM_AMDGPU_WAIT_FENCES, union drm_amdgpu_wait_fences)
#define DRM_IOCTL_AMDGPU_GEM_FIND_BO DRM_IOWR(DRM_COMMAND_BASE +
DRM_AMDGPU_GEM_FIND_BO, struct drm_amdgpu_gem_find_bo)
+#define DRM_IOCTL_AMDGPU_FREESYNC DRM_IOWR(DRM_COMMAND_BASE +
DRM_AMDGPU_FREESYNC, struct drm_amdgpu_freesync)
#define AMDGPU_GEM_DOMAIN_CPU 0x1
#define AMDGPU_GEM_DOMAIN_GTT 0x2
@@ -706,4 +708,17 @@ struct drm_amdgpu_virtual_range {
uint64_t start;
uint64_t end;
};
+
+/*
+ * Definition of free sync enter and exit signals
+ * We may have more options in the future
+ */
+#define AMDGPU_FREESYNC_FULLSCREEN_ENTER1
+#define AMDGPU_FREESYNC_FULLSCREEN_EXIT 2
+
+struct drm_amdgpu_freesync {
+__u32 op; /* AMDGPU_FREESYNC_FULLSCREEN_ENTER or
*/
+/* AMDGPU_FREESYNC_FULLSCREEN_ENTER */
+__u32 spare[7];
+};
#endif
--
2.7.4
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
