Message ID | 20220808162750.828001-2-randy.li@synaptics.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | Add pixel formats used in Synatpics SoC | expand |
Hi Randy, On Tue, Aug 9, 2022 at 1:28 AM Hsia-Jun Li <randy.li@synaptics.com> wrote: > > From: "Hsia-Jun(Randy) Li" <randy.li@synaptics.com> > > Memory Traffic Reduction(MTR) is a module in Synaptics > VideoSmart platform could process lossless compression image > and cache the tile memory line. > > Those modifiers only record the parameters would effort pixel > layout or memory layout. Whether physical memory page mapping > is used is not a part of format. > > We would allocate the same size of memory for uncompressed > and compressed luma and chroma data, while the compressed buffer > would request two extra planes holding the metadata for > the decompression. > > The reason why we need to allocate the same size of memory for > the compressed frame: > 1. The compression ratio is not fixed and differnt platforms could > use a different compression protocol. These protocols are complete > vendor proprietaries, the other device won't be able to use them. > It is not necessary to define the version of them here. > > 2. Video codec could discard the compression attribute when the > intra block copy applied to this frame. It would waste lots of > time on re-allocation. > > I am wondering if it is better to add an addtional plane property to > describe whether the current framebuffer is compressed? > While the compression flag is still a part of format modifier, > because it would have two extra meta data planes in the compression > version. > > Signed-off-by: Hsia-Jun(Randy) Li <randy.li@synaptics.com> > --- > include/uapi/drm/drm_fourcc.h | 49 +++++++++++++++++++++++++++++++++++ > 1 file changed, 49 insertions(+) > > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h > index 0206f812c569..b67884e8bc69 100644 > --- a/include/uapi/drm/drm_fourcc.h > +++ b/include/uapi/drm/drm_fourcc.h > @@ -381,6 +381,7 @@ extern "C" { > #define DRM_FORMAT_MOD_VENDOR_ARM 0x08 > #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09 > #define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a > +#define DRM_FORMAT_MOD_VENDOR_SYNAPTICS 0x0b > > /* add more to the end as needed */ > > @@ -1452,6 +1453,54 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier) > #define AMD_FMT_MOD_CLEAR(field) \ > (~((__u64)AMD_FMT_MOD_##field##_MASK << AMD_FMT_MOD_##field##_SHIFT)) > > +/* > + * Synaptics VideoSmart modifiers > + * > + * Macro > + * Bits Param Description > + * ---- ----- ----------------------------------------------------------------- > + * > + * 7:0 f Scan direction description. > + * > + * 0 = Invalid > + * 1 = V4, the scan would always start from vertical for 4 pixel > + * then move back to the start pixel of the next horizontal > + * direction. > + * 2 = Reserved for future use. I guess 2..255 are all reserved for future use? > + * > + * 15:8 m The times of pattern repeat in the right angle direction from > + * the first scan direction. > + * > + * 19:16 p The padding bits after the whole scan, could be zero. What is the meaning of "scan" and "whole scan" here? Best regards, Tomasz > + * > + * 35:20 - Reserved for future use. Must be zero. > + * > + * 36:36 c Compression flag. > + * > + * 55:37 - Reserved for future use. Must be zero. > + * > + */ > + > +#define DRM_FORMAT_MOD_SYNA_V4_TILED fourcc_mod_code(SYNAPTICS, 1) > + > +#define DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(f, m, p, c) \ > + fourcc_mod_code(SYNAPTICS, (((f) & 0xff) | \ > + (((m) & 0xff) << 8) | \ > + (((p) & 0xf) << 16) | \ > + (((c) & 0x1) << 36))) > + > +#define DRM_FORMAT_MOD_SYNA_V4H1 \ > + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 1, 0, 0) > + > +#define DRM_FORMAT_MOD_SYNA_V4H3P8 \ > + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 3, 8, 0) > + > +#define DRM_FORMAT_MOD_SYNA_V4H1_COMPRESSED \ > + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 1, 0, 1) > + > +#define DRM_FORMAT_MOD_SYNA_V4H3P8_COMPRESSED \ > + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 3, 8, 1) > + > #if defined(__cplusplus) > } > #endif > -- > 2.17.1 >
On 8/18/22 14:07, Tomasz Figa wrote: > CAUTION: Email originated externally, do not click links or open attachments unless you recognize the sender and know the content is safe. > > > Hi Randy, > > On Tue, Aug 9, 2022 at 1:28 AM Hsia-Jun Li <randy.li@synaptics.com> wrote: >> >> From: "Hsia-Jun(Randy) Li" <randy.li@synaptics.com> >> >> Memory Traffic Reduction(MTR) is a module in Synaptics >> VideoSmart platform could process lossless compression image >> and cache the tile memory line. >> >> Those modifiers only record the parameters would effort pixel >> layout or memory layout. Whether physical memory page mapping >> is used is not a part of format. >> >> We would allocate the same size of memory for uncompressed >> and compressed luma and chroma data, while the compressed buffer >> would request two extra planes holding the metadata for >> the decompression. >> >> The reason why we need to allocate the same size of memory for >> the compressed frame: >> 1. The compression ratio is not fixed and differnt platforms could >> use a different compression protocol. These protocols are complete >> vendor proprietaries, the other device won't be able to use them. >> It is not necessary to define the version of them here. >> >> 2. Video codec could discard the compression attribute when the >> intra block copy applied to this frame. It would waste lots of >> time on re-allocation. >> >> I am wondering if it is better to add an addtional plane property to >> describe whether the current framebuffer is compressed? >> While the compression flag is still a part of format modifier, >> because it would have two extra meta data planes in the compression >> version. >> >> Signed-off-by: Hsia-Jun(Randy) Li <randy.li@synaptics.com> >> --- >> include/uapi/drm/drm_fourcc.h | 49 +++++++++++++++++++++++++++++++++++ >> 1 file changed, 49 insertions(+) >> >> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h >> index 0206f812c569..b67884e8bc69 100644 >> --- a/include/uapi/drm/drm_fourcc.h >> +++ b/include/uapi/drm/drm_fourcc.h >> @@ -381,6 +381,7 @@ extern "C" { >> #define DRM_FORMAT_MOD_VENDOR_ARM 0x08 >> #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09 >> #define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a >> +#define DRM_FORMAT_MOD_VENDOR_SYNAPTICS 0x0b >> >> /* add more to the end as needed */ >> >> @@ -1452,6 +1453,54 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier) >> #define AMD_FMT_MOD_CLEAR(field) \ >> (~((__u64)AMD_FMT_MOD_##field##_MASK << AMD_FMT_MOD_##field##_SHIFT)) >> >> +/* >> + * Synaptics VideoSmart modifiers >> + * >> + * Macro >> + * Bits Param Description >> + * ---- ----- ----------------------------------------------------------------- >> + * >> + * 7:0 f Scan direction description. >> + * >> + * 0 = Invalid >> + * 1 = V4, the scan would always start from vertical for 4 pixel >> + * then move back to the start pixel of the next horizontal >> + * direction. >> + * 2 = Reserved for future use. > > I guess 2..255 are all reserved for future use? Likes the Intel has y-tile and x-tile. > >> + * >> + * 15:8 m The times of pattern repeat in the right angle direction from >> + * the first scan direction. >> + * >> + * 19:16 p The padding bits after the whole scan, could be zero. > > What is the meaning of "scan" and "whole scan" here? For example a NV15 tiled format, (0, 0) (0, 1) (0, 2) (1, 0) (1, 1) (2, 0) (2, 1) (3, 0) (0, 0) (1, 0) (2, 0) (3, 0) (0, 1) (1, 1) (2, 1) ... (3, 2) are 120bits, then fill it with an extra 8 bits, (0, 3) would be placed that the first 128bits in the memory. Besides, I found even with four 64bits modifiers, it is not possible to store all the compression options we need there. I need to borrow what Intel did, hiding the tile flags somewhere(I would not use the userspace gmmlib way, our codecs is based on v4l2, even drm framework may not be a good place). Although the compression options could affect the memory layout but userspace really don't need to know that. > > Best regards, > Tomasz > >> + * >> + * 35:20 - Reserved for future use. Must be zero. >> + * >> + * 36:36 c Compression flag. >> + * >> + * 55:37 - Reserved for future use. Must be zero. >> + * >> + */ >> + >> +#define DRM_FORMAT_MOD_SYNA_V4_TILED fourcc_mod_code(SYNAPTICS, 1) >> + >> +#define DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(f, m, p, c) \ >> + fourcc_mod_code(SYNAPTICS, (((f) & 0xff) | \ >> + (((m) & 0xff) << 8) | \ >> + (((p) & 0xf) << 16) | \ >> + (((c) & 0x1) << 36))) >> + >> +#define DRM_FORMAT_MOD_SYNA_V4H1 \ >> + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 1, 0, 0) >> + >> +#define DRM_FORMAT_MOD_SYNA_V4H3P8 \ >> + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 3, 8, 0) >> + >> +#define DRM_FORMAT_MOD_SYNA_V4H1_COMPRESSED \ >> + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 1, 0, 1) >> + >> +#define DRM_FORMAT_MOD_SYNA_V4H3P8_COMPRESSED \ >> + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 3, 8, 1) >> + >> #if defined(__cplusplus) >> } >> #endif >> -- >> 2.17.1 >>
Hi Hsia-Jun, Thank you for the patch. On Tue, Aug 09, 2022 at 12:27:49AM +0800, Hsia-Jun Li wrote: > From: "Hsia-Jun(Randy) Li" <randy.li@synaptics.com> > > Memory Traffic Reduction(MTR) is a module in Synaptics > VideoSmart platform could process lossless compression image > and cache the tile memory line. > > Those modifiers only record the parameters would effort pixel > layout or memory layout. Whether physical memory page mapping > is used is not a part of format. > > We would allocate the same size of memory for uncompressed > and compressed luma and chroma data, while the compressed buffer > would request two extra planes holding the metadata for > the decompression. > > The reason why we need to allocate the same size of memory for > the compressed frame: > 1. The compression ratio is not fixed and differnt platforms could > use a different compression protocol. These protocols are complete > vendor proprietaries, the other device won't be able to use them. > It is not necessary to define the version of them here. > > 2. Video codec could discard the compression attribute when the > intra block copy applied to this frame. It would waste lots of > time on re-allocation. > > I am wondering if it is better to add an addtional plane property to > describe whether the current framebuffer is compressed? > While the compression flag is still a part of format modifier, > because it would have two extra meta data planes in the compression > version. Would it possible to show an example of how these modifiers apply to a particular format (such as NV12 for instance) ? Otherwise I'm having trouble understanding how they actually work. > Signed-off-by: Hsia-Jun(Randy) Li <randy.li@synaptics.com> > --- > include/uapi/drm/drm_fourcc.h | 49 +++++++++++++++++++++++++++++++++++ > 1 file changed, 49 insertions(+) > > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h > index 0206f812c569..b67884e8bc69 100644 > --- a/include/uapi/drm/drm_fourcc.h > +++ b/include/uapi/drm/drm_fourcc.h > @@ -381,6 +381,7 @@ extern "C" { > #define DRM_FORMAT_MOD_VENDOR_ARM 0x08 > #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09 > #define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a > +#define DRM_FORMAT_MOD_VENDOR_SYNAPTICS 0x0b > > /* add more to the end as needed */ > > @@ -1452,6 +1453,54 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier) > #define AMD_FMT_MOD_CLEAR(field) \ > (~((__u64)AMD_FMT_MOD_##field##_MASK << AMD_FMT_MOD_##field##_SHIFT)) > > +/* > + * Synaptics VideoSmart modifiers > + * > + * Macro > + * Bits Param Description > + * ---- ----- ----------------------------------------------------------------- > + * > + * 7:0 f Scan direction description. > + * > + * 0 = Invalid > + * 1 = V4, the scan would always start from vertical for 4 pixel > + * then move back to the start pixel of the next horizontal > + * direction. > + * 2 = Reserved for future use. > + * > + * 15:8 m The times of pattern repeat in the right angle direction from > + * the first scan direction. > + * > + * 19:16 p The padding bits after the whole scan, could be zero. > + * > + * 35:20 - Reserved for future use. Must be zero. > + * > + * 36:36 c Compression flag. > + * > + * 55:37 - Reserved for future use. Must be zero. > + * > + */ > + > +#define DRM_FORMAT_MOD_SYNA_V4_TILED fourcc_mod_code(SYNAPTICS, 1) > + > +#define DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(f, m, p, c) \ > + fourcc_mod_code(SYNAPTICS, (((f) & 0xff) | \ > + (((m) & 0xff) << 8) | \ > + (((p) & 0xf) << 16) | \ > + (((c) & 0x1) << 36))) > + > +#define DRM_FORMAT_MOD_SYNA_V4H1 \ > + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 1, 0, 0) > + > +#define DRM_FORMAT_MOD_SYNA_V4H3P8 \ > + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 3, 8, 0) > + > +#define DRM_FORMAT_MOD_SYNA_V4H1_COMPRESSED \ > + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 1, 0, 1) > + > +#define DRM_FORMAT_MOD_SYNA_V4H3P8_COMPRESSED \ > + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 3, 8, 1) > + > #if defined(__cplusplus) > } > #endif
On 8/19/22 07:16, Laurent Pinchart wrote: > CAUTION: Email originated externally, do not click links or open attachments unless you recognize the sender and know the content is safe. > > > Hi Hsia-Jun, > > Thank you for the patch. > > On Tue, Aug 09, 2022 at 12:27:49AM +0800, Hsia-Jun Li wrote: >> From: "Hsia-Jun(Randy) Li" <randy.li@synaptics.com> >> >> Memory Traffic Reduction(MTR) is a module in Synaptics >> VideoSmart platform could process lossless compression image >> and cache the tile memory line. >> >> Those modifiers only record the parameters would effort pixel >> layout or memory layout. Whether physical memory page mapping >> is used is not a part of format. >> >> We would allocate the same size of memory for uncompressed >> and compressed luma and chroma data, while the compressed buffer >> would request two extra planes holding the metadata for >> the decompression. >> >> The reason why we need to allocate the same size of memory for >> the compressed frame: >> 1. The compression ratio is not fixed and differnt platforms could >> use a different compression protocol. These protocols are complete >> vendor proprietaries, the other device won't be able to use them. >> It is not necessary to define the version of them here. >> >> 2. Video codec could discard the compression attribute when the >> intra block copy applied to this frame. It would waste lots of >> time on re-allocation. >> >> I am wondering if it is better to add an addtional plane property to >> describe whether the current framebuffer is compressed? >> While the compression flag is still a part of format modifier, >> because it would have two extra meta data planes in the compression >> version. > > Would it possible to show an example of how these modifiers apply to a > particular format (such as NV12 for instance) ? Otherwise I'm having > trouble understanding how they actually workThis version didn't contains the big tile information as I was considering moving them into compression options. The uncompressed tile in big tile pixel formats do exist, but I never see them being used. Anyway, let me just try to describe the most simple tile here. For example a NV12 tile format(V4H1) (0, 0) (0, 1) (0, 2) (1, 0) (1, 1) (2, 0) (2, 1) (3, 0) (0, 0) (1, 0) (2, 0) (3, 0) is a tile, then (0, 1)..(3, 1) after that. (4, 0) is after (3, y). For example a NV15 tiled format(V4H3P8), (0, 0) (0, 1) (0, 2) (1, 0) (1, 1) (2, 0) (2, 1) (3, 0) (0, 0) (1, 0) (2, 0) (3, 0) (0, 1) (1, 1) (2, 1) ... (3, 2) are 120bits, then fill it with an extra 8 bits, (0, 3) would be placed that the first 128bits in the memory. > >> Signed-off-by: Hsia-Jun(Randy) Li <randy.li@synaptics.com> >> --- >> include/uapi/drm/drm_fourcc.h | 49 +++++++++++++++++++++++++++++++++++ >> 1 file changed, 49 insertions(+) >> >> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h >> index 0206f812c569..b67884e8bc69 100644 >> --- a/include/uapi/drm/drm_fourcc.h >> +++ b/include/uapi/drm/drm_fourcc.h >> @@ -381,6 +381,7 @@ extern "C" { >> #define DRM_FORMAT_MOD_VENDOR_ARM 0x08 >> #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09 >> #define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a >> +#define DRM_FORMAT_MOD_VENDOR_SYNAPTICS 0x0b >> >> /* add more to the end as needed */ >> >> @@ -1452,6 +1453,54 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier) >> #define AMD_FMT_MOD_CLEAR(field) \ >> (~((__u64)AMD_FMT_MOD_##field##_MASK << AMD_FMT_MOD_##field##_SHIFT)) >> >> +/* >> + * Synaptics VideoSmart modifiers >> + * >> + * Macro >> + * Bits Param Description >> + * ---- ----- ----------------------------------------------------------------- >> + * >> + * 7:0 f Scan direction description. >> + * >> + * 0 = Invalid >> + * 1 = V4, the scan would always start from vertical for 4 pixel >> + * then move back to the start pixel of the next horizontal >> + * direction. >> + * 2 = Reserved for future use. >> + * >> + * 15:8 m The times of pattern repeat in the right angle direction from >> + * the first scan direction. >> + * >> + * 19:16 p The padding bits after the whole scan, could be zero. >> + * >> + * 35:20 - Reserved for future use. Must be zero. >> + * >> + * 36:36 c Compression flag. >> + * >> + * 55:37 - Reserved for future use. Must be zero. >> + * >> + */ >> + >> +#define DRM_FORMAT_MOD_SYNA_V4_TILED fourcc_mod_code(SYNAPTICS, 1) >> + >> +#define DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(f, m, p, c) \ >> + fourcc_mod_code(SYNAPTICS, (((f) & 0xff) | \ >> + (((m) & 0xff) << 8) | \ >> + (((p) & 0xf) << 16) | \ >> + (((c) & 0x1) << 36))) >> + >> +#define DRM_FORMAT_MOD_SYNA_V4H1 \ >> + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 1, 0, 0) >> + >> +#define DRM_FORMAT_MOD_SYNA_V4H3P8 \ >> + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 3, 8, 0) >> + >> +#define DRM_FORMAT_MOD_SYNA_V4H1_COMPRESSED \ >> + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 1, 0, 1) >> + >> +#define DRM_FORMAT_MOD_SYNA_V4H3P8_COMPRESSED \ >> + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 3, 8, 1) >> + >> #if defined(__cplusplus) >> } >> #endif > > -- > Regards, > > Laurent Pinchart
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h index 0206f812c569..b67884e8bc69 100644 --- a/include/uapi/drm/drm_fourcc.h +++ b/include/uapi/drm/drm_fourcc.h @@ -381,6 +381,7 @@ extern "C" { #define DRM_FORMAT_MOD_VENDOR_ARM 0x08 #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09 #define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a +#define DRM_FORMAT_MOD_VENDOR_SYNAPTICS 0x0b /* add more to the end as needed */ @@ -1452,6 +1453,54 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier) #define AMD_FMT_MOD_CLEAR(field) \ (~((__u64)AMD_FMT_MOD_##field##_MASK << AMD_FMT_MOD_##field##_SHIFT)) +/* + * Synaptics VideoSmart modifiers + * + * Macro + * Bits Param Description + * ---- ----- ----------------------------------------------------------------- + * + * 7:0 f Scan direction description. + * + * 0 = Invalid + * 1 = V4, the scan would always start from vertical for 4 pixel + * then move back to the start pixel of the next horizontal + * direction. + * 2 = Reserved for future use. + * + * 15:8 m The times of pattern repeat in the right angle direction from + * the first scan direction. + * + * 19:16 p The padding bits after the whole scan, could be zero. + * + * 35:20 - Reserved for future use. Must be zero. + * + * 36:36 c Compression flag. + * + * 55:37 - Reserved for future use. Must be zero. + * + */ + +#define DRM_FORMAT_MOD_SYNA_V4_TILED fourcc_mod_code(SYNAPTICS, 1) + +#define DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(f, m, p, c) \ + fourcc_mod_code(SYNAPTICS, (((f) & 0xff) | \ + (((m) & 0xff) << 8) | \ + (((p) & 0xf) << 16) | \ + (((c) & 0x1) << 36))) + +#define DRM_FORMAT_MOD_SYNA_V4H1 \ + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 1, 0, 0) + +#define DRM_FORMAT_MOD_SYNA_V4H3P8 \ + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 3, 8, 0) + +#define DRM_FORMAT_MOD_SYNA_V4H1_COMPRESSED \ + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 1, 0, 1) + +#define DRM_FORMAT_MOD_SYNA_V4H3P8_COMPRESSED \ + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 3, 8, 1) + #if defined(__cplusplus) } #endif