From: Eric Anholt <eric@anholt.net>
To: Daniel Stone <daniel@fooishbar.org>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
Dave Stevenson <dave.stevenson@raspberrypi.org>,
Boris Brezillon <boris.brezillon@bootlin.com>,
Maxime Ripard <maxime.ripard@bootlin.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Daniel Stone <daniels@collabora.com>
Subject: Re: [PATCH] drm/vc4: Add support for SAND modifier.
Date: Fri, 16 Mar 2018 15:05:59 -0700 [thread overview]
Message-ID: <87a7v7ad6g.fsf@anholt.net> (raw)
In-Reply-To: <CAPj87rNtcN0PDFViJB_NOVzUeLSWKe9smnQx7RSXwBR1+nm__w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1453 bytes --]
Daniel Stone <daniel@fooishbar.org> writes:
> Hey Eric,
>
> On 3 March 2018 at 01:34, Eric Anholt <eric@anholt.net> wrote:
>> Ccing a couple of folks who are likely to have opinions about
>> drm_fourcc.h additions (Do we have enough docs? Are the macros OK?),
>> and Bootlin who are likely reviewers.
>>
>> The plan is to use these modifiers in VC4 GL imports as well, and for
>> buffers coming from the v4l2 mmal camera driver. You can find a demo
>> using this in KMS planes at
>> https://github.com/anholt/drm_mmal/commit/sand for now.
>
> I had a dig through and this seems like the most sensible thing to do
> if you have a reasonable variety of tile heights. If you only see a
> couple of combinations in the wild, then hardcoding them as separate
> modifiers might make things easier than hiving off 24 bits. If you do
> keep the split though, and especially if you're envisioning future
> flexible tile formats, maybe something like an 8 code / 48 params
> split would make more sense.
>
> Either way, those are just my opinions (you did ask), and I don't see
> anything really objectionable, so if you think that's a good split
> then this is:
> Acked-by: Daniel Stone <daniels@collabora.com>
I had been thinking of potentially specifying a meaning for the other 24
bits (separate U/V plane v stride if set, if we ever get a component
that needs to do that), so I went ahead and did this, along with a
couple of fixes due to Ville's patch.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
prev parent reply other threads:[~2018-03-16 22:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-03 1:34 [PATCH] drm/vc4: Add support for SAND modifier Eric Anholt
2018-03-03 1:34 ` Eric Anholt
2018-03-14 11:08 ` Daniel Stone
2018-03-14 11:08 ` Daniel Stone
2018-03-16 22:05 ` Eric Anholt [this message]
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=87a7v7ad6g.fsf@anholt.net \
--to=eric@anholt.net \
--cc=boris.brezillon@bootlin.com \
--cc=daniel@fooishbar.org \
--cc=daniels@collabora.com \
--cc=dave.stevenson@raspberrypi.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maxime.ripard@bootlin.com \
/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.