From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: "Daniel Vetter" <daniel.vetter@ffwll.ch>,
"Intel Graphics Development" <intel-gfx@lists.freedesktop.org>,
"Daniel Stone" <daniel@fooishbar.org>,
"DRI Development" <dri-devel@lists.freedesktop.org>,
"Daniel Vetter" <daniel.vetter@intel.com>,
"Michel Dänzer" <michel@daenzer.net>,
"Laurent Pinchart" <laurent.pinchart@ideasonboard.com>
Subject: Re: [PATCH] RFC: drm: add support for tiled/compressed/etc modifier in addfb2 (v1.5)
Date: Thu, 29 Jan 2015 11:43:07 +0000 [thread overview]
Message-ID: <54CA1CCB.30500@linux.intel.com> (raw)
In-Reply-To: <20150129113029.GA4764@phenom.ffwll.local>
On 01/29/2015 11:30 AM, Daniel Vetter wrote:
> On Wed, Jan 28, 2015 at 05:57:56PM +0000, Tvrtko Ursulin wrote:
>>
>> On 01/28/2015 05:37 PM, Daniel Vetter wrote:
>>> From: Rob Clark <robdclark@gmail.com>
>>>
>>> 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.
>>> The format modifiers are added at the end of the ioctl struct, so for
>>> legacy userspace it will be zero padded.
>>>
>>> TODO how best to deal with assignment of modifier token values? The
>>> rough idea was to namespace things with an 8bit vendor-id, and then
>>> beyond that it is treated as an opaque value. But that was a relatively
>>> arbitrary choice. There are cases where same tiling pattern and/or
>>> compression is supported by various different vendors. So we should
>>> standardize to use the vendor-id and value of the first one who
>>> documents the format?
>>
>> Maybe:
>> __u64 modifier[4];
>> __u64 vendor_modifier[4];
>
> Seems rendundant since the modifier added in this patch is already vendor
> specific. Or what exactly are you trying to accomplish here?
I am trying to avoid packet-in-a-packet (bitmasks) mumbo-jumbo and
vendor id on the head followed by maybe standardized or maybe vendor
specific tag. Feels funny. Would it not be simpler to put a struct in there?
But I was not following this from the start so maybe I am missing
something..
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-01-29 11:43 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-28 17:37 [PATCH] RFC: drm: add support for tiled/compressed/etc modifier in addfb2 (v1.5) Daniel Vetter
2015-01-28 17:57 ` Tvrtko Ursulin
2015-01-29 11:30 ` Daniel Vetter
2015-01-29 11:43 ` Tvrtko Ursulin [this message]
2015-01-29 11:57 ` Daniel Vetter
2015-01-29 12:55 ` Tvrtko Ursulin
2015-01-29 13:27 ` Daniel Vetter
2015-01-29 15:09 ` Rob Clark
2015-01-28 18:46 ` Rob Clark
2015-01-29 11:29 ` Daniel Vetter
2015-01-29 17:01 ` [PATCH] RFC: drm: add support for tiled/compressed/etc modifier in addfb2 Daniel Vetter
2015-01-30 10:51 ` Tvrtko Ursulin
2015-01-30 13:43 ` Rob Clark
2015-01-30 14:35 ` Tvrtko Ursulin
2015-01-30 14:51 ` Rob Clark
2015-01-30 15:42 ` Daniel Vetter
2015-01-30 15:19 ` Tvrtko Ursulin
2015-01-30 16:08 ` Daniel Vetter
2015-02-01 20:14 ` shuang.he
2015-02-03 15:36 ` Thierry Reding
2015-03-11 6:40 ` [Intel-gfx] " Dave Airlie
2015-02-01 1:48 ` shuang.he
2015-02-02 23:14 ` [PATCH] RFC: drm: add support for tiled/compressed/etc modifier in addfb2 (v1.5) shuang.he
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54CA1CCB.30500@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=daniel@ffwll.ch \
--cc=daniel@fooishbar.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=michel@daenzer.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.