Re: [PATCH v4 01/10] drm/fourcc: Add AFBC yuv fourccs for Mali
Hey, Op 19-03-2019 om 00:27 schreef Ayan Halder: > 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: >>> >>> >>> 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. > Apologies, I see that I was cc-ed in the mail 'drm: Add Y2xx and Y4xx > (xx:10/12/16) format definitions and fourcc' sent by > swati2.sha...@intel.com. It got lost in my pile of unread mails. :( > > About this patch, I had tagged you in irc channel > (https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel_names==2019-03-11_html=true) > for reviewing this seies. Did not hear back from you then ? Looks like we both unfortunately not looked at each others series then, or at least I missed the HDR formats part. >>> 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. > In light of the suggestions made by brian.star...@arm.com, I think > changing the format from Y410 to X410 (in your case) might make sense > as the alpha bits are absent. > If this suggestion looks reasonable to you, I can volunteer myself to make > this change in topic/hdr-formats. I sent a patch to fix the conflicts. There's already XVYU2101010 in that series, which is Y410 without alpha. I've extended it and used it to convert i915. It's unfortunate those conflicts happen, but fortunately it didn't spread to drm-next or linux-next. Link: https://patchwork.freedesktop.org/patch/292977/?series=58182=1 Tested it, basic tests seems to work for i915. ~Maarten ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 01/10] drm/fourcc: Add AFBC yuv fourccs for Mali
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: > > > > > > > >> 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. Apologies, I see that I was cc-ed in the mail 'drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc' sent by swati2.sha...@intel.com. It got lost in my pile of unread mails. :( About this patch, I had tagged you in irc channel (https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel_names==2019-03-11_html=true) for reviewing this seies. Did not hear back from you then ? > > > 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. In light of the suggestions made by brian.star...@arm.com, I think changing the format from Y410 to X410 (in your case) might make sense as the alpha bits are absent. If this suggestion looks reasonable to you, I can volunteer myself to make this change in topic/hdr-formats. > > > -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
Re: [PATCH v4 01/10] drm/fourcc: Add AFBC yuv fourccs for Mali
On Mon, Mar 18, 2019 at 07:06:39PM +, Brian Starkey wrote: > > [1] > > https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/commit/0ac7d1187b234e86157ad74937c249a3c016807c > > Eh. I'm not familiar enough with the gitlab UI. Looks like this didn't > merge in GStreamer so far. Gah! Still wrong. It's in 1.16, with Alpha: https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-GstVideo.html#GstVideoFormat > > > > > > > > -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
Re: [PATCH v4 01/10] drm/fourcc: Add AFBC yuv fourccs for Mali
On Mon, Mar 18, 2019 at 07:00:57PM +, Brian Starkey wrote: > 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: > > > > > > > > > > > >> 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 Eh. I'm not familiar enough with the gitlab UI. Looks like this didn't merge in GStreamer so far. > > > > > -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
Re: [PATCH v4 01/10] drm/fourcc: Add AFBC yuv fourccs for Mali
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: > > > > > > > >> 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
Re: [PATCH v4 01/10] drm/fourcc: Add AFBC yuv fourccs for Mali
Op 18-03-2019 om 16:40 schreef Brian Starkey: > Hi, > > On Mon, Mar 18, 2019 at 11:17:55AM +0100, Maarten Lankhorst wrote: > > > >> 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. > 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. > -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
Re: [PATCH v4 01/10] drm/fourcc: Add AFBC yuv fourccs for Mali
Hi, On Mon, Mar 18, 2019 at 11:17:55AM +0100, Maarten Lankhorst wrote: > 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. 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?) -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
Re: [PATCH v4 01/10] drm/fourcc: Add AFBC yuv fourccs for Mali
Op 12-03-2019 om 19:16 schreef Ayan Halder: > From: Brian Starkey > > As we look to enable AFBC using DRM format modifiers, we run into > problems which we've historically handled via vendor-private details > (i.e. gralloc, on Android). > > AFBC (as an encoding) is fully flexible, and for example YUV data can > be encoded into 1, 2 or 3 encoded "planes", much like the linear > equivalents. Component order is also meaningful, as AFBC doesn't > necessarily care about what each "channel" of the data it encodes > contains. Therefore ABGR and RGBA can be encoded in AFBC with > different representations. Similarly, 'X' components may be encoded > into AFBC streams in cases where a decoder expects to decode a 4th > component. > > In addition, AFBC is a licensable IP, meaning that to support the > ecosystem we need to ensure that _all_ AFBC users are able to describe > the encodings that they need. This is much better achieved by > preserving meaning in the fourcc codes when they are combined with an > AFBC modifier. > > In essence, we want to use the modifier to describe the parameters of > the AFBC encode/decode, and use the fourcc code to describe the data > being encoded/decoded. > > To do anything different would be to introduce redundancy - we would > need to duplicate in the modifier information which is _already_ > conveyed clearly and non-ambigiously by a fourcc code. > > I hope that for RGB this is non-controversial. > (BGRA + MODIFIER_AFBC) is a different format from > (RGBA + MODIFIER_AFBC). > > Possibly more controversial is that (XBGR + MODIFIER_AFBC) > is different from (BGR888 + MODIFIER_AFBC). I understand that in some > schemes it is not the case - but in AFBC it is so. > > Where we run into problems is where there are not already fourcc codes > which represent the data which the AFBC encoder/decoder is processing. > To that end, we want to introduce new fourcc codes to describe the > data being encoded/decoded, in the places where none of the existing > fourcc codes are applicable. > > Where we don't support an equivalent non-compressed layout, or where > no "obvious" linear layout exists, we are proposing adding fourcc > codes which have no associated linear layout - because any layout we > proposed would be completely arbitrary. > > Some formats are following the naming conventions from [2]. > > The summary of the new formats is: > DRM_FORMAT_VUY888 - Packed 8-bit YUV 444. Y followed by U then V. > DRM_FORMAT_VUY101010 - Packed 10-bit YUV 444. Y followed by U then > V. No defined linear encoding. > DRM_FORMAT_Y210 - Packed 10-bit YUV 422. Y followed by U (then Y) >then V. 10-bit samples in 16-bit words. > DRM_FORMAT_Y410 - Packed 10-bit YUV 444, with 2-bit alpha. > DRM_FORMAT_P210 - Semi-planar 10-bit YUV 422. Y plane, followed by >interleaved U-then-V plane. 10-bit samples in >16-bit words. > DRM_FORMAT_YUV420_8BIT - Packed 8-bit YUV 420. Y followed by U then > V. No defined linear encoding > DRM_FORMAT_YUV420_10BIT - Packed 10-bit YUV 420. Y followed by U >then V. No defined linear encoding > > Please also note that in the absence of AFBC, we would still need to > add Y410, Y210 and P210. > > Full rationale follows: > > YUV 444 8-bit, 1-plane > -- > The currently defined AYUV format encodes a 4th alpha component, > which makes it unsuitable for representing a 3-component YUV 444 > AFBC stream. > > The proposed[1] XYUV format which is supported by Mali-DP in linear > layout is also unsuitable, because the component order is the > opposite of the AFBC version, and it encodes a 4th 'X' component. > > DRM_FORMAT_VUY888 is the "obvious" format for a 3-component, packed, > YUV 444 8-bit format, with the component order which our HW expects to > encode/decode. It conforms to the same naming convention as the > existing packed YUV 444 format. > The naming here is meant to be consistent with DRM_FORMAT_AYUV and > DRM_FORMAT_XYUV[1] > > YUV 444 10-bit, 1-plane > --- > There is no currently-defined YUV 444 10-bit format in > drm_fourcc.h, irrespective of number of planes. > > The proposed[1] XVYU2101010 format which is supported by Mali-DP in > linear layout uses the wrong component order, and also encodes a 4th > 'X' component, which doesn't match the AFBC version of YUV 444 > 10-bit which we support. > > DRM_FORMAT_Y410 is the same layout as XVYU2101010, but with 2 bits of > alpha. This format is supported with linear layout by Mali GPUs. The > naming follows[2]. > > There is no "obvious" linear encoding for a 3-component 10:10:10 > packed format, and so DRM_FORMAT_VUY101010 defines a component > order, but not a bit encoding. Again, the naming is meant to be > consistent with DRM_FORMAT_AYUV. > > YUV 422 8-bit, 1-plane > -- > The existing
