From: Brian Starkey <Brian.Starkey@arm.com> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ayan Halder <Ayan.Halder@arm.com>, Liviu Dudau <Liviu.Dudau@arm.com>, "malidp@foss.arm.com" <malidp@foss.arm.com>, "maxime.ripard@bootlin.com" <maxime.ripard@bootlin.com>, "sean@poorly.run" <sean@poorly.run>, "airlied@linux.ie" <airlied@linux.ie>, "daniel@ffwll.ch" <daniel@ffwll.ch>, "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "alyssa@rosenzweig.io" <alyssa@rosenzweig.io>, nd <nd@arm.com>, Daniel Vetter <daniel.vetter@ffwll.ch>, Dave Airlie <airlied@gmail.com>, Swati Sharma <swati2.sharma@intel.com>, Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>, Vidya Srinivas <vidya.srinivas@intel.com> Subject: Re: [PATCH v4 01/10] drm/fourcc: Add AFBC yuv fourccs for Mali Date: Mon, 18 Mar 2019 19:00:57 +0000 [thread overview] Message-ID: <20190318190056.kr7vvgi5qqaiv6qi@DESKTOP-E1NTVVP.localdomain> (raw) In-Reply-To: <a67ec415-af2b-9ddd-9856-b5066ce2b791@linux.intel.com> On Mon, Mar 18, 2019 at 07:12:24PM +0100, Maarten Lankhorst wrote: > Op 18-03-2019 om 16:40 schreef Brian Starkey: > > Hi, > > > > On Mon, Mar 18, 2019 at 11:17:55AM +0100, Maarten Lankhorst wrote: > > > > <snip> > > > >> Hey.. > >> > >> There's a conflict with this patch and the merge of topic/hdr-formats, resulting in double definitions for Y210, Y410 and P010. > >> > >> Worse still is that one has set has_alpha to true for Y41x and other to false. > >> > >> ~Maarten > >> > > Oh that's sad :-( I think this fell through the cracks on our side > > when someone left our team. Also turns out I'm not subscribed to > > igt-dev. > > > > I see you commented the same on one of the previous patches, and that > > there was some discussion of this on the test patches too. > > > > I have been referring to Microsoft's page[1] as "the" source for these > > formats, which does indeed call out Y410 as having 2 bits of alpha. > > Our GPU expects alpha. > > Ah. Yeah there has been discussion on whether there was supposed to be alpha or not, but the original discussion on HDR formats has been completely ignored by arm. > > The patch had originally a few arm devs on cc and was sent to dri-devel with linux-media cc'd. Was sad to see it completely ignored so after having been sent twice I pushed it. That's the kernel patch(es)? It looks like I did receive them via dri-devel, and Ayan was Cc'd on two of the series', but it's disingenuous to say they had "a few Arm devs". I first submitted this patch with Y410 to dri-devel back in August, and since then it's been sent 8 times by my count (with you on Cc on all of them!), and all have been similarly completely ignored; so I'm sorry but I don't think you can put the blame entirely with Arm here. > > > Was there a specific reason for opting to change the test instead of > > the definition? Any way to get this changed now? > > > > It doesn't seem that sensible for the kernel to call something Y410 > > which doesn't match an "existing" definition by the same name. If > > alpha needs to be ignored on scanout, the alpha blend mode property > > can be used (more archaeology - I see that was still giving CRC > > failures, but that might be a "known issue" for all YUV on your HW?) > > Were a few bugs, but should be fixed now. :) > > Well only that we didn't have hw supporting alpha, and didn't hear back from others so we went without alpha. So what do you suggest? Can we change it, or we need to forever live with divergent definitions in DRM vs elsewhere? Gstreamer appears to have a Y410 definition including alpha[1], and there's the aforementioned Microsoft page too. To me it looks like we should change DRM, and if your HW supports something that's "almost but not quite" Y410 then you need a different name or only allow alpha-blend-mode "none". Thanks, -Brian [1] https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/commit/0ac7d1187b234e86157ad74937c249a3c016807c > > > -Brian > > > > [1] https://docs.microsoft.com/en-us/windows/desktop/medfound/10-bit-and-16-bit-yuv-video-formats#444-formats > >
WARNING: multiple messages have this Message-ID (diff)
From: Brian Starkey <Brian.Starkey@arm.com> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: nd <nd@arm.com>, Vidya Srinivas <vidya.srinivas@intel.com>, Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>, "maxime.ripard@bootlin.com" <maxime.ripard@bootlin.com>, Daniel Vetter <daniel.vetter@ffwll.ch>, Liviu Dudau <Liviu.Dudau@arm.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>, "airlied@linux.ie" <airlied@linux.ie>, "malidp@foss.arm.com" <malidp@foss.arm.com>, Swati Sharma <swati2.sharma@intel.com>, Ayan Halder <Ayan.Halder@arm.com>, "sean@poorly.run" <sean@poorly.run>, "alyssa@rosenzweig.io" <alyssa@rosenzweig.io> Subject: Re: [PATCH v4 01/10] drm/fourcc: Add AFBC yuv fourccs for Mali Date: Mon, 18 Mar 2019 19:00:57 +0000 [thread overview] Message-ID: <20190318190056.kr7vvgi5qqaiv6qi@DESKTOP-E1NTVVP.localdomain> (raw) In-Reply-To: <a67ec415-af2b-9ddd-9856-b5066ce2b791@linux.intel.com> On Mon, Mar 18, 2019 at 07:12:24PM +0100, Maarten Lankhorst wrote: > Op 18-03-2019 om 16:40 schreef Brian Starkey: > > Hi, > > > > On Mon, Mar 18, 2019 at 11:17:55AM +0100, Maarten Lankhorst wrote: > > > > <snip> > > > >> Hey.. > >> > >> There's a conflict with this patch and the merge of topic/hdr-formats, resulting in double definitions for Y210, Y410 and P010. > >> > >> Worse still is that one has set has_alpha to true for Y41x and other to false. > >> > >> ~Maarten > >> > > Oh that's sad :-( I think this fell through the cracks on our side > > when someone left our team. Also turns out I'm not subscribed to > > igt-dev. > > > > I see you commented the same on one of the previous patches, and that > > there was some discussion of this on the test patches too. > > > > I have been referring to Microsoft's page[1] as "the" source for these > > formats, which does indeed call out Y410 as having 2 bits of alpha. > > Our GPU expects alpha. > > Ah. Yeah there has been discussion on whether there was supposed to be alpha or not, but the original discussion on HDR formats has been completely ignored by arm. > > The patch had originally a few arm devs on cc and was sent to dri-devel with linux-media cc'd. Was sad to see it completely ignored so after having been sent twice I pushed it. That's the kernel patch(es)? It looks like I did receive them via dri-devel, and Ayan was Cc'd on two of the series', but it's disingenuous to say they had "a few Arm devs". I first submitted this patch with Y410 to dri-devel back in August, and since then it's been sent 8 times by my count (with you on Cc on all of them!), and all have been similarly completely ignored; so I'm sorry but I don't think you can put the blame entirely with Arm here. > > > Was there a specific reason for opting to change the test instead of > > the definition? Any way to get this changed now? > > > > It doesn't seem that sensible for the kernel to call something Y410 > > which doesn't match an "existing" definition by the same name. If > > alpha needs to be ignored on scanout, the alpha blend mode property > > can be used (more archaeology - I see that was still giving CRC > > failures, but that might be a "known issue" for all YUV on your HW?) > > Were a few bugs, but should be fixed now. :) > > Well only that we didn't have hw supporting alpha, and didn't hear back from others so we went without alpha. So what do you suggest? Can we change it, or we need to forever live with divergent definitions in DRM vs elsewhere? Gstreamer appears to have a Y410 definition including alpha[1], and there's the aforementioned Microsoft page too. To me it looks like we should change DRM, and if your HW supports something that's "almost but not quite" Y410 then you need a different name or only allow alpha-blend-mode "none". Thanks, -Brian [1] https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/commit/0ac7d1187b234e86157ad74937c249a3c016807c > > > -Brian > > > > [1] https://docs.microsoft.com/en-us/windows/desktop/medfound/10-bit-and-16-bit-yuv-video-formats#444-formats > > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-03-18 19:01 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-03-12 18:16 [PATCH v4 01/10] drm/fourcc: Add AFBC yuv fourccs for Mali Ayan Halder 2019-03-12 18:16 ` Ayan Halder 2019-03-12 18:16 ` [PATCH v4 02/10] drm: Added a new format DRM_FORMAT_XVYU2101010 Ayan Halder 2019-03-12 18:16 ` Ayan Halder 2019-03-12 18:16 ` [PATCH v4 03/10] drm/arm/malidp: Set the AFBC register bits if the framebuffer has AFBC modifier Ayan Halder 2019-03-12 18:16 ` Ayan Halder 2019-03-12 18:16 ` [PATCH v4 04/10] drm/arm/malidp:- Added support for new YUV formats for DP500, DP550 and DP650 Ayan Halder 2019-03-12 18:16 ` Ayan Halder 2019-03-12 18:16 ` [PATCH v4 05/10] drm/arm/malidp:- Define a common list of AFBC format modifiers supported " Ayan Halder 2019-03-12 18:16 ` Ayan Halder 2019-03-12 18:16 ` [PATCH v4 06/10] drm/arm/malidp: Specified the rotation memory requirements for AFBC YUV formats Ayan Halder 2019-03-12 18:16 ` Ayan Halder 2019-03-12 18:16 ` [PATCH v4 07/10] drm/arm/malidp:- Writeback framebuffer does not support any modifiers Ayan Halder 2019-03-12 18:16 ` Ayan Halder 2019-03-12 18:16 ` [PATCH v4 08/10] drm/arm/malidp:- Use the newly introduced malidp_format_get_bpp() instead of relying on cpp for calculating framebuffer size Ayan Halder 2019-03-12 18:16 ` Ayan Halder 2019-03-12 18:16 ` [PATCH v4 09/10] drm/arm/malidp:- Disregard the pitch alignment constraint for AFBC framebuffer Ayan Halder 2019-03-12 18:16 ` Ayan Halder 2019-03-12 18:16 ` [PATCH v4 10/10] drm/arm/malidp: Added support for AFBC modifiers for all layers except DE_SMART Ayan Halder 2019-03-12 18:16 ` Ayan Halder 2019-03-18 10:17 ` [PATCH v4 01/10] drm/fourcc: Add AFBC yuv fourccs for Mali Maarten Lankhorst 2019-03-18 15:40 ` Brian Starkey 2019-03-18 18:12 ` Maarten Lankhorst 2019-03-18 19:00 ` Brian Starkey [this message] 2019-03-18 19:00 ` Brian Starkey 2019-03-18 19:06 ` Brian Starkey 2019-03-18 19:06 ` Brian Starkey 2019-03-18 19:11 ` Brian Starkey 2019-03-18 23:27 ` Ayan Halder 2019-03-18 23:27 ` Ayan Halder 2019-03-19 16:08 ` Maarten Lankhorst 2019-03-19 16:08 ` Maarten Lankhorst
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190318190056.kr7vvgi5qqaiv6qi@DESKTOP-E1NTVVP.localdomain \ --to=brian.starkey@arm.com \ --cc=Ayan.Halder@arm.com \ --cc=Liviu.Dudau@arm.com \ --cc=airlied@gmail.com \ --cc=airlied@linux.ie \ --cc=alyssa@rosenzweig.io \ --cc=daniel.vetter@ffwll.ch \ --cc=daniel@ffwll.ch \ --cc=dri-devel@lists.freedesktop.org \ --cc=juhapekka.heikkila@gmail.com \ --cc=linux-kernel@vger.kernel.org \ --cc=maarten.lankhorst@linux.intel.com \ --cc=malidp@foss.arm.com \ --cc=maxime.ripard@bootlin.com \ --cc=nd@arm.com \ --cc=sean@poorly.run \ --cc=swati2.sharma@intel.com \ --cc=vidya.srinivas@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.