From: Nicolas Dufresne <nicolas@ndufresne.ca>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Brian Starkey <brian.starkey@arm.com>
Cc: Hans Verkuil <hverkuil@xs4all.nl>,
Daniel Vetter <daniel@ffwll.ch>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
jonathan.chai@arm.com,
dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: DRM Format Modifiers in v4l2
Date: Thu, 31 Aug 2017 12:12:58 -0400 [thread overview]
Message-ID: <1504195978.18413.14.camel@ndufresne.ca> (raw)
In-Reply-To: <4559442.sz5HF0f0o4@avalon>
[-- Attachment #1: Type: text/plain, Size: 868 bytes --]
Le jeudi 31 août 2017 à 17:28 +0300, Laurent Pinchart a écrit :
> > e.g. if I have two devices which support MODIFIER_FOO, I could attempt
> > to share a buffer between them which uses MODIFIER_FOO without
> > necessarily knowing exactly what it is/does.
>
> Userspace could certainly set modifiers blindly, but the point of modifiers is
> to generate side effects benefitial to the use case at hand (for instance by
> optimizing the memory access pattern). To use them meaningfully userspace
> would need to have at least an idea of the side effects they generate.
Generic userspace will basically pick some random combination. To allow
generically picking the optimal configuration we could indeed rely on
the application knowledge, but we could also enhance the spec so that
the order in the enumeration becomes meaningful.
regards,
Nicolas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
next prev parent reply other threads:[~2017-08-31 16:13 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-21 15:52 DRM Format Modifiers in v4l2 Brian Starkey
2017-08-21 16:01 ` Daniel Vetter
2017-08-21 16:21 ` Brian Starkey
2017-08-21 16:36 ` Hans Verkuil
2017-08-24 11:14 ` Brian Starkey
2017-08-24 11:37 ` Hans Verkuil
2017-08-24 12:26 ` Brian Starkey
2017-08-25 8:14 ` Hans Verkuil
2017-08-29 9:19 ` Brian Starkey
2017-08-31 14:36 ` Laurent Pinchart
2017-08-28 18:07 ` Nicolas Dufresne
2017-08-28 20:49 ` Daniel Vetter
2017-08-29 9:47 ` Brian Starkey
2017-08-30 7:50 ` Daniel Vetter
2017-08-30 8:10 ` Hans Verkuil
2017-08-30 9:36 ` Brian Starkey
2017-08-30 9:53 ` Hans Verkuil
2017-08-30 10:32 ` Brian Starkey
2017-08-31 14:51 ` Laurent Pinchart
2017-08-31 15:23 ` Brian Starkey
2017-08-31 14:28 ` Laurent Pinchart
2017-08-31 16:12 ` Nicolas Dufresne [this message]
2017-09-01 7:13 ` Laurent Pinchart
2017-09-01 12:43 ` Rob Clark
2017-09-03 9:00 ` Daniel Vetter
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=1504195978.18413.14.camel@ndufresne.ca \
--to=nicolas@ndufresne.ca \
--cc=brian.starkey@arm.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=hverkuil@xs4all.nl \
--cc=jonathan.chai@arm.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox