[PATCH] drm: document that user-space should avoid parsing EDIDs

[PATCH] drm: document that user-space should avoid parsing EDIDs

[Simon Ser]

User-space should avoid parsing EDIDs for metadata already exposed via
other KMS interfaces and properties. For instance, user-space should not
try to extract a list of modes from the EDID: the kernel might mutate
the mode list (because of link capabilities or quirks for instance).

Other metadata not exposed by KMS can be parsed by user-space. This
includes for instance monitor identification (make/model/serial) and
supported color-spaces.

Signed-off-by: Simon Ser <contact@emersion.fr>
Suggested-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/drm_connector.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 717c4e7271b0..00e58fd2d292 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -960,6 +960,10 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
  * 	drm_connector_update_edid_property(), usually after having parsed
  * 	the EDID using drm_add_edid_modes(). Userspace cannot change this
  * 	property.
+ *
+ * 	User-space should not parse the EDID to obtain information exposed via
+ * 	other KMS properties. For instance, user-space should not try to parse
+ * 	mode lists from the EDID.
  * DPMS:
  * 	Legacy property for setting the power state of the connector. For atomic
  * 	drivers this is only provided for backwards compatibility with existing
-- 
2.28.0


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: document that user-space should avoid parsing EDIDs

[Daniel Vetter]

On Fri, Oct 9, 2020 at 11:24 AM Simon Ser <contact@emersion.fr> wrote:
>
> User-space should avoid parsing EDIDs for metadata already exposed via
> other KMS interfaces and properties. For instance, user-space should not
> try to extract a list of modes from the EDID: the kernel might mutate
> the mode list (because of link capabilities or quirks for instance).
>
> Other metadata not exposed by KMS can be parsed by user-space. This
> includes for instance monitor identification (make/model/serial) and
> supported color-spaces.
>
> Signed-off-by: Simon Ser <contact@emersion.fr>
> Suggested-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

> ---
>  drivers/gpu/drm/drm_connector.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 717c4e7271b0..00e58fd2d292 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -960,6 +960,10 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>   *     drm_connector_update_edid_property(), usually after having parsed
>   *     the EDID using drm_add_edid_modes(). Userspace cannot change this
>   *     property.
> + *
> + *     User-space should not parse the EDID to obtain information exposed via
> + *     other KMS properties. For instance, user-space should not try to parse
> + *     mode lists from the EDID.
>   * DPMS:
>   *     Legacy property for setting the power state of the connector. For atomic
>   *     drivers this is only provided for backwards compatibility with existing
> --
> 2.28.0
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: document that user-space should avoid parsing EDIDs

[Thomas Zimmermann]

[-- Attachment #1.1.1: Type: text/plain, Size: 2159 bytes --]

Hi

Am 09.10.20 um 11:24 schrieb Simon Ser:
> User-space should avoid parsing EDIDs for metadata already exposed via
> other KMS interfaces and properties. For instance, user-space should not
> try to extract a list of modes from the EDID: the kernel might mutate
> the mode list (because of link capabilities or quirks for instance).
> 
> Other metadata not exposed by KMS can be parsed by user-space. This
> includes for instance monitor identification (make/model/serial) and
> supported color-spaces.
> 
> Signed-off-by: Simon Ser <contact@emersion.fr>
> Suggested-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/drm_connector.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 717c4e7271b0..00e58fd2d292 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -960,6 +960,10 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>   * 	drm_connector_update_edid_property(), usually after having parsed
>   * 	the EDID using drm_add_edid_modes(). Userspace cannot change this
>   * 	property.
> + *
> + * 	User-space should not parse the EDID to obtain information exposed via
> + * 	other KMS properties. For instance, user-space should not try to parse
> + * 	mode lists from the EDID.

Acked-by: Thomas Zimmermann <tzimmermann@suse.de>

But this makes me wonder why the kernel exposes raw EDID in the first
place. Wouldn't it be better to expose meaningful fields (display model,
vendor, etc) instead?

Best regards
Thomas

>   * DPMS:
>   * 	Legacy property for setting the power state of the connector. For atomic
>   * 	drivers this is only provided for backwards compatibility with existing
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 516 bytes --]

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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: document that user-space should avoid parsing EDIDs

[Thomas Zimmermann]

[-- Attachment #1.1.1: Type: text/plain, Size: 2351 bytes --]

Hi

Am 09.10.20 um 11:48 schrieb Thomas Zimmermann:
> Hi
> 
> Am 09.10.20 um 11:24 schrieb Simon Ser:
>> User-space should avoid parsing EDIDs for metadata already exposed via
>> other KMS interfaces and properties. For instance, user-space should not
>> try to extract a list of modes from the EDID: the kernel might mutate
>> the mode list (because of link capabilities or quirks for instance).
>>
>> Other metadata not exposed by KMS can be parsed by user-space. This
>> includes for instance monitor identification (make/model/serial) and
>> supported color-spaces.
>>
>> Signed-off-by: Simon Ser <contact@emersion.fr>
>> Suggested-by: Daniel Vetter <daniel.vetter@intel.com>
>> Cc: Daniel Vetter <daniel.vetter@intel.com>
>> Cc: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> ---
>>  drivers/gpu/drm/drm_connector.c | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
>> index 717c4e7271b0..00e58fd2d292 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -960,6 +960,10 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>>   * 	drm_connector_update_edid_property(), usually after having parsed
>>   * 	the EDID using drm_add_edid_modes(). Userspace cannot change this
>>   * 	property.
>> + *
>> + * 	User-space should not parse the EDID to obtain information exposed via

One nit: the rest of the file uses 'userspace' instead of 'user-space'.

>> + * 	other KMS properties. For instance, user-space should not try to parse
>> + * 	mode lists from the EDID.
> 
> Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
> 
> But this makes me wonder why the kernel exposes raw EDID in the first
> place. Wouldn't it be better to expose meaningful fields (display model,
> vendor, etc) instead?
> 
> Best regards
> Thomas
> 
>>   * DPMS:
>>   * 	Legacy property for setting the power state of the connector. For atomic
>>   * 	drivers this is only provided for backwards compatibility with existing
>>
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 516 bytes --]

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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: document that user-space should avoid parsing EDIDs

[Pekka Paalanen]

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

On Fri, 9 Oct 2020 11:48:44 +0200
Thomas Zimmermann <tzimmermann@suse.de> wrote:

> Hi
> 
> Am 09.10.20 um 11:24 schrieb Simon Ser:
> > User-space should avoid parsing EDIDs for metadata already exposed via
> > other KMS interfaces and properties. For instance, user-space should not
> > try to extract a list of modes from the EDID: the kernel might mutate
> > the mode list (because of link capabilities or quirks for instance).
> > 
> > Other metadata not exposed by KMS can be parsed by user-space. This
> > includes for instance monitor identification (make/model/serial) and
> > supported color-spaces.
> > 
> > Signed-off-by: Simon Ser <contact@emersion.fr>
> > Suggested-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Daniel Vetter <daniel.vetter@intel.com>

Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>

> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >  drivers/gpu/drm/drm_connector.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > index 717c4e7271b0..00e58fd2d292 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -960,6 +960,10 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
> >   * 	drm_connector_update_edid_property(), usually after having parsed
> >   * 	the EDID using drm_add_edid_modes(). Userspace cannot change this
> >   * 	property.
> > + *
> > + * 	User-space should not parse the EDID to obtain information exposed via
> > + * 	other KMS properties. For instance, user-space should not try to parse
> > + * 	mode lists from the EDID.  
> 
> Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
> 
> But this makes me wonder why the kernel exposes raw EDID in the first
> place. Wouldn't it be better to expose meaningful fields (display model,
> vendor, etc) instead?

There are many EDID bits of information that the kernel has no use
for. EDID specifications and extensions also continually evolve.

If the kernel set out to expose all information EDID may encode, what
should the UAPI look like? How do you keep the UAPI maintainable and
extendable?

Why should the kernel parse information it has no use for itself at
all? For example: RGB and white-point chromaticities, or maximum HDR
luminance.

That seems quite a lot of continuous work for a benefit I'm not sure I
see when compared to just handing the EDID blob to userspace and let
userspace parse the things the kernel does not expose already.

What we do need is a userspace EDID parsing library. This was discussed
in #dri-devel IRC today as well.


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: document that user-space should avoid parsing EDIDs

[Brian Starkey]

On Fri, Oct 09, 2020 at 09:24:01AM +0000, Simon Ser wrote:
> User-space should avoid parsing EDIDs for metadata already exposed via
> other KMS interfaces and properties. For instance, user-space should not
> try to extract a list of modes from the EDID: the kernel might mutate
> the mode list (because of link capabilities or quirks for instance).
> 
> Other metadata not exposed by KMS can be parsed by user-space. This
> includes for instance monitor identification (make/model/serial) and
> supported color-spaces.
> 
> Signed-off-by: Simon Ser <contact@emersion.fr>
> Suggested-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
> Cc: Ville Syrj�l� <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/drm_connector.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 717c4e7271b0..00e58fd2d292 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -960,6 +960,10 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>   * 	drm_connector_update_edid_property(), usually after having parsed
>   * 	the EDID using drm_add_edid_modes(). Userspace cannot change this
>   * 	property.
> + *
> + * 	User-space should not parse the EDID to obtain information exposed via
> + * 	other KMS properties. For instance, user-space should not try to parse
> + * 	mode lists from the EDID.

I assume that this is so that the kernel can apply quirks/limits in
cases where it knows it needs to? I think it would be nice to put at
least a few words indicating "why", otherwise this feels like an
arbitrary commandment with no justification.

Cheers,
-Brian

>   * DPMS:
>   * 	Legacy property for setting the power state of the connector. For atomic
>   * 	drivers this is only provided for backwards compatibility with existing
> -- 
> 2.28.0
> 
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: document that user-space should avoid parsing EDIDs

[Simon Ser]

On Friday, October 9, 2020 12:25 PM, Brian Starkey <brian.starkey@arm.com> wrote:

> I assume that this is so that the kernel can apply quirks/limits in
> cases where it knows it needs to? I think it would be nice to put at
> least a few words indicating "why", otherwise this feels like an
> arbitrary commandment with no justification.

I mainly wanted to avoid having some user-space developers think "but
I know better than the kernel!". I don't want to document that the
kernel will exclusively change the mode list because of quirks, then
figuring out that we need to fix-up another EDID field for other
reasons, and end up with complains.

I added an intentionally short explanation in v2.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: document that user-space should avoid parsing EDIDs

[Daniel Stone]

Hi,

On Fri, 9 Oct 2020 at 10:24, Simon Ser <contact@emersion.fr> wrote:
> User-space should avoid parsing EDIDs for metadata already exposed via
> other KMS interfaces and properties. For instance, user-space should not
> try to extract a list of modes from the EDID: the kernel might mutate
> the mode list (because of link capabilities or quirks for instance).
>
> Other metadata not exposed by KMS can be parsed by user-space. This
> includes for instance monitor identification (make/model/serial) and
> supported color-spaces.

So I take it the only way to get modes is through the connector's list
of modes. That sounds reasonable enough to me, but I think to properly
handle colour (e.g. CEA modes have different behaviour for
limited/full range depending on which VIC they correspond to IIRC)
we'd need to take more bits out of drm_mode_modeinfo::flags, which is
unfortunate since there aren't that many of them left and it's not an
extensible structure. Maybe proper mode handling is going to require
an expanded mode structure, but today is not that day, so:
Acked-by: Daniel Stone <daniels@collabora.com>

Cheers,
Daniel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: document that user-space should avoid parsing EDIDs

[Ville Syrjälä]

On Fri, Oct 09, 2020 at 01:07:20PM +0100, Daniel Stone wrote:
> Hi,
> 
> On Fri, 9 Oct 2020 at 10:24, Simon Ser <contact@emersion.fr> wrote:
> > User-space should avoid parsing EDIDs for metadata already exposed via
> > other KMS interfaces and properties. For instance, user-space should not
> > try to extract a list of modes from the EDID: the kernel might mutate
> > the mode list (because of link capabilities or quirks for instance).
> >
> > Other metadata not exposed by KMS can be parsed by user-space. This
> > includes for instance monitor identification (make/model/serial) and
> > supported color-spaces.
> 
> So I take it the only way to get modes is through the connector's list
> of modes. That sounds reasonable enough to me, but I think to properly
> handle colour (e.g. CEA modes have different behaviour for
> limited/full range depending on which VIC they correspond to IIRC)

If the mode has a VIC and that VIC is not 1, then it's limited range,
otherwise full range. There are fortunately no cases where you would
have the same exact timings corresponding to different quantization
range depending on the VIC.

And the only reason the same timings could correspond to multiple VICs
is aspect ratio. Which is already exposed via the mode flags, assuming
the appropriate client cap is enabled.

So I think the only reason to expose the VIC would be if userspace is
non-lazy and wants to manage its colors presicely, but is otherwise lazy
and doesn't want to figure out what the VIC of the mode is on its own.

I guess one related thing we might want to expose is the "is
quantization range selectable?" bits from the EDID (assuming we
really want the "don't parse the EDID in userspace" policy [1]). That
would be needed for userspace to be able to figure out if it can
override the VIC based quantization range in the display. Although
with a bunch of crappy displays you will want to override it anyway
because they just didn't bother with implementing the spec correctly
and instead always expect full range data.

[1] which probably would mean a huge boatload if properties or
some structure inside a blob (which is pretty much just the EDID
with a different layout then).

> we'd need to take more bits out of drm_mode_modeinfo::flags, which is
> unfortunate since there aren't that many of them left and it's not an
> extensible structure. Maybe proper mode handling is going to require
> an expanded mode structure, but today is not that day, so:
> Acked-by: Daniel Stone <daniels@collabora.com>
> 
> Cheers,
> Daniel
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: document that user-space should avoid parsing EDIDs

[Pekka Paalanen]

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

On Fri, 9 Oct 2020 16:10:25 +0300
Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:

> On Fri, Oct 09, 2020 at 01:07:20PM +0100, Daniel Stone wrote:
> > Hi,
> > 
> > On Fri, 9 Oct 2020 at 10:24, Simon Ser <contact@emersion.fr> wrote:  
> > > User-space should avoid parsing EDIDs for metadata already exposed via
> > > other KMS interfaces and properties. For instance, user-space should not
> > > try to extract a list of modes from the EDID: the kernel might mutate
> > > the mode list (because of link capabilities or quirks for instance).
> > >
> > > Other metadata not exposed by KMS can be parsed by user-space. This
> > > includes for instance monitor identification (make/model/serial) and
> > > supported color-spaces.  
> > 
> > So I take it the only way to get modes is through the connector's list
> > of modes. That sounds reasonable enough to me, but I think to properly
> > handle colour (e.g. CEA modes have different behaviour for
> > limited/full range depending on which VIC they correspond to IIRC)  
> 
> If the mode has a VIC and that VIC is not 1, then it's limited range,
> otherwise full range. There are fortunately no cases where you would
> have the same exact timings corresponding to different quantization
> range depending on the VIC.
> 
> And the only reason the same timings could correspond to multiple VICs
> is aspect ratio. Which is already exposed via the mode flags, assuming
> the appropriate client cap is enabled.
> 
> So I think the only reason to expose the VIC would be if userspace is
> non-lazy and wants to manage its colors presicely, but is otherwise lazy
> and doesn't want to figure out what the VIC of the mode is on its own.

What would "figure out what the VIC of the mode is" require in userspace?

A database of all VIC modes and then compare if the detailed timings match?

Is that also how the kernel recognises that userspace wants to set a
certain VIC mode instead of some arbitrary mode?

Can CVT or GVT produce those exact timings? Can that accidentally
result in limited range?

Sounds like the hypothetical libedid needs a libvic as a friend... and
libpixel-format while at it. :-)


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: document that user-space should avoid parsing EDIDs

[Ville Syrjälä]

