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