On Fri, Jan 30, 2015 at 05:08:23PM +0100, Daniel Vetter wrote:
> From: Rob Clark <robdclark@xxxxxxxxx>
>
> In DRM/KMS we are lacking a good way to deal with tiled/compressed
> formats. Especially in the case of dmabuf/prime buffer sharing, where
> we cannot always rely on under-the-hood flags passed to driver specific
> gem-create ioctl to pass around these extra flags.
>
> The proposal is to add a per-plane format modifier. This allows to, if
> necessary, use different tiling patters for sub-sampled planes, etc.
"patterns". Alternatively perhaps "modes", which is how I've heard it
referred to most commonly.
> The format modifiers are added at the end of the ioctl struct, so for
> legacy userspace it will be zero padded.
>
> v1: original
> v1.5: increase modifier to 64b
>
> v2: Incorporate review comments from the big thread, plus a few more.
>
> - Add a getcap so that userspace doesn't have to jump through hoops.
> - Allow modifiers only when a flag is set. That way drivers know when
> they're dealing with old userspace and need to fish out e.g. tiling
> from other information.
> - After rolling out checks for ->modifier to all drivers I've decided
> that this is way too fragile and needs an explicit opt-in flag. So
> do that instead.
> - Add a define (just for documentation really) for the "NONE"
> modifier. Imo we don't need to add mask #defines since drivers
> really should only do exact matches against values defined with
> fourcc_mod_code.
> - Drop the Samsung tiling modifier on Rob's request since he's not yet
> sure whether that one is accurate.
>
> v3:
> - Also add a new ->modifier[] array to struct drm_framebuffer and fill
> it in drm_helper_mode_fill_fb_struct. Requested by Tvrtko Uruslin.
> - Remove TODO in comment and add code comment that modifiers should be
> properly documented, requested by Rob.
>
> v4: Balance parens, spotted by Tvrtko.
>
> Cc: Rob Clark <robdclark@xxxxxxxxx>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxxxxx>
> Cc: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>
> Cc: Daniel Stone <daniel@xxxxxxxxxxxxx>
> Cc: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> Cc: Michel Dänzer <michel@xxxxxxxxxxx>
> Signed-off-by: Rob Clark <robdclark@xxxxxxxxx> (v1.5)
> Reviewed-by: Rob Clark <robdclark@xxxxxxxxx>
> Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx>
> ---
> drivers/gpu/drm/drm_crtc.c | 14 +++++++++++++-
> drivers/gpu/drm/drm_crtc_helper.c | 1 +
> drivers/gpu/drm/drm_ioctl.c | 3 +++
> include/drm/drm_crtc.h | 4 ++++
> include/uapi/drm/drm.h | 1 +
> include/uapi/drm/drm_fourcc.h | 32 ++++++++++++++++++++++++++++++++
> include/uapi/drm/drm_mode.h | 9 +++++++++
> 7 files changed, 63 insertions(+), 1 deletion(-)
Also as discussed on IRC, I think this would be better in a non-DRM
specific header so that we can have a central, cross-subsystem
authority.
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 646ae5f39f42..622109677747 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -132,4 +132,36 @@
> #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 */
>
> +
Possibly unintented extra blank line?
> +/*
> + * 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
I think this should be NVIDIA for consistency with other naming in the
kernel, at least on Tegra.
Otherwise:
Reviewed-by: Thierry Reding <treding@xxxxxxxxxx>
Attachment:
pgp0D1KaTBLjl.pgp
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