On Fri, Oct 09, 2020 at 04:56:51PM +0300, Pekka Paalanen wrote:
> On Fri, 9 Oct 2020 16:10:25 +0300
> Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> 
> > On Fri, Oct 09, 2020 at 01:07:20PM +0100, Daniel Stone wrote:
> > > Hi,
> > > 
> > > On Fri, 9 Oct 2020 at 10:24, Simon Ser <contact@emersion.fr> wrote:  
> > > > User-space should avoid parsing EDIDs for metadata already exposed via
> > > > other KMS interfaces and properties. For instance, user-space should not
> > > > try to extract a list of modes from the EDID: the kernel might mutate
> > > > the mode list (because of link capabilities or quirks for instance).
> > > >
> > > > Other metadata not exposed by KMS can be parsed by user-space. This
> > > > includes for instance monitor identification (make/model/serial) and
> > > > supported color-spaces.  
> > > 
> > > So I take it the only way to get modes is through the connector's list
> > > of modes. That sounds reasonable enough to me, but I think to properly
> > > handle colour (e.g. CEA modes have different behaviour for
> > > limited/full range depending on which VIC they correspond to IIRC)  
> > 
> > If the mode has a VIC and that VIC is not 1, then it's limited range,
> > otherwise full range. There are fortunately no cases where you would
> > have the same exact timings corresponding to different quantization
> > range depending on the VIC.
> > 
> > And the only reason the same timings could correspond to multiple VICs
> > is aspect ratio. Which is already exposed via the mode flags, assuming
> > the appropriate client cap is enabled.
> > 
> > So I think the only reason to expose the VIC would be if userspace is
> > non-lazy and wants to manage its colors presicely, but is otherwise lazy
> > and doesn't want to figure out what the VIC of the mode is on its own.
> 
> What would "figure out what the VIC of the mode is" require in userspace?
> 
> A database of all VIC modes and then compare if the detailed timings match?
> 
> Is that also how the kernel recognises that userspace wants to set a
> certain VIC mode instead of some arbitrary mode?

Yes and yes.

Note that atm we also don't have a way for userspace to say that it
wants to signal limited range to the sink but wants the kernel
to not do the full->limited range conversion. Ie. no way for userspace
to pass in pixels that are already in limited range. There was a patch
for that posted quite long ago, but it didn't go in.

> 
> Can CVT or GVT produce those exact timings? Can that accidentally
> result in limited range?

Not sure.

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: document that user-space should avoid parsing EDIDs

[Pekka Paalanen]

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

On Fri, 9 Oct 2020 17:20:18 +0300
Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:

> On Fri, Oct 09, 2020 at 04:56:51PM +0300, Pekka Paalanen wrote:
> > On Fri, 9 Oct 2020 16:10:25 +0300
> > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> >   
> > > On Fri, Oct 09, 2020 at 01:07:20PM +0100, Daniel Stone wrote:  
> > > > Hi,
> > > > 
> > > > On Fri, 9 Oct 2020 at 10:24, Simon Ser <contact@emersion.fr> wrote:    
> > > > > User-space should avoid parsing EDIDs for metadata already exposed via
> > > > > other KMS interfaces and properties. For instance, user-space should not
> > > > > try to extract a list of modes from the EDID: the kernel might mutate
> > > > > the mode list (because of link capabilities or quirks for instance).
> > > > >
> > > > > Other metadata not exposed by KMS can be parsed by user-space. This
> > > > > includes for instance monitor identification (make/model/serial) and
> > > > > supported color-spaces.    
> > > > 
> > > > So I take it the only way to get modes is through the connector's list
> > > > of modes. That sounds reasonable enough to me, but I think to properly
> > > > handle colour (e.g. CEA modes have different behaviour for
> > > > limited/full range depending on which VIC they correspond to IIRC)    
> > > 
> > > If the mode has a VIC and that VIC is not 1, then it's limited range,
> > > otherwise full range. There are fortunately no cases where you would
> > > have the same exact timings corresponding to different quantization
> > > range depending on the VIC.
> > > 
> > > And the only reason the same timings could correspond to multiple VICs
> > > is aspect ratio. Which is already exposed via the mode flags, assuming
> > > the appropriate client cap is enabled.
> > > 
> > > So I think the only reason to expose the VIC would be if userspace is
> > > non-lazy and wants to manage its colors presicely, but is otherwise lazy
> > > and doesn't want to figure out what the VIC of the mode is on its own.  
> > 
> > What would "figure out what the VIC of the mode is" require in userspace?
> > 
> > A database of all VIC modes and then compare if the detailed timings match?
> > 
> > Is that also how the kernel recognises that userspace wants to set a
> > certain VIC mode instead of some arbitrary mode?  
> 
> Yes and yes.
> 
> Note that atm we also don't have a way for userspace to say that it
> wants to signal limited range to the sink but wants the kernel
> to not do the full->limited range conversion. Ie. no way for userspace
> to pass in pixels that are already in limited range. There was a patch
> for that posted quite long ago, but it didn't go in.

Thanks for the heads-up.

If userspace uses all available KMS color management properties
(CTM, LUTs, etc.) *and* the video mode implies limited range on the
cable, at what point in the pixel pipeline does that conversion from
full to limited range occur?

That is something I expect to need codify into Weston at some point so
that the complete pixel pipeline works as intended.


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: document that user-space should avoid parsing EDIDs

[Ville Syrjälä]

On Mon, Oct 12, 2020 at 10:11:01AM +0300, Pekka Paalanen wrote:
> On Fri, 9 Oct 2020 17:20:18 +0300
> Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> 
> > On Fri, Oct 09, 2020 at 04:56:51PM +0300, Pekka Paalanen wrote:
> > > On Fri, 9 Oct 2020 16:10:25 +0300
> > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > >   
> > > > On Fri, Oct 09, 2020 at 01:07:20PM +0100, Daniel Stone wrote:  
> > > > > Hi,
> > > > > 
> > > > > On Fri, 9 Oct 2020 at 10:24, Simon Ser <contact@emersion.fr> wrote:    
> > > > > > User-space should avoid parsing EDIDs for metadata already exposed via
> > > > > > other KMS interfaces and properties. For instance, user-space should not
> > > > > > try to extract a list of modes from the EDID: the kernel might mutate
> > > > > > the mode list (because of link capabilities or quirks for instance).
> > > > > >
> > > > > > Other metadata not exposed by KMS can be parsed by user-space. This
> > > > > > includes for instance monitor identification (make/model/serial) and
> > > > > > supported color-spaces.    
> > > > > 
> > > > > So I take it the only way to get modes is through the connector's list
> > > > > of modes. That sounds reasonable enough to me, but I think to properly
> > > > > handle colour (e.g. CEA modes have different behaviour for
> > > > > limited/full range depending on which VIC they correspond to IIRC)    
> > > > 
> > > > If the mode has a VIC and that VIC is not 1, then it's limited range,
> > > > otherwise full range. There are fortunately no cases where you would
> > > > have the same exact timings corresponding to different quantization
> > > > range depending on the VIC.
> > > > 
> > > > And the only reason the same timings could correspond to multiple VICs
> > > > is aspect ratio. Which is already exposed via the mode flags, assuming
> > > > the appropriate client cap is enabled.
> > > > 
> > > > So I think the only reason to expose the VIC would be if userspace is
> > > > non-lazy and wants to manage its colors presicely, but is otherwise lazy
> > > > and doesn't want to figure out what the VIC of the mode is on its own.  
> > > 
> > > What would "figure out what the VIC of the mode is" require in userspace?
> > > 
> > > A database of all VIC modes and then compare if the detailed timings match?
> > > 
> > > Is that also how the kernel recognises that userspace wants to set a
> > > certain VIC mode instead of some arbitrary mode?  
> > 
> > Yes and yes.
> > 
> > Note that atm we also don't have a way for userspace to say that it
> > wants to signal limited range to the sink but wants the kernel
> > to not do the full->limited range conversion. Ie. no way for userspace
> > to pass in pixels that are already in limited range. There was a patch
> > for that posted quite long ago, but it didn't go in.
> 
> Thanks for the heads-up.
> 
> If userspace uses all available KMS color management properties
> (CTM, LUTs, etc.) *and* the video mode implies limited range on the
> cable, at what point in the pixel pipeline does that conversion from
> full to limited range occur?

It should be the last step.

<stop reading now if you don't care about Intel hw details>

There is a slight snag on some Intel platforms that the gamma LUT
is sitting after the CSC unit, and currently we use the CSC for
the range compression.

On glk in particular I *think* we currently just do the wrong
thing do the range compression before gamma. The same probably
applies to hsw+ when both gamma and degamma are used at the same
time. But that is clearly buggy, and we should fix it to either:
a) return an error, which isn't super awesome since then you
   can't do gamma+limited range at the same time on glk, nor
   gamma+degamma+limited range on hsw+.
b) for the glk case we could use the hw degamma LUT for the
   gamma, which isn't great becasue the hw gamma and degamma
   LUTs are quite different beasts, and so the hw degamma LUT
   might not be able to do exactly what we need. On hsw+ we do
   use this trick already to get the gamma+limited range right,
   but on these platforms the hw gamma and degamma LUTs have
   identical capabilities.
c) do the range compression with the hw gamma LUT instead, which
   of course means we have to combine the user gamma and range
   compression into the same gamma LUT.

So I think c) is what it should be. Would just need to find the time
to implement it, and figure out how to not totally mess up our
driver's hw state checker. Hmm, except this won't help at all
with YCbCr output since we need to apply gamma before the
RGB->YCbCr conversion (which uses the same CSC again). Argh.
So YCbCr output would still need option b).

Thankfully icl+ fixed all this by adding a dedicated output CSC
unit which sits after the gamma LUT in the pipeline. And pre-hsw
is almost fine as well since the hw has a dedicated fixed function
thing for the range compression. So the only snag on pre-hsw
is the YCbCr+degamma+gamma case.

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: document that user-space should avoid parsing EDIDs

[Pekka Paalanen]

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

On Fri, 16 Oct 2020 16:50:16 +0300
Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:

> On Mon, Oct 12, 2020 at 10:11:01AM +0300, Pekka Paalanen wrote:
> > On Fri, 9 Oct 2020 17:20:18 +0300
> > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> >   
> > > On Fri, Oct 09, 2020 at 04:56:51PM +0300, Pekka Paalanen wrote:  
> > > > On Fri, 9 Oct 2020 16:10:25 +0300
> > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > >     
> > > > > On Fri, Oct 09, 2020 at 01:07:20PM +0100, Daniel Stone wrote:    
> > > > > > Hi,
> > > > > > 
> > > > > > On Fri, 9 Oct 2020 at 10:24, Simon Ser <contact@emersion.fr> wrote:      
> > > > > > > User-space should avoid parsing EDIDs for metadata already exposed via
> > > > > > > other KMS interfaces and properties. For instance, user-space should not
> > > > > > > try to extract a list of modes from the EDID: the kernel might mutate
> > > > > > > the mode list (because of link capabilities or quirks for instance).
> > > > > > >
> > > > > > > Other metadata not exposed by KMS can be parsed by user-space. This
> > > > > > > includes for instance monitor identification (make/model/serial) and
> > > > > > > supported color-spaces.      
> > > > > > 
> > > > > > So I take it the only way to get modes is through the connector's list
> > > > > > of modes. That sounds reasonable enough to me, but I think to properly
> > > > > > handle colour (e.g. CEA modes have different behaviour for
> > > > > > limited/full range depending on which VIC they correspond to IIRC)      
> > > > > 
> > > > > If the mode has a VIC and that VIC is not 1, then it's limited range,
> > > > > otherwise full range. There are fortunately no cases where you would
> > > > > have the same exact timings corresponding to different quantization
> > > > > range depending on the VIC.
> > > > > 
> > > > > And the only reason the same timings could correspond to multiple VICs
> > > > > is aspect ratio. Which is already exposed via the mode flags, assuming
> > > > > the appropriate client cap is enabled.
> > > > > 
> > > > > So I think the only reason to expose the VIC would be if userspace is
> > > > > non-lazy and wants to manage its colors presicely, but is otherwise lazy
> > > > > and doesn't want to figure out what the VIC of the mode is on its own.    
> > > > 
> > > > What would "figure out what the VIC of the mode is" require in userspace?
> > > > 
> > > > A database of all VIC modes and then compare if the detailed timings match?
> > > > 
> > > > Is that also how the kernel recognises that userspace wants to set a
> > > > certain VIC mode instead of some arbitrary mode?    
> > > 
> > > Yes and yes.
> > > 
> > > Note that atm we also don't have a way for userspace to say that it
> > > wants to signal limited range to the sink but wants the kernel
> > > to not do the full->limited range conversion. Ie. no way for userspace
> > > to pass in pixels that are already in limited range. There was a patch
> > > for that posted quite long ago, but it didn't go in.  
> > 
> > Thanks for the heads-up.
> > 
> > If userspace uses all available KMS color management properties
> > (CTM, LUTs, etc.) *and* the video mode implies limited range on the
> > cable, at what point in the pixel pipeline does that conversion from
> > full to limited range occur?  
> 
> It should be the last step.
> 
> <stop reading now if you don't care about Intel hw details>
> 
> There is a slight snag on some Intel platforms that the gamma LUT
> is sitting after the CSC unit, and currently we use the CSC for
> the range compression.
> 
> On glk in particular I *think* we currently just do the wrong
> thing do the range compression before gamma. The same probably
> applies to hsw+ when both gamma and degamma are used at the same
> time. But that is clearly buggy, and we should fix it to either:
> a) return an error, which isn't super awesome since then you
>    can't do gamma+limited range at the same time on glk, nor
>    gamma+degamma+limited range on hsw+.
> b) for the glk case we could use the hw degamma LUT for the
>    gamma, which isn't great becasue the hw gamma and degamma
>    LUTs are quite different beasts, and so the hw degamma LUT
>    might not be able to do exactly what we need. On hsw+ we do
>    use this trick already to get the gamma+limited range right,
>    but on these platforms the hw gamma and degamma LUTs have
>    identical capabilities.
> c) do the range compression with the hw gamma LUT instead, which
>    of course means we have to combine the user gamma and range
>    compression into the same gamma LUT.
> 
> So I think c) is what it should be. Would just need to find the time
> to implement it, and figure out how to not totally mess up our
> driver's hw state checker. Hmm, except this won't help at all
> with YCbCr output since we need to apply gamma before the
> RGB->YCbCr conversion (which uses the same CSC again). Argh.
> So YCbCr output would still need option b).
> 
> Thankfully icl+ fixed all this by adding a dedicated output CSC
> unit which sits after the gamma LUT in the pipeline. And pre-hsw
> is almost fine as well since the hw has a dedicated fixed function
> thing for the range compression. So the only snag on pre-hsw
> is the YCbCr+degamma+gamma case.

Interesting.

I gather that if I stick to RGB and full-range, or maybe just
full-range regardless of RGB vs. YCbCr on the cable, I should be fine.
I'd need to have color management disable all limited-range (VIC)
modes in a compositor... no, not disable, but maybe print a warning in
the log.

I'd love if there was a test suite ensuring these work correctly, but
that's a lot of work. I'm not sure if writeback or CRC helps with
it, or does it need actual HDMI or DP frame grabber hardware?

I presume that there is too much acceptable fuzz in output signal that
CRC testing is not going to be useful anyway.

The Wayland color management design, or more like compositor designs,
kind of rely on the KMS hardware doing exactly what it's told.


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: document that user-space should avoid parsing EDIDs

[Vitaly Prosyak]

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


On 2020-10-19 3:49 a.m., Pekka Paalanen wrote:
> On Fri, 16 Oct 2020 16:50:16 +0300
> Ville Syrjälä<ville.syrjala@linux.intel.com>  wrote:
>
>> On Mon, Oct 12, 2020 at 10:11:01AM +0300, Pekka Paalanen wrote:
>>> On Fri, 9 Oct 2020 17:20:18 +0300
>>> Ville Syrjälä<ville.syrjala@linux.intel.com>  wrote:
>>>    
>>>> On Fri, Oct 09, 2020 at 04:56:51PM +0300, Pekka Paalanen wrote:
>>>>> On Fri, 9 Oct 2020 16:10:25 +0300
>>>>> Ville Syrjälä<ville.syrjala@linux.intel.com>  wrote:
>>>>>      
>>>>>> On Fri, Oct 09, 2020 at 01:07:20PM +0100, Daniel Stone wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Fri, 9 Oct 2020 at 10:24, Simon Ser<contact@emersion.fr>  wrote:
>>>>>>>> User-space should avoid parsing EDIDs for metadata already exposed via
>>>>>>>> other KMS interfaces and properties. For instance, user-space should not
>>>>>>>> try to extract a list of modes from the EDID: the kernel might mutate
>>>>>>>> the mode list (because of link capabilities or quirks for instance).
>>>>>>>>
>>>>>>>> Other metadata not exposed by KMS can be parsed by user-space. This
>>>>>>>> includes for instance monitor identification (make/model/serial) and
>>>>>>>> supported color-spaces.
>>>>>>> So I take it the only way to get modes is through the connector's list
>>>>>>> of modes. That sounds reasonable enough to me, but I think to properly
>>>>>>> handle colour (e.g. CEA modes have different behaviour for
>>>>>>> limited/full range depending on which VIC they correspond to IIRC)
>>>>>> If the mode has a VIC and that VIC is not 1, then it's limited range,
>>>>>> otherwise full range. There are fortunately no cases where you would
>>>>>> have the same exact timings corresponding to different quantization
>>>>>> range depending on the VIC.
>>>>>>
>>>>>> And the only reason the same timings could correspond to multiple VICs
>>>>>> is aspect ratio. Which is already exposed via the mode flags, assuming
>>>>>> the appropriate client cap is enabled.
>>>>>>
>>>>>> So I think the only reason to expose the VIC would be if userspace is
>>>>>> non-lazy and wants to manage its colors presicely, but is otherwise lazy
>>>>>> and doesn't want to figure out what the VIC of the mode is on its own.
>>>>> What would "figure out what the VIC of the mode is" require in userspace?
>>>>>
>>>>> A database of all VIC modes and then compare if the detailed timings match?
>>>>>
>>>>> Is that also how the kernel recognises that userspace wants to set a
>>>>> certain VIC mode instead of some arbitrary mode?
>>>> Yes and yes.
>>>>
>>>> Note that atm we also don't have a way for userspace to say that it
>>>> wants to signal limited range to the sink but wants the kernel
>>>> to not do the full->limited range conversion. Ie. no way for userspace
>>>> to pass in pixels that are already in limited range. There was a patch
>>>> for that posted quite long ago, but it didn't go in.
>>> Thanks for the heads-up.
>>>
>>> If userspace uses all available KMS color management properties
>>> (CTM, LUTs, etc.)*and*  the video mode implies limited range on the
>>> cable, at what point in the pixel pipeline does that conversion from
>>> full to limited range occur?
>> It should be the last step.
>>
>> <stop reading now if you don't care about Intel hw details>
>>
>> There is a slight snag on some Intel platforms that the gamma LUT
>> is sitting after the CSC unit, and currently we use the CSC for
>> the range compression.

Thanks a lot for letting us to know about this!
AMD display pipe has always at the end CSC matrix where we apply appropriate range conversion if necessary.

>>
>> On glk in particular I*think*  we currently just do the wrong
>> thing do the range compression before gamma. The same probably
>> applies to hsw+ when both gamma and degamma are used at the same
>> time. But that is clearly buggy, and we should fix it to either:
>> a) return an error, which isn't super awesome since then you
>>     can't do gamma+limited range at the same time on glk, nor
>>     gamma+degamma+limited range on hsw+.
>> b) for the glk case we could use the hw degamma LUT for the
>>     gamma, which isn't great becasue the hw gamma and degamma
>>     LUTs are quite different beasts, and so the hw degamma LUT
>>     might not be able to do exactly what we need.

Do you mean that hw de-gamma LUT build on ROM ( it is not programmable, just select the proper bit)?

>> On hsw+ we do
>>     use this trick already to get the gamma+limited range right,
>>     but on these platforms the hw gamma and degamma LUTs have
>>     identical capabilities.
>> c) do the range compression with the hw gamma LUT instead, which
>>     of course means we have to combine the user gamma and range
>>     compression into the same gamma LUT.

Nice w/a and in amdgpu we are using also curve concatenations into re gamma LUT.

The number of concatenations could be as many as need it and we may take advantage of this in user mode. Does this sounds preliminarily  good?

Wouldn't the following sentence be interesting for you if the user mode generates 1D LUT points using X axis exponential distribution to avoid
unnecessary interpolation in kernel?  It may be especially important if curve concatenation is expected?

>>
>> So I think c) is what it should be. Would just need to find the time
>> to implement it, and figure out how to not totally mess up our
>> driver's hw state checker. Hmm, except this won't help at all
>> with YCbCr output since we need to apply gamma before the
>> RGB->YCbCr conversion (which uses the same CSC again). Argh.
>> So YCbCr output would still need option b).
>>
>> Thankfully icl+ fixed all this by adding a dedicated output CSC
>> unit which sits after the gamma LUT in the pipeline. And pre-hsw
>> is almost fine as well since the hw has a dedicated fixed function
>> thing for the range compression. So the only snag on pre-hsw
>> is the YCbCr+degamma+gamma case.

Where is the display engine scaler is located on Intel platforms?

AMD old ASIC's have a display scaler after display color pipeline ,so the whole color processing can be a bit mess up unless integer scaling is in use.

The new ASIC's ( ~5 years already)  have scaler before color pipeline.

> Interesting.
>
> I gather that if I stick to RGB and full-range, or maybe just
> full-range regardless of RGB vs. YCbCr on the cable, I should be fine.
> I'd need to have color management disable all limited-range (VIC)
> modes in a compositor... no, not disable, but maybe print a warning in
> the log.
>
> I'd love if there was a test suite ensuring these work correctly, but
> that's a lot of work. I'm not sure if writeback or CRC helps with
> it, or does it need actual HDMI or DP frame grabber hardware?
>
> I presume that there is too much acceptable fuzz in output signal that
> CRC testing is not going to be useful anyway.
>
> The Wayland color management design, or more like compositor designs,
> kind of rely on the KMS hardware doing exactly what it's told.
>
>
> Thanks,
> pq

Thanks, Vitaly


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

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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: document that user-space should avoid parsing EDIDs

[Ville Syrjälä]

On Mon, Oct 19, 2020 at 11:08:27PM -0400, Vitaly Prosyak wrote:
> 
> On 2020-10-19 3:49 a.m., Pekka Paalanen wrote:
> > On Fri, 16 Oct 2020 16:50:16 +0300
> > Ville Syrjälä<ville.syrjala@linux.intel.com>  wrote:
> >
> >> On Mon, Oct 12, 2020 at 10:11:01AM +0300, Pekka Paalanen wrote:
> >>> On Fri, 9 Oct 2020 17:20:18 +0300
> >>> Ville Syrjälä<ville.syrjala@linux.intel.com>  wrote:
<snip>
> >> There is a slight snag on some Intel platforms that the gamma LUT
> >> is sitting after the CSC unit, and currently we use the CSC for
> >> the range compression.
> 
> Thanks a lot for letting us to know about this!
> AMD display pipe has always at the end CSC matrix where we apply appropriate range conversion if necessary.
> 
> >>
> >> On glk in particular I*think*  we currently just do the wrong
> >> thing do the range compression before gamma. The same probably
> >> applies to hsw+ when both gamma and degamma are used at the same
> >> time. But that is clearly buggy, and we should fix it to either:
> >> a) return an error, which isn't super awesome since then you
> >>     can't do gamma+limited range at the same time on glk, nor
> >>     gamma+degamma+limited range on hsw+.
> >> b) for the glk case we could use the hw degamma LUT for the
> >>     gamma, which isn't great becasue the hw gamma and degamma
> >>     LUTs are quite different beasts, and so the hw degamma LUT
> >>     might not be able to do exactly what we need.
> 
> Do you mean that hw de-gamma LUT build on ROM ( it is not programmable, just select the proper bit)?

No. The hw degamma LUT is a 1x33 linearly interpolated
non-decreasing curve. So can't do directcolor type stuff,
and each RGB channel must have the same gamma.

The hw gamma LUT on the other hand can operate in multiple
different modes, from which we currently choose the
3x1024 non-interpoated mode. Which can do all those
things the degamma LUT can't do.

> 
> >> On hsw+ we do
> >>     use this trick already to get the gamma+limited range right,
> >>     but on these platforms the hw gamma and degamma LUTs have
> >>     identical capabilities.
> >> c) do the range compression with the hw gamma LUT instead, which
> >>     of course means we have to combine the user gamma and range
> >>     compression into the same gamma LUT.
> 
> Nice w/a and in amdgpu we are using also curve concatenations into re gamma LUT.
> 
> The number of concatenations could be as many as need it and we may take advantage of this in user mode. Does this sounds preliminarily  good?
> 
> Wouldn't the following sentence be interesting for you if the user mode generates 1D LUT points using X axis exponential distribution to avoid
> unnecessary interpolation in kernel?  It may be especially important if curve concatenation is expected?

Yeah, I think we want a new uapi for gamma stuff that will allow
userspace to properly calculate things up front for different kinds
of hw implementations, without the kernel having to interpolate/decimate.
We've had some discussions/proposals on the list.

> 
> >>
> >> So I think c) is what it should be. Would just need to find the time
> >> to implement it, and figure out how to not totally mess up our
> >> driver's hw state checker. Hmm, except this won't help at all
> >> with YCbCr output since we need to apply gamma before the
> >> RGB->YCbCr conversion (which uses the same CSC again). Argh.
> >> So YCbCr output would still need option b).
> >>
> >> Thankfully icl+ fixed all this by adding a dedicated output CSC
> >> unit which sits after the gamma LUT in the pipeline. And pre-hsw
> >> is almost fine as well since the hw has a dedicated fixed function
> >> thing for the range compression. So the only snag on pre-hsw
> >> is the YCbCr+degamma+gamma case.
> 
> Where is the display engine scaler is located on Intel platforms?
> AMD old ASIC's have a display scaler after display color pipeline ,so the whole color processing can be a bit mess up unless integer scaling is in use.
> 
> The new ASIC's ( ~5 years already)  have scaler before color pipeline.

We have a somewhat similar situation.

On older hw the scaler tap point is at the end of the pipe, so
between the gamma LUT and dithering.

On icl+ I think we have two tap points; one between degamma
LUT and the first pipe CSC, and a second one between the output
CSC and dithering. The spec calls these non-linear and linear tap
points. The scaler also gained another linear vs. non-linear
control knob which affects the precision at which it can operate
in some form. There's also some other interaction between this and
another knob ("HDR" mode) which controls the precision of blending
in the pipe. I haven't yet thought how we should configure all this
to the best effect. For the moment we leave these scaler settings
to their defaults, which means using the non-linear tap point and
non-linear precision setting. The blending precision we adjust
dynamically depending on which planes are enabled. Only a subset
of the planes (so called HDR planes) can be enabled when using the
high precision blending mode.

On icl+ plane scaling also has the two different tap points, but
this time I think it just depdends on the type of plane used;
HDR planes have a linear tap point just before blending, SDR
planes have a non-linear tap point right after the pixels enter
the plane's pipeline. Older hw again just had the non-linear
tap point.

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: document that user-space should avoid parsing EDIDs

[Vitaly Prosyak]

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


On 2020-10-20 11:04 a.m., Ville Syrjälä wrote:
> On Mon, Oct 19, 2020 at 11:08:27PM -0400, Vitaly Prosyak wrote:
>> On 2020-10-19 3:49 a.m., Pekka Paalanen wrote:
>>> On Fri, 16 Oct 2020 16:50:16 +0300
>>> Ville Syrjälä<ville.syrjala@linux.intel.com>  wrote:
>>>
>>>> On Mon, Oct 12, 2020 at 10:11:01AM +0300, Pekka Paalanen wrote:
>>>>> On Fri, 9 Oct 2020 17:20:18 +0300
>>>>> Ville Syrjälä<ville.syrjala@linux.intel.com>  wrote:
> <snip>
>>>> There is a slight snag on some Intel platforms that the gamma LUT
>>>> is sitting after the CSC unit, and currently we use the CSC for
>>>> the range compression.
>> Thanks a lot for letting us to know about this!
>> AMD display pipe has always at the end CSC matrix where we apply appropriate range conversion if necessary.
>>
>>>> On glk in particular I*think*  we currently just do the wrong
>>>> thing do the range compression before gamma. The same probably
>>>> applies to hsw+ when both gamma and degamma are used at the same
>>>> time. But that is clearly buggy, and we should fix it to either:
>>>> a) return an error, which isn't super awesome since then you
>>>>      can't do gamma+limited range at the same time on glk, nor
>>>>      gamma+degamma+limited range on hsw+.
>>>> b) for the glk case we could use the hw degamma LUT for the
>>>>      gamma, which isn't great becasue the hw gamma and degamma
>>>>      LUTs are quite different beasts, and so the hw degamma LUT
>>>>      might not be able to do exactly what we need.
>> Do you mean that hw de-gamma LUT build on ROM ( it is not programmable, just select the proper bit)?
> No. The hw degamma LUT is a 1x33 linearly interpolated
> non-decreasing curve. So can't do directcolor type stuff,
> and each RGB channel must have the same gamma.
>
> The hw gamma LUT on the other hand can operate in multiple
> different modes, from which we currently choose the
> 3x1024 non-interpoated mode. Which can do all those
> things the degamma LUT can't do.
>
>>>> On hsw+ we do
>>>>      use this trick already to get the gamma+limited range right,
>>>>      but on these platforms the hw gamma and degamma LUTs have
>>>>      identical capabilities.
>>>> c) do the range compression with the hw gamma LUT instead, which
>>>>      of course means we have to combine the user gamma and range
>>>>      compression into the same gamma LUT.
>> Nice w/a and in amdgpu we are using also curve concatenations into re gamma LUT.
>>
>> The number of concatenations could be as many as need it and we may take advantage of this in user mode. Does this sounds preliminarily  good?
>>
>> Wouldn't the following sentence be interesting for you if the user mode generates 1D LUT points using X axis exponential distribution to avoid
>> unnecessary interpolation in kernel?  It may be especially important if curve concatenation is expected?
> Yeah, I think we want a new uapi for gamma stuff that will allow
> userspace to properly calculate things up front for different kinds
> of hw implementations, without the kernel having to interpolate/decimate.
> We've had some discussions/proposals on the list.
>
>>>> So I think c) is what it should be. Would just need to find the time
>>>> to implement it, and figure out how to not totally mess up our
>>>> driver's hw state checker. Hmm, except this won't help at all
>>>> with YCbCr output since we need to apply gamma before the
>>>> RGB->YCbCr conversion (which uses the same CSC again). Argh.
>>>> So YCbCr output would still need option b).
>>>>
>>>> Thankfully icl+ fixed all this by adding a dedicated output CSC
>>>> unit which sits after the gamma LUT in the pipeline. And pre-hsw
>>>> is almost fine as well since the hw has a dedicated fixed function
>>>> thing for the range compression. So the only snag on pre-hsw
>>>> is the YCbCr+degamma+gamma case.
>> Where is the display engine scaler is located on Intel platforms?
>> AMD old ASIC's have a display scaler after display color pipeline ,so the whole color processing can be a bit mess up unless integer scaling is in use.
>>
>> The new ASIC's ( ~5 years already)  have scaler before color pipeline.
> We have a somewhat similar situation.
>
> On older hw the scaler tap point is at the end of the pipe, so
> between the gamma LUT and dithering.
>
> On icl+ I think we have two tap points; one between degamma
> LUT and the first pipe CSC, and a second one between the output
> CSC and dithering. The spec calls these non-linear and linear tap
> points. The scaler also gained another linear vs. non-linear
> control knob which affects the precision at which it can operate
> in some form. There's also some other interaction between this and
> another knob ("HDR" mode) which controls the precision of blending
> in the pipe. I haven't yet thought how we should configure all this
> to the best effect. For the moment we leave these scaler settings
> to their defaults, which means using the non-linear tap point and
> non-linear precision setting. The blending precision we adjust
> dynamically depending on which planes are enabled. Only a subset
> of the planes (so called HDR planes) can be enabled when using the
> high precision blending mode.
>
> On icl+ plane scaling also has the two different tap points, but
> this time I think it just depdends on the type of plane used;
> HDR planes have a linear tap point just before blending, SDR
> planes have a non-linear tap point right after the pixels enter
> the plane's pipeline. Older hw again just had the non-linear
> tap point.

Thanks for the clarification Ville!

I am not sure if i understood correctly tap points.

Are you referring that you have full 2 scalers and each-one can do horizontal and vertical scaling?

The first scaler does scaling in linear space and and the second in non linear. Is it correct?

I just found thread from Pekka :https://lists.freedesktop.org/archives/wayland-devel/2020-October/041637.html

regarding integer scaling and other related stuff.

AMD display engine has always 1 scaler, we do concatenation of two or more scaling transforms into one if it is necessary.

Old ASIC's do scaling in nonlinear space, new ASIC's in linear space since scaler precision is half float.

All these questions are become important for hardware composition and if the differences are too big( not sure about this) and it can't be abstracted.

As one approach , can we think about shared object in user mode for each vendor ( this approach was in android for hardware composition) and this small component can do

LUT's , scaler coefficients content and other not compatible stuff ) ?

For example, tiling is already has nice abstraction level  like  dma buf modifiers .

Another approach , I am not sure if user mode can request abstraction from driver regarding color pipeline

in accordance to ICC spec. In fact all display engine pipes are look very similar to ICC spec which grew also from 8 bpc to half float.

If we take this as baseline then we can try to abstract and this may be beneficial for entire Linux ecosystem and move forward together with Color Consortium.

Thanks, Vitaly






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

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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: document that user-space should avoid parsing EDIDs

[Ville Syrjälä]

On Tue, Oct 20, 2020 at 09:46:30PM -0400, Vitaly Prosyak wrote:
> 
> On 2020-10-20 11:04 a.m., Ville Syrjälä wrote:
> > On Mon, Oct 19, 2020 at 11:08:27PM -0400, Vitaly Prosyak wrote:
> >> On 2020-10-19 3:49 a.m., Pekka Paalanen wrote:
> >>> On Fri, 16 Oct 2020 16:50:16 +0300
> >>> Ville Syrjälä<ville.syrjala@linux.intel.com>  wrote:
> >>>
> >>>> On Mon, Oct 12, 2020 at 10:11:01AM +0300, Pekka Paalanen wrote:
> >>>>> On Fri, 9 Oct 2020 17:20:18 +0300
> >>>>> Ville Syrjälä<ville.syrjala@linux.intel.com>  wrote:
> > <snip>
> >>>> There is a slight snag on some Intel platforms that the gamma LUT
> >>>> is sitting after the CSC unit, and currently we use the CSC for
> >>>> the range compression.
> >> Thanks a lot for letting us to know about this!
> >> AMD display pipe has always at the end CSC matrix where we apply appropriate range conversion if necessary.
> >>
> >>>> On glk in particular I*think*  we currently just do the wrong
> >>>> thing do the range compression before gamma. The same probably
> >>>> applies to hsw+ when both gamma and degamma are used at the same
> >>>> time. But that is clearly buggy, and we should fix it to either:
> >>>> a) return an error, which isn't super awesome since then you
> >>>>      can't do gamma+limited range at the same time on glk, nor
> >>>>      gamma+degamma+limited range on hsw+.
> >>>> b) for the glk case we could use the hw degamma LUT for the
> >>>>      gamma, which isn't great becasue the hw gamma and degamma
> >>>>      LUTs are quite different beasts, and so the hw degamma LUT
> >>>>      might not be able to do exactly what we need.
> >> Do you mean that hw de-gamma LUT build on ROM ( it is not programmable, just select the proper bit)?
> > No. The hw degamma LUT is a 1x33 linearly interpolated
> > non-decreasing curve. So can't do directcolor type stuff,
> > and each RGB channel must have the same gamma.
> >
> > The hw gamma LUT on the other hand can operate in multiple
> > different modes, from which we currently choose the
> > 3x1024 non-interpoated mode. Which can do all those
> > things the degamma LUT can't do.
> >
> >>>> On hsw+ we do
> >>>>      use this trick already to get the gamma+limited range right,
> >>>>      but on these platforms the hw gamma and degamma LUTs have
> >>>>      identical capabilities.
> >>>> c) do the range compression with the hw gamma LUT instead, which
> >>>>      of course means we have to combine the user gamma and range
> >>>>      compression into the same gamma LUT.
> >> Nice w/a and in amdgpu we are using also curve concatenations into re gamma LUT.
> >>
> >> The number of concatenations could be as many as need it and we may take advantage of this in user mode. Does this sounds preliminarily  good?
> >>
> >> Wouldn't the following sentence be interesting for you if the user mode generates 1D LUT points using X axis exponential distribution to avoid
> >> unnecessary interpolation in kernel?  It may be especially important if curve concatenation is expected?
> > Yeah, I think we want a new uapi for gamma stuff that will allow
> > userspace to properly calculate things up front for different kinds
> > of hw implementations, without the kernel having to interpolate/decimate.
> > We've had some discussions/proposals on the list.
> >
> >>>> So I think c) is what it should be. Would just need to find the time
> >>>> to implement it, and figure out how to not totally mess up our
> >>>> driver's hw state checker. Hmm, except this won't help at all
> >>>> with YCbCr output since we need to apply gamma before the
> >>>> RGB->YCbCr conversion (which uses the same CSC again). Argh.
> >>>> So YCbCr output would still need option b).
> >>>>
> >>>> Thankfully icl+ fixed all this by adding a dedicated output CSC
> >>>> unit which sits after the gamma LUT in the pipeline. And pre-hsw
> >>>> is almost fine as well since the hw has a dedicated fixed function
> >>>> thing for the range compression. So the only snag on pre-hsw
> >>>> is the YCbCr+degamma+gamma case.
> >> Where is the display engine scaler is located on Intel platforms?
> >> AMD old ASIC's have a display scaler after display color pipeline ,so the whole color processing can be a bit mess up unless integer scaling is in use.
> >>
> >> The new ASIC's ( ~5 years already)  have scaler before color pipeline.
> > We have a somewhat similar situation.
> >
> > On older hw the scaler tap point is at the end of the pipe, so
> > between the gamma LUT and dithering.
> >
> > On icl+ I think we have two tap points; one between degamma
> > LUT and the first pipe CSC, and a second one between the output
> > CSC and dithering. The spec calls these non-linear and linear tap
> > points. The scaler also gained another linear vs. non-linear
> > control knob which affects the precision at which it can operate
> > in some form. There's also some other interaction between this and
> > another knob ("HDR" mode) which controls the precision of blending
> > in the pipe. I haven't yet thought how we should configure all this
> > to the best effect. For the moment we leave these scaler settings
> > to their defaults, which means using the non-linear tap point and
> > non-linear precision setting. The blending precision we adjust
> > dynamically depending on which planes are enabled. Only a subset
> > of the planes (so called HDR planes) can be enabled when using the
> > high precision blending mode.
> >
> > On icl+ plane scaling also has the two different tap points, but
> > this time I think it just depdends on the type of plane used;
> > HDR planes have a linear tap point just before blending, SDR
> > planes have a non-linear tap point right after the pixels enter
> > the plane's pipeline. Older hw again just had the non-linear
> > tap point.
> 
> Thanks for the clarification Ville!
> 
> I am not sure if i understood correctly tap points.
> 
> Are you referring that you have full 2 scalers and each-one can do horizontal and vertical scaling?
> 
> The first scaler does scaling in linear space and and the second in non linear. Is it correct?

There are two scalers per pipe, each will do the full horz+vert scaling,
and each one can be assigned to either:
- any HDR plane linear tap point to scale the plane
- any SDR plane non-linear tap point to scale the plane
- pipe linear pipe tap point to scale the whole crtc output
- pipe non-linear tap point to scale the whole crtc output

I don't think you're supposed to assign scalers to both of
the pipe tap points simultaneously. The registers might allow
it though, so could be an interesting experiment :P
 
> I just found thread from Pekka :https://lists.freedesktop.org/archives/wayland-devel/2020-October/041637.html
> 
> regarding integer scaling and other related stuff.
> 
> AMD display engine has always 1 scaler, we do concatenation of two or more scaling transforms into one if it is necessary.
> 
> Old ASIC's do scaling in nonlinear space, new ASIC's in linear space since scaler precision is half float.
> 
> All these questions are become important for hardware composition and if the differences are too big( not sure about this) and it can't be abstracted.
> 
> As one approach , can we think about shared object in user mode for each vendor ( this approach was in android for hardware composition) and this small component can do
> 
> LUT's , scaler coefficients content and other not compatible stuff ) ?

The idea has come up before. Getting any kind of acceptance for such a
thing across the various userspace components would probably require
a full time lobbyist.

I think various forms of gamma and CSC should be possible to abstract
in a somewhat reasonable way. For scaling we're now moving ahead with
the enum prop to specify the filter. If there was a real need we could
even try to abstract some kind of filter coefficients uapi as well.
I suspect most things would have some kind of polyphase FIR filter.

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: document that user-space should avoid parsing EDIDs

[Vitaly Prosyak]

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


