On 2021-08-16 14:40, Harry Wentland wrote:
On 2021-08-16 7:10 a.m., Brian Starkey wrote:
On Fri, Aug 13, 2021 at 10:42:12AM +0530, Sharma, Shashank wrote:
Hello Brian,
(+Uma in cc)
Thanks for your comments, Let me try to fill-in for Harry to keep the
design
discussion going. Please find my comments inline.
Thanks, Shashank. I'm back at work now. Had to cut my trip short
due to rising Covid cases and concern for my kids.
On 8/2/2021 10:00 PM, Brian Starkey wrote:
-- snip --
Android doesn't blend in linear space, so any API shouldn't be built
around an assumption of linear blending.
This seems incorrect but I guess ultimately the OS is in control of
this. If we want to allow blending in non-linear space with the new
API we would either need to describe the blending space or the
pre/post-blending gamma/de-gamma.
Any idea if this blending behavior in Android might get changed in
the future?
There is lots of software which blends in sRGB space and designers
adjusted to the incorrect blending in a way that the result looks right.
Blending in linear space would result in incorrectly looking images.
If I am not wrong, we still need linear buffers for accurate Gamut
transformation (SRGB -> BT2020 or other way around) isn't it ?
Yeah, you need to transform the buffer to linear for color gamut
conversions, but then back to non-linear (probably sRGB or gamma 2.2)
for actual blending.
This is why I'd like to have the per-plane "OETF/GAMMA" separate
from tone-mapping, so that the composition transfer function is
independent.
...
+
+Tonemapping in this case could be a simple nits value or `EDR`_ to
describe
+how to scale the :ref:`SDR luminance`.
+
+Tonemapping could also include the ability to use a 3D LUT which
might be
+accompanied by a 1D shaper LUT. The shaper LUT is required in
order to
+ensure a 3D LUT with limited entries (e.g. 9x9x9, or 17x17x17)
operates
+in perceptual (non-linear) space, so as to evenly spread the
limited
+entries evenly across the perceived space.
Some terminology care may be needed here - up until this point, I
think you've been talking about "tonemapping" being luminance
adjustment, whereas I'd expect 3D LUTs to be used for gamut
adjustment.
IMO, what harry wants to say here is that, which HW block gets picked
and
how tone mapping is achieved can be a very driver/HW specific thing,
where
one driver can use a 1D/Fixed function block, whereas another one can
choose
more complex HW like a 3D LUT for the same.
DRM layer needs to define only the property to hook the API with core
driver, and the driver can decide which HW to pick and configure for
the
activity. So when we have a tonemapping property, we might not have a
separate 3D-LUT property, or the driver may fail the atomic_check()
if both
of them are programmed for different usages.
I still think that directly exposing the HW blocks and their
capabilities is the right approach, rather than a "magic" tonemapping
property.
Yes, userspace would need to have a good understanding of how to use
that hardware, but if the pipeline model is standardised that's the
kind of thing a cross-vendor library could handle.
One problem with cross-vendor libraries is that they might struggle
to really be cross-vendor when it comes to unique HW behavior. Or
they might pick sub-optimal configurations as they're not aware of
the power impact of a configuration. What's an optimal configuration
might differ greatly between different HW.
We're seeing this problem with "universal" planes as well.
I'm repeating what has been said before but apparently it has to be said
again: if a property can't be replicated exactly in a shader the
property is useless. If your hardware is so unique that it can't give us
the exact formula we expect you cannot expose the property.
Maybe my view on power consumption is simplistic but I would expect enum
< 1d lut < 3d lut < shader. Is there more to it?
Either way if the fixed KMS pixel pipeline is not sufficient to expose
the intricacies of real hardware the right move would be to make the KMS
pixel pipeline more dynamic, expose more hardware specifics and create a
hardware specific user space like mesa. Moving the whole compositing
with all its policies and decision making into the kernel is exactly the
wrong way to go.
Laurent Pinchart put this very well:
https://lists.freedesktop.org/archives/dri-devel/2021-June/311689.html
It would definitely be good to get some compositor opinions here.
For this we'll probably have to wait for Pekka's input when he's
back from his vacation.
Cheers,
-Brian
