On Mon, 16 Aug 2021 15:37:23 +0200 sebastian@xxxxxxxxxxxxxxxxx wrote: > 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. Hi, yes, and I'm guilty of that too, at least by negligence. ;-) All Wayland compositors do it, since that's what everyone has always been doing, more or less. It's still physically wrong, but when all you have is sRGB and black window shadows and rounded corners as the only use case, you don't mind. When you start blending with colors other than black (gradients!), when you go to wide gamut, or especially with HDR, I believe the problems start to become painfully obvious. But as long as you're stuck with sRGB only, people expect the "wrong" result and deviating from that is a regression. Similarly, once Weston starts doing color management and people turn it on and install monitor profiles, I expect to get reports saying "all old apps look really dull now". That's how sRGB is defined to look like, they've been looking at something else for all that time. :-) Maybe we need a sRGB "gamut boost" similar to SDR luminance boost. ;-) > >> 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. From desktop perspective, yes, but I'm nowadays less adamant about it. If kernel developers are happy to maintain multiple alternative UAPIs, then I'm not going to try to NAK that - I'll just say when I can and cannot make use of them. Also everything is always up to some precision, and ultimately here it is a question of whether people can see the difference. Entertainment end user audience is also much more forgiving than professional color management audience. For the latter, I'd hesitate to use non-primary KMS planes at all. > 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 Thanks for digging that up, saved me the trouble. :-) Thanks, pq
Attachment:
pgpdMY_oeaDLv.pgp
Description: OpenPGP digital signature
