| Message ID | 20221202131658.434114-1-tomi.valkeinen+renesas@ideasonboard.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Support Y210 | expand |
On 02/12/2022 15:16, Tomi Valkeinen wrote: > From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> > > Hi, > > These kms++ patches add support for Y210 format. > > I didn't find a super clear description of the byte order for Y210 > anywhere. If someone knows what it is supposed to be, I'd appreciate > verifying the code =). Actually, this: https://learn.microsoft.com/en-us/windows/win32/medfound/10-bit-and-16-bit-yuv-video-formats#overview indicates that the 10-bit values should be shifted by 6. So the drawing code in this series is probably not right. Tomi
Hi Tomi, On Fri, Dec 2, 2022 at 4:32 PM Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> wrote: > On 02/12/2022 15:16, Tomi Valkeinen wrote: > > These kms++ patches add support for Y210 format. > > > > I didn't find a super clear description of the byte order for Y210 > > anywhere. If someone knows what it is supposed to be, I'd appreciate > > verifying the code =). > > Actually, this: > > https://learn.microsoft.com/en-us/windows/win32/medfound/10-bit-and-16-bit-yuv-video-formats#overview > > indicates that the 10-bit values should be shifted by 6. So the drawing > code in this series is probably not right. https://elixir.bootlin.com/linux/latest/source/include/uapi/drm/drm_fourcc.h#L212 seems to confirm that? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On 02/12/2022 17:56, Geert Uytterhoeven wrote: > Hi Tomi, > > On Fri, Dec 2, 2022 at 4:32 PM Tomi Valkeinen > <tomi.valkeinen@ideasonboard.com> wrote: >> On 02/12/2022 15:16, Tomi Valkeinen wrote: >>> These kms++ patches add support for Y210 format. >>> >>> I didn't find a super clear description of the byte order for Y210 >>> anywhere. If someone knows what it is supposed to be, I'd appreciate >>> verifying the code =). >> >> Actually, this: >> >> https://learn.microsoft.com/en-us/windows/win32/medfound/10-bit-and-16-bit-yuv-video-formats#overview >> >> indicates that the 10-bit values should be shifted by 6. So the drawing >> code in this series is probably not right. > > https://elixir.bootlin.com/linux/latest/source/include/uapi/drm/drm_fourcc.h#L212 > seems to confirm that? Hmm, indeed. I've looked at that before but I couldn't decipher it, but now the text makes sense. Although afaics, it doesn't say that each component is a 16-bit little endian. And I don't get the "little endian per 2 Y pixels". So if I get this right... The first byte in memory is the two lowest bits of Y0 in bits 6 and 7. The rest of the first byte is zero padding. The second byte is the 8 highest bits of Y0. Then following the same method, Cb, Y1, Cr. Tomi
On Fri, Dec 02, 2022 at 06:06:01PM +0200, Tomi Valkeinen wrote: > On 02/12/2022 17:56, Geert Uytterhoeven wrote: > > On Fri, Dec 2, 2022 at 4:32 PM Tomi Valkeinen wrote: > >> On 02/12/2022 15:16, Tomi Valkeinen wrote: > >>> These kms++ patches add support for Y210 format. > >>> > >>> I didn't find a super clear description of the byte order for Y210 > >>> anywhere. If someone knows what it is supposed to be, I'd appreciate > >>> verifying the code =). > >> > >> Actually, this: > >> > >> https://learn.microsoft.com/en-us/windows/win32/medfound/10-bit-and-16-bit-yuv-video-formats#overview > >> > >> indicates that the 10-bit values should be shifted by 6. So the drawing > >> code in this series is probably not right. > > > > https://elixir.bootlin.com/linux/latest/source/include/uapi/drm/drm_fourcc.h#L212 > > seems to confirm that? > > Hmm, indeed. I've looked at that before but I couldn't decipher it, but > now the text makes sense. Although afaics, it doesn't say that each > component is a 16-bit little endian. And I don't get the "little endian > per 2 Y pixels". > > So if I get this right... > > The first byte in memory is the two lowest bits of Y0 in bits 6 and 7. > The rest of the first byte is zero padding. > > The second byte is the 8 highest bits of Y0. > > Then following the same method, Cb, Y1, Cr. I would have said in bits 7 and 6 for the first byte, but I assume we mean the same. Apart from that, your interpretation is the same as mind. However, if your aim is to support the 10bpp YUV 4:2:2 format of the VSP, I'm not sure this is correct. Assuming you plan to set F2B=1 to align bits towards the MSB, it's not clear if the endianness can be configured. The four permutations of the packed YUYV components are achievable as far as I can tell (see figure 60.12 in the documentation), but I didn't immediately find a place where the endianness of each 16-bit value could be configured. Figure 60.15 mentions "example in case of big endian", I don't know if it's an example, or the only possible option. You may want to try both.
On 03/12/2022 01:47, Laurent Pinchart wrote: > On Fri, Dec 02, 2022 at 06:06:01PM +0200, Tomi Valkeinen wrote: >> On 02/12/2022 17:56, Geert Uytterhoeven wrote: >>> On Fri, Dec 2, 2022 at 4:32 PM Tomi Valkeinen wrote: >>>> On 02/12/2022 15:16, Tomi Valkeinen wrote: >>>>> These kms++ patches add support for Y210 format. >>>>> >>>>> I didn't find a super clear description of the byte order for Y210 >>>>> anywhere. If someone knows what it is supposed to be, I'd appreciate >>>>> verifying the code =). >>>> >>>> Actually, this: >>>> >>>> https://learn.microsoft.com/en-us/windows/win32/medfound/10-bit-and-16-bit-yuv-video-formats#overview >>>> >>>> indicates that the 10-bit values should be shifted by 6. So the drawing >>>> code in this series is probably not right. >>> >>> https://elixir.bootlin.com/linux/latest/source/include/uapi/drm/drm_fourcc.h#L212 >>> seems to confirm that? >> >> Hmm, indeed. I've looked at that before but I couldn't decipher it, but >> now the text makes sense. Although afaics, it doesn't say that each >> component is a 16-bit little endian. And I don't get the "little endian >> per 2 Y pixels". >> >> So if I get this right... >> >> The first byte in memory is the two lowest bits of Y0 in bits 6 and 7. >> The rest of the first byte is zero padding. >> >> The second byte is the 8 highest bits of Y0. >> >> Then following the same method, Cb, Y1, Cr. > > I would have said in bits 7 and 6 for the first byte, but I assume we > mean the same. Apart from that, your interpretation is the same as mind. > However, if your aim is to support the 10bpp YUV 4:2:2 format of the > VSP, I'm not sure this is correct. Assuming you plan to set F2B=1 to > align bits towards the MSB, it's not clear if the endianness can be > configured. The four permutations of the packed YUYV components are > achievable as far as I can tell (see figure 60.12 in the documentation), > but I didn't immediately find a place where the endianness of each > 16-bit value could be configured. Figure 60.15 mentions "example in case > of big endian", I don't know if it's an example, or the only possible > option. You may want to try both. The pixel format can be set using F2B and swap options in VI6_RPFn_DSWAP (Table 60.14). I have Y210 working (and I have had multiple other variations working too). And by "working" I mean that it looks good to me, but I can only see it via a web meeting as the board is at Kieran's. The HW seems to be very versatile, and a lot of different variations can be supported, especially for RGB formats. So this has been a bit difficult as I didn't have any ready and validated test tool to draw Y210, but I hope I got it working now correctly in kms++. I don't know what format for 10-bit YUV Renesas really needs, but the BSP commits said Y210, so that's what I added. Although afaik, the DU only handles 8-bits per component, so I'm not sure what's the benefit of 10-bit formats (especially for RGB). Tomi
From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Hi, These kms++ patches add support for Y210 format. I didn't find a super clear description of the byte order for Y210 anywhere. If someone knows what it is supposed to be, I'd appreciate verifying the code =). Tomi Tomi Valkeinen (4): kms++: PixelFormats: Fix formatting kms++: PixelFormats: Add Y210 format kms++util: Add endian.h kms++util: Add Y210 drawing support kms++/inc/kms++/pixelformats.h | 2 + kms++/src/pixelformats.cpp | 66 ++++++++------------------------ kms++util/inc/kms++util/endian.h | 46 ++++++++++++++++++++++ kms++util/src/drawing.cpp | 31 +++++++++++++++ 4 files changed, 95 insertions(+), 50 deletions(-) create mode 100644 kms++util/inc/kms++util/endian.h