[PATCH] Add freesync ioctl interface

[PATCH] Add freesync ioctl interface

[Hawking Zhang]

Change-Id: I38cb3a80e75a904cee875ae47bc0a39a3d471aca
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
---
 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_CREATE	DRM_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_ENTER                1
+#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

Re: [PATCH] Add freesync ioctl interface

[Michel Dänzer]

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

[Zhang, Hawking]

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:michel@daenzer.net] 
Sent: Tuesday, August 02, 2016 11:11
To: Zhang, Hawking <Hawking.Zhang@amd.com>
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

[Zhang, Hawking]

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:michel@daenzer.net] 
Sent: Tuesday, August 02, 2016 11:11
To: Zhang, Hawking <Hawking.Zhang@amd.com>
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

[Michel Dänzer]

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

[Zhang, Hawking]

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:michel@daenzer.net] 
Sent: Tuesday, August 02, 2016 11:32
To: Zhang, Hawking <Hawking.Zhang@amd.com>
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

[Deucher, Alexander]

> -----Original Message-----
> From: amd-gfx [mailto:amd-gfx-bounces@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:michel@daenzer.net]
> Sent: Tuesday, August 02, 2016 11:32
> To: Zhang, Hawking <Hawking.Zhang@amd.com>
> 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

[Dave Airlie]

On 2 August 2016 at 12:26, Hawking Zhang <Hawking.Zhang@amd.com> wrote:
> Change-Id: I38cb3a80e75a904cee875ae47bc0a39a3d471aca
> Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
> ---
>  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_CREATE    DRM_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_ENTER                1
> +#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

[Christian König]

Am 03.08.2016 um 03:04 schrieb Dave Airlie:
> On 2 August 2016 at 12:26, Hawking Zhang <Hawking.Zhang@amd.com> wrote:
>> Change-Id: I38cb3a80e75a904cee875ae47bc0a39a3d471aca
>> Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
>> ---
>>   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_CREATE    DRM_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_ENTER                1
>> +#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

[Michel Dänzer]

On 03.08.2016 10:04, Dave Airlie wrote:
> On 2 August 2016 at 12:26, Hawking Zhang <Hawking.Zhang@amd.com> wrote:
>> Change-Id: I38cb3a80e75a904cee875ae47bc0a39a3d471aca
>> Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
>> ---
>>  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_CREATE    DRM_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_ENTER                1
>> +#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

[Christian König]

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 <Hawking.Zhang@amd.com> wrote:
>>> Change-Id: I38cb3a80e75a904cee875ae47bc0a39a3d471aca
>>> Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
>>> ---
>>>   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_CREATE    DRM_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_ENTER                1
>>> +#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

[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 <Hawking.Zhang@amd.com> 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_ENTER                1
>>>> +#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

[Christian König]

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 <Hawking.Zhang@amd.com> 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_ENTER                1
>>>>> +#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

[Michel Dänzer]

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

[Christian König]

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

[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?

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

[Christian König]

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

[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?


> 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

[Christian König]

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 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?

I think so. I mean the minimum is usually rather low, e.g. between 20 
and 30Hz.

>
>
>> 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.

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.

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

[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:
>>>>> 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
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] Add freesync ioctl interface

[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

Re: [PATCH] Add freesync ioctl interface

[Ernst Sjöstrand]

[-- Attachment #1.1: Type: text/plain, Size: 3896 bytes --]

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 <michel-otUistvHUpPR7s880joybQ@public.gmane.org>:

> 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-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>

[-- Attachment #1.2: Type: text/html, Size: 5180 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] Add freesync ioctl interface

[Christian König]

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

[Deucher, Alexander]

[-- Attachment #1.1: Type: text/plain, Size: 4197 bytes --]

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-bounces@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 <michel@daenzer.net<mailto:michel@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


[-- Attachment #1.2: Type: text/html, Size: 9000 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx