libdrm: Add framebuffer modifiers uapi
diff mbox

Message ID 1438595283-4076-1-git-send-email-tvrtko.ursulin@linux.intel.com
State New
Headers show

Commit Message

Tvrtko Ursulin Aug. 3, 2015, 9:48 a.m. UTC
From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Sync up with new kernel features as per commits:

e3eb3250d84ef97b766312345774367b6a310db8
93b81f5102a7cd270a305c2741b17c8d44bb0629
b5ff6e1637b683d5996ae11ac29afe406c0bee90
8c4f83fb1e8bf317e894f62d17a63c32b7a6b75e
570655b09b065d2fff1b8ab9bdb8308f4c5a05a3

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: dri-devel@lists.freedesktop.org
Cc: Rob Clark <robdclark@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 include/drm/drm.h        |  1 +
 include/drm/drm_fourcc.h | 93 ++++++++++++++++++++++++++++++++++++++++++++++++
 include/drm/drm_mode.h   | 11 +++++-
 3 files changed, 104 insertions(+), 1 deletion(-)

Comments

Tvrtko Ursulin Sept. 7, 2015, 2:18 p.m. UTC | #1
On 08/03/2015 10:48 AM, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>
> Sync up with new kernel features as per commits:
>
> e3eb3250d84ef97b766312345774367b6a310db8
> 93b81f5102a7cd270a305c2741b17c8d44bb0629
> b5ff6e1637b683d5996ae11ac29afe406c0bee90
> 8c4f83fb1e8bf317e894f62d17a63c32b7a6b75e
> 570655b09b065d2fff1b8ab9bdb8308f4c5a05a3

Ping anyone?

Can we review and merge this uapi catchup or some existing process will 
scoop it up at some point? It hasn't happened so far...

Regards,

Tvrtko

> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: Rob Clark <robdclark@gmail.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
>   include/drm/drm.h        |  1 +
>   include/drm/drm_fourcc.h | 93 ++++++++++++++++++++++++++++++++++++++++++++++++
>   include/drm/drm_mode.h   | 11 +++++-
>   3 files changed, 104 insertions(+), 1 deletion(-)
>
> diff --git a/include/drm/drm.h b/include/drm/drm.h
> index 167b7b81b0d0..a950b580cd11 100644
> --- a/include/drm/drm.h
> +++ b/include/drm/drm.h
> @@ -816,6 +816,7 @@ struct drm_event_vblank {
>   #define DRM_CAP_PRIME 0x5
>   #define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
>   #define DRM_CAP_ASYNC_PAGE_FLIP 0x7
> +#define DRM_CAP_ADDFB2_MODIFIERS	0x10
>
>   #define DRM_PRIME_CAP_IMPORT 0x1
>   #define DRM_PRIME_CAP_EXPORT 0x2
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index 85facb0a17cf..63a80ca5ba39 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -127,4 +127,97 @@
>   #define DRM_FORMAT_YUV444	fourcc_code('Y', 'U', '2', '4') /* non-subsampled Cb (1) and Cr (2) planes */
>   #define DRM_FORMAT_YVU444	fourcc_code('Y', 'V', '2', '4') /* non-subsampled Cr (1) and Cb (2) planes */
>
> +
> +/*
> + * Format Modifiers:
> + *
> + * Format modifiers describe, typically, a re-ordering or modification
> + * of the data in a plane of an FB.  This can be used to express tiled/
> + * swizzled formats, or compression, or a combination of the two.
> + *
> + * The upper 8 bits of the format modifier are a vendor-id as assigned
> + * below.  The lower 56 bits are assigned as vendor sees fit.
> + */
> +
> +/* Vendor Ids: */
> +#define DRM_FORMAT_MOD_NONE           0
> +#define DRM_FORMAT_MOD_VENDOR_INTEL   0x01
> +#define DRM_FORMAT_MOD_VENDOR_AMD     0x02
> +#define DRM_FORMAT_MOD_VENDOR_NV      0x03
> +#define DRM_FORMAT_MOD_VENDOR_SAMSUNG 0x04
> +#define DRM_FORMAT_MOD_VENDOR_QCOM    0x05
> +/* add more to the end as needed */
> +
> +#define fourcc_mod_code(vendor, val) \
> +	((((u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val & 0x00ffffffffffffffULL))
> +
> +/*
> + * Format Modifier tokens:
> + *
> + * When adding a new token please document the layout with a code comment,
> + * similar to the fourcc codes above. drm_fourcc.h is considered the
> + * authoritative source for all of these.
> + */
> +
> +/* Intel framebuffer modifiers */
> +
> +/*
> + * Intel X-tiling layout
> + *
> + * This is a tiled layout using 4Kb tiles (except on gen2 where the tiles 2Kb)
> + * in row-major layout. Within the tile bytes are laid out row-major, with
> + * a platform-dependent stride. On top of that the memory can apply
> + * platform-depending swizzling of some higher address bits into bit6.
> + *
> + * This format is highly platforms specific and not useful for cross-driver
> + * sharing. It exists since on a given platform it does uniquely identify the
> + * layout in a simple way for i915-specific userspace.
> + */
> +#define I915_FORMAT_MOD_X_TILED	fourcc_mod_code(INTEL, 1)
> +
> +/*
> + * Intel Y-tiling layout
> + *
> + * This is a tiled layout using 4Kb tiles (except on gen2 where the tiles 2Kb)
> + * in row-major layout. Within the tile bytes are laid out in OWORD (16 bytes)
> + * chunks column-major, with a platform-dependent height. On top of that the
> + * memory can apply platform-depending swizzling of some higher address bits
> + * into bit6.
> + *
> + * This format is highly platforms specific and not useful for cross-driver
> + * sharing. It exists since on a given platform it does uniquely identify the
> + * layout in a simple way for i915-specific userspace.
> + */
> +#define I915_FORMAT_MOD_Y_TILED	fourcc_mod_code(INTEL, 2)
> +
> +/*
> + * Intel Yf-tiling layout
> + *
> + * This is a tiled layout using 4Kb tiles in row-major layout.
> + * Within the tile pixels are laid out in 16 256 byte units / sub-tiles which
> + * are arranged in four groups (two wide, two high) with column-major layout.
> + * Each group therefore consits out of four 256 byte units, which are also laid
> + * out as 2x2 column-major.
> + * 256 byte units are made out of four 64 byte blocks of pixels, producing
> + * either a square block or a 2:1 unit.
> + * 64 byte blocks of pixels contain four pixel rows of 16 bytes, where the width
> + * in pixel depends on the pixel depth.
> + */
> +#define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
> +
> +/*
> + * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
> + *
> + * Macroblocks are laid in a Z-shape, and each pixel data is following the
> + * standard NV12 style.
> + * As for NV12, an image is the result of two frame buffers: one for Y,
> + * one for the interleaved Cb/Cr components (1/2 the height of the Y buffer).
> + * Alignment requirements are (for each buffer):
> + * - multiple of 128 pixels for the width
> + * - multiple of  32 pixels for the height
> + *
> + * For more information: see http://linuxtv.org/downloads/v4l-dvb-apis/re32.html
> + */
> +#define DRM_FORMAT_MOD_SAMSUNG_64_32_TILE	fourcc_mod_code(SAMSUNG, 1)
> +
>   #endif /* DRM_FOURCC_H */
> diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
> index 69c1ac3cf00c..115f36e452d9 100644
> --- a/include/drm/drm_mode.h
> +++ b/include/drm/drm_mode.h
> @@ -322,7 +322,8 @@ struct drm_mode_fb_cmd {
>   	__u32 handle;
>   };
>
> -#define DRM_MODE_FB_INTERLACED (1<<0) /* for interlaced framebuffers */
> +#define DRM_MODE_FB_INTERLACED	(1<<0) /* for interlaced framebuffers */
> +#define DRM_MODE_FB_MODIFIERS	(1<<1) /* enables ->modifer[] */
>
>   struct drm_mode_fb_cmd2 {
>   	__u32 fb_id;
> @@ -343,10 +344,18 @@ struct drm_mode_fb_cmd2 {
>   	 * So it would consist of Y as offset[0] and UV as
>   	 * offset[1].  Note that offset[0] will generally
>   	 * be 0.
> +	 *
> +	 * To accommodate tiled, compressed, etc formats, a per-plane
> +	 * modifier can be specified.  The default value of zero
> +	 * indicates "native" format as specified by the fourcc.
> +	 * Vendor specific modifier token.  This allows, for example,
> +	 * different tiling/swizzling pattern on different planes.
> +	 * See discussion above of DRM_FORMAT_MOD_xxx.
>   	 */
>   	__u32 handles[4];
>   	__u32 pitches[4]; /* pitch for each plane */
>   	__u32 offsets[4]; /* offset of each plane */
> +	__u64 modifier[4]; /* ie, tiling, compressed (per plane) */
>   };
>
>   #define DRM_MODE_FB_DIRTY_ANNOTATE_COPY 0x01
>

Patch
diff mbox

diff --git a/include/drm/drm.h b/include/drm/drm.h
index 167b7b81b0d0..a950b580cd11 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -816,6 +816,7 @@  struct drm_event_vblank {
 #define DRM_CAP_PRIME 0x5
 #define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
 #define DRM_CAP_ASYNC_PAGE_FLIP 0x7
+#define DRM_CAP_ADDFB2_MODIFIERS	0x10
 
 #define DRM_PRIME_CAP_IMPORT 0x1
 #define DRM_PRIME_CAP_EXPORT 0x2
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 85facb0a17cf..63a80ca5ba39 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -127,4 +127,97 @@ 
 #define DRM_FORMAT_YUV444	fourcc_code('Y', 'U', '2', '4') /* non-subsampled Cb (1) and Cr (2) planes */
 #define DRM_FORMAT_YVU444	fourcc_code('Y', 'V', '2', '4') /* non-subsampled Cr (1) and Cb (2) planes */
 
+
+/*
+ * Format Modifiers:
+ *
+ * Format modifiers describe, typically, a re-ordering or modification
+ * of the data in a plane of an FB.  This can be used to express tiled/
+ * swizzled formats, or compression, or a combination of the two.
+ *
+ * The upper 8 bits of the format modifier are a vendor-id as assigned
+ * below.  The lower 56 bits are assigned as vendor sees fit.
+ */
+
+/* Vendor Ids: */
+#define DRM_FORMAT_MOD_NONE           0
+#define DRM_FORMAT_MOD_VENDOR_INTEL   0x01
+#define DRM_FORMAT_MOD_VENDOR_AMD     0x02
+#define DRM_FORMAT_MOD_VENDOR_NV      0x03
+#define DRM_FORMAT_MOD_VENDOR_SAMSUNG 0x04
+#define DRM_FORMAT_MOD_VENDOR_QCOM    0x05
+/* add more to the end as needed */
+
+#define fourcc_mod_code(vendor, val) \
+	((((u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val & 0x00ffffffffffffffULL))
+
+/*
+ * Format Modifier tokens:
+ *
+ * When adding a new token please document the layout with a code comment,
+ * similar to the fourcc codes above. drm_fourcc.h is considered the
+ * authoritative source for all of these.
+ */
+
+/* Intel framebuffer modifiers */
+
+/*
+ * Intel X-tiling layout
+ *
+ * This is a tiled layout using 4Kb tiles (except on gen2 where the tiles 2Kb)
+ * in row-major layout. Within the tile bytes are laid out row-major, with
+ * a platform-dependent stride. On top of that the memory can apply
+ * platform-depending swizzling of some higher address bits into bit6.
+ *
+ * This format is highly platforms specific and not useful for cross-driver
+ * sharing. It exists since on a given platform it does uniquely identify the
+ * layout in a simple way for i915-specific userspace.
+ */
+#define I915_FORMAT_MOD_X_TILED	fourcc_mod_code(INTEL, 1)
+
+/*
+ * Intel Y-tiling layout
+ *
+ * This is a tiled layout using 4Kb tiles (except on gen2 where the tiles 2Kb)
+ * in row-major layout. Within the tile bytes are laid out in OWORD (16 bytes)
+ * chunks column-major, with a platform-dependent height. On top of that the
+ * memory can apply platform-depending swizzling of some higher address bits
+ * into bit6.
+ *
+ * This format is highly platforms specific and not useful for cross-driver
+ * sharing. It exists since on a given platform it does uniquely identify the
+ * layout in a simple way for i915-specific userspace.
+ */
+#define I915_FORMAT_MOD_Y_TILED	fourcc_mod_code(INTEL, 2)
+
+/*
+ * Intel Yf-tiling layout
+ *
+ * This is a tiled layout using 4Kb tiles in row-major layout.
+ * Within the tile pixels are laid out in 16 256 byte units / sub-tiles which
+ * are arranged in four groups (two wide, two high) with column-major layout.
+ * Each group therefore consits out of four 256 byte units, which are also laid
+ * out as 2x2 column-major.
+ * 256 byte units are made out of four 64 byte blocks of pixels, producing
+ * either a square block or a 2:1 unit.
+ * 64 byte blocks of pixels contain four pixel rows of 16 bytes, where the width
+ * in pixel depends on the pixel depth.
+ */
+#define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
+
+/*
+ * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
+ *
+ * Macroblocks are laid in a Z-shape, and each pixel data is following the
+ * standard NV12 style.
+ * As for NV12, an image is the result of two frame buffers: one for Y,
+ * one for the interleaved Cb/Cr components (1/2 the height of the Y buffer).
+ * Alignment requirements are (for each buffer):
+ * - multiple of 128 pixels for the width
+ * - multiple of  32 pixels for the height
+ *
+ * For more information: see http://linuxtv.org/downloads/v4l-dvb-apis/re32.html
+ */
+#define DRM_FORMAT_MOD_SAMSUNG_64_32_TILE	fourcc_mod_code(SAMSUNG, 1)
+
 #endif /* DRM_FOURCC_H */
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 69c1ac3cf00c..115f36e452d9 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -322,7 +322,8 @@  struct drm_mode_fb_cmd {
 	__u32 handle;
 };
 
-#define DRM_MODE_FB_INTERLACED (1<<0) /* for interlaced framebuffers */
+#define DRM_MODE_FB_INTERLACED	(1<<0) /* for interlaced framebuffers */
+#define DRM_MODE_FB_MODIFIERS	(1<<1) /* enables ->modifer[] */
 
 struct drm_mode_fb_cmd2 {
 	__u32 fb_id;
@@ -343,10 +344,18 @@  struct drm_mode_fb_cmd2 {
 	 * So it would consist of Y as offset[0] and UV as
 	 * offset[1].  Note that offset[0] will generally
 	 * be 0.
+	 *
+	 * To accommodate tiled, compressed, etc formats, a per-plane
+	 * modifier can be specified.  The default value of zero
+	 * indicates "native" format as specified by the fourcc.
+	 * Vendor specific modifier token.  This allows, for example,
+	 * different tiling/swizzling pattern on different planes.
+	 * See discussion above of DRM_FORMAT_MOD_xxx.
 	 */
 	__u32 handles[4];
 	__u32 pitches[4]; /* pitch for each plane */
 	__u32 offsets[4]; /* offset of each plane */
+	__u64 modifier[4]; /* ie, tiling, compressed (per plane) */
 };
 
 #define DRM_MODE_FB_DIRTY_ANNOTATE_COPY 0x01