On 2020-10-21 10:35 a.m., Ville Syrjälä wrote:
> On Tue, Oct 20, 2020 at 09:46:30PM -0400, Vitaly Prosyak wrote:
>> On 2020-10-20 11:04 a.m., Ville Syrjälä wrote:
>>> On Mon, Oct 19, 2020 at 11:08:27PM -0400, Vitaly Prosyak wrote:
>>>> On 2020-10-19 3:49 a.m., Pekka Paalanen wrote:
>>>>> On Fri, 16 Oct 2020 16:50:16 +0300
>>>>> Ville Syrjälä<ville.syrjala@linux.intel.com>   wrote:
>>>>>
>>>>>> On Mon, Oct 12, 2020 at 10:11:01AM +0300, Pekka Paalanen wrote:
>>>>>>> On Fri, 9 Oct 2020 17:20:18 +0300
>>>>>>> Ville Syrjälä<ville.syrjala@linux.intel.com>   wrote:
>>> <snip>
>>>>>> There is a slight snag on some Intel platforms that the gamma LUT
>>>>>> is sitting after the CSC unit, and currently we use the CSC for
>>>>>> the range compression.
>>>> Thanks a lot for letting us to know about this!
>>>> AMD display pipe has always at the end CSC matrix where we apply appropriate range conversion if necessary.
>>>>
>>>>>> On glk in particular I*think*  we currently just do the wrong
>>>>>> thing do the range compression before gamma. The same probably
>>>>>> applies to hsw+ when both gamma and degamma are used at the same
>>>>>> time. But that is clearly buggy, and we should fix it to either:
>>>>>> a) return an error, which isn't super awesome since then you
>>>>>>       can't do gamma+limited range at the same time on glk, nor
>>>>>>       gamma+degamma+limited range on hsw+.
>>>>>> b) for the glk case we could use the hw degamma LUT for the
>>>>>>       gamma, which isn't great becasue the hw gamma and degamma
>>>>>>       LUTs are quite different beasts, and so the hw degamma LUT
>>>>>>       might not be able to do exactly what we need.
>>>> Do you mean that hw de-gamma LUT build on ROM ( it is not programmable, just select the proper bit)?
>>> No. The hw degamma LUT is a 1x33 linearly interpolated
>>> non-decreasing curve. So can't do directcolor type stuff,
>>> and each RGB channel must have the same gamma.
>>>
>>> The hw gamma LUT on the other hand can operate in multiple
>>> different modes, from which we currently choose the
>>> 3x1024 non-interpoated mode. Which can do all those
>>> things the degamma LUT can't do.
>>>
>>>>>> On hsw+ we do
>>>>>>       use this trick already to get the gamma+limited range right,
>>>>>>       but on these platforms the hw gamma and degamma LUTs have
>>>>>>       identical capabilities.
>>>>>> c) do the range compression with the hw gamma LUT instead, which
>>>>>>       of course means we have to combine the user gamma and range
>>>>>>       compression into the same gamma LUT.
>>>> Nice w/a and in amdgpu we are using also curve concatenations into re gamma LUT.
>>>>
>>>> The number of concatenations could be as many as need it and we may take advantage of this in user mode. Does this sounds preliminarily  good?
>>>>
>>>> Wouldn't the following sentence be interesting for you if the user mode generates 1D LUT points using X axis exponential distribution to avoid
>>>> unnecessary interpolation in kernel?  It may be especially important if curve concatenation is expected?
>>> Yeah, I think we want a new uapi for gamma stuff that will allow
>>> userspace to properly calculate things up front for different kinds
>>> of hw implementations, without the kernel having to interpolate/decimate.
>>> We've had some discussions/proposals on the list.
>>>
>>>>>> So I think c) is what it should be. Would just need to find the time
>>>>>> to implement it, and figure out how to not totally mess up our
>>>>>> driver's hw state checker. Hmm, except this won't help at all
>>>>>> with YCbCr output since we need to apply gamma before the
>>>>>> RGB->YCbCr conversion (which uses the same CSC again). Argh.
>>>>>> So YCbCr output would still need option b).
>>>>>>
>>>>>> Thankfully icl+ fixed all this by adding a dedicated output CSC
>>>>>> unit which sits after the gamma LUT in the pipeline. And pre-hsw
>>>>>> is almost fine as well since the hw has a dedicated fixed function
>>>>>> thing for the range compression. So the only snag on pre-hsw
>>>>>> is the YCbCr+degamma+gamma case.
>>>> Where is the display engine scaler is located on Intel platforms?
>>>> AMD old ASIC's have a display scaler after display color pipeline ,so the whole color processing can be a bit mess up unless integer scaling is in use.
>>>>
>>>> The new ASIC's ( ~5 years already)  have scaler before color pipeline.
>>> We have a somewhat similar situation.
>>>
>>> On older hw the scaler tap point is at the end of the pipe, so
>>> between the gamma LUT and dithering.
>>>
>>> On icl+ I think we have two tap points; one between degamma
>>> LUT and the first pipe CSC, and a second one between the output
>>> CSC and dithering. The spec calls these non-linear and linear tap
>>> points. The scaler also gained another linear vs. non-linear
>>> control knob which affects the precision at which it can operate
>>> in some form. There's also some other interaction between this and
>>> another knob ("HDR" mode) which controls the precision of blending
>>> in the pipe. I haven't yet thought how we should configure all this
>>> to the best effect. For the moment we leave these scaler settings
>>> to their defaults, which means using the non-linear tap point and
>>> non-linear precision setting. The blending precision we adjust
>>> dynamically depending on which planes are enabled. Only a subset
>>> of the planes (so called HDR planes) can be enabled when using the
>>> high precision blending mode.
>>>
>>> On icl+ plane scaling also has the two different tap points, but
>>> this time I think it just depdends on the type of plane used;
>>> HDR planes have a linear tap point just before blending, SDR
>>> planes have a non-linear tap point right after the pixels enter
>>> the plane's pipeline. Older hw again just had the non-linear
>>> tap point.
>> Thanks for the clarification Ville!
>>
>> I am not sure if i understood correctly tap points.
>>
>> Are you referring that you have full 2 scalers and each-one can do horizontal and vertical scaling?
>>
>> The first scaler does scaling in linear space and and the second in non linear. Is it correct?
> There are two scalers per pipe, each will do the full horz+vert scaling,
> and each one can be assigned to either:
> - any HDR plane linear tap point to scale the plane
> - any SDR plane non-linear tap point to scale the plane
> - pipe linear pipe tap point to scale the whole crtc output
> - pipe non-linear tap point to scale the whole crtc output
>
> I don't think you're supposed to assign scalers to both of
> the pipe tap points simultaneously. The registers might allow
> it though, so could be an interesting experiment :P
>   
>> I just found thread from Pekka :https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fwayland-devel%2F2020-October%2F041637.html&amp;data=04%7C01%7Cvitaly.prosyak%40amd.com%7C3f9bc0029f3f4302eedd08d875ce8004%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637388877054321803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=yfBke%2BWwsh8P0i37qAkGNRjyUUKFC4mD%2BXJ5gqyFEM0%3D&amp;reserved=0
>>
>> regarding integer scaling and other related stuff.
>>
>> AMD display engine has always 1 scaler, we do concatenation of two or more scaling transforms into one if it is necessary.
>>
>> Old ASIC's do scaling in nonlinear space, new ASIC's in linear space since scaler precision is half float.
>>
>> All these questions are become important for hardware composition and if the differences are too big( not sure about this) and it can't be abstracted.
>>
>> As one approach , can we think about shared object in user mode for each vendor ( this approach was in android for hardware composition) and this small component can do
>>
>> LUT's , scaler coefficients content and other not compatible stuff ) ?
> The idea has come up before. Getting any kind of acceptance for such a
> thing across the various userspace components would probably require
> a full time lobbyist.

That's for sure.

>
> I think various forms of gamma and CSC should be possible to abstract
> in a somewhat reasonable way. For scaling we're now moving ahead with
> the enum prop to specify the filter. If there was a real need we could
> even try to abstract some kind of filter coefficients uapi as well.
> I suspect most things would have some kind of polyphase FIR filter.

Yes, AMD display pipe has a polyphase scaler.
Thanks for sharing ideas .

> -- Ville Syrjälä Intel

vitaly


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

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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel