<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 2020-10-19 3:49 a.m., Pekka Paalanen
wrote:<br>
</div>
<blockquote type="cite" cite="mid:20201019104948.5ae842c0@eldfell">
<div class="moz-text-plain" wrap="true" graphical-quote="true" style="font-family: -moz-fixed; font-size: 12px;" lang="x-unicode">
<pre class="moz-quote-pre" wrap="">On Fri, 16 Oct 2020 16:50:16 +0300
Ville Syrjälä <a class="moz-txt-link-rfc2396E" href="mailto:ville.syrjala@linux.intel.com" moz-do-not-send="true"><ville.syrjala@linux.intel.com></a> wrote:
</pre>
<blockquote type="cite" style="color: #000000;">
<pre class="moz-quote-pre" wrap="">On Mon, Oct 12, 2020 at 10:11:01AM +0300, Pekka Paalanen wrote:
</pre>
<blockquote type="cite" style="color: #000000;">
<pre class="moz-quote-pre" wrap="">On Fri, 9 Oct 2020 17:20:18 +0300
Ville Syrjälä <a class="moz-txt-link-rfc2396E" href="mailto:ville.syrjala@linux.intel.com" moz-do-not-send="true"><ville.syrjala@linux.intel.com></a> wrote:
</pre>
<blockquote type="cite" style="color: #000000;">
<pre class="moz-quote-pre" wrap="">On Fri, Oct 09, 2020 at 04:56:51PM +0300, Pekka Paalanen wrote:
</pre>
<blockquote type="cite" style="color: #000000;">
<pre class="moz-quote-pre" wrap="">On Fri, 9 Oct 2020 16:10:25 +0300
Ville Syrjälä <a class="moz-txt-link-rfc2396E" href="mailto:ville.syrjala@linux.intel.com" moz-do-not-send="true"><ville.syrjala@linux.intel.com></a> wrote:
</pre>
<blockquote type="cite" style="color: #000000;">
<pre class="moz-quote-pre" wrap="">On Fri, Oct 09, 2020 at 01:07:20PM +0100, Daniel Stone wrote:
</pre>
<blockquote type="cite" style="color: #000000;">
<pre class="moz-quote-pre" wrap="">Hi,
On Fri, 9 Oct 2020 at 10:24, Simon Ser <a class="moz-txt-link-rfc2396E" href="mailto:contact@emersion.fr" moz-do-not-send="true"><contact@emersion.fr></a> wrote:
</pre>
<blockquote type="cite" style="color: #000000;">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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)
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Thanks for the heads-up.
If userspace uses all available KMS color management properties
(CTM, LUTs, etc.) <b class="moz-txt-star"><span class="moz-txt-tag">*</span>and<span class="moz-txt-tag">*</span></b> 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?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
</div>
</blockquote>
<pre>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.
</pre>
<blockquote type="cite" cite="mid:20201019104948.5ae842c0@eldfell">
<div class="moz-text-plain" wrap="true" graphical-quote="true" style="font-family: -moz-fixed; font-size: 12px;" lang="x-unicode">
<blockquote type="cite" style="color: #000000;">
<pre class="moz-quote-pre" wrap="">
On glk in particular I <b class="moz-txt-star"><span class="moz-txt-tag">*</span>think<span class="moz-txt-tag">*</span></b> 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. </pre>
</blockquote>
</div>
</blockquote>
<pre>Do you mean that hw de-gamma LUT build on ROM ( it is not programmable, just select the proper bit)?
</pre>
<blockquote type="cite" cite="mid:20201019104948.5ae842c0@eldfell">
<div class="moz-text-plain" wrap="true" graphical-quote="true" style="font-family: -moz-fixed; font-size: 12px;" lang="x-unicode">
<blockquote type="cite" style="color: #000000;">
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
</div>
</blockquote>
<pre>Nice w/a and in amdgpu we are using also curve concatenations into re gamma LUT.</pre>
<pre>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?
</pre>
<pre>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?
</pre>
<blockquote type="cite" cite="mid:20201019104948.5ae842c0@eldfell">
<div class="moz-text-plain" wrap="true" graphical-quote="true" style="font-family: -moz-fixed; font-size: 12px;" lang="x-unicode">
<blockquote type="cite" style="color: #000000;">
<pre class="moz-quote-pre" wrap="">
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.
</pre>
</blockquote>
</div>
</blockquote>
<pre>Where is the display engine scaler is located on Intel platforms?</pre>
<pre>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.</pre>
<pre>The new ASIC's ( ~5 years already) have scaler before color pipeline.
</pre>
<blockquote type="cite" cite="mid:20201019104948.5ae842c0@eldfell">
<div class="moz-text-plain" wrap="true" graphical-quote="true" style="font-family: -moz-fixed; font-size: 12px;" lang="x-unicode">
<pre class="moz-quote-pre" wrap="">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
</pre>
</div>
</blockquote>
<div class="moz-signature">
<pre>Thanks, Vitaly</pre>
</div>
</body>
</html>