From: Simon Ser <contact@emersion.fr>
To: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Ezequiel Garcia <ezequiel@collabora.com>,
Robert Beckett <bob.beckett@collabora.com>,
"kernel@collabora.com" <kernel@collabora.com>,
Benjamin Gaignard <benjamin.gaignard@st.com>,
James Jones <jajones@nvidia.com>,
dri-devel <dri-devel@lists.freedesktop.org>,
"Andrew F . Davis" <afd@ti.com>, Liam Mark <lmark@codeaurora.org>,
Laura Abbott <labbott@kernel.org>,
Daniel Stone <daniels@collabora.com>,
Tomasz Figa <tfiga@chromium.org>,
linux-media <linux-media@vger.kernel.org>
Subject: Re: [RFC] Experimental DMA-BUF Device Heaps
Date: Thu, 27 Aug 2020 10:05:31 +0000 [thread overview]
Message-ID: <HLs4Vl86o7Bizqo_-jyz_sHLhvnePm1DoLc9c_96NjYt-GeGwjX1NLz_lScgmmDBMvulyYsgzqiIXhs9yhYxsbompEotRDwtz9uNDAp7ZWs=@emersion.fr> (raw)
In-Reply-To: <a1663f6e74eca50f19b44416cdeb346a7b836108.camel@collabora.com>
On Tuesday, August 25, 2020 10:26 PM, Nicolas Dufresne <nicolas.dufresne@collabora.com> wrote:
> > I don't think we can do this in a system-agnostic way. What I'd like to
> > see is an API for the kernel to expose opaque constraints for each
>
> Please, take into consideration that constraints can also come from
> userspace. These days, there exist things we may want to do using the
> CPU, but the SIMD instructions and the associated algorithm will
> introduce constraints too. If these constraints comes too opaque, but
> you will also potentially limit some valid CPU interaction with HW in
> term of buffer access. CPU constraints todays are fairly small and one
> should be able to express them I believe. Of course, these are not
> media agnostic, some constraints may depends on the media (like an
> image buffer, a matrix buffer or audio buffer) and the associated
> algorithm to be used.
>
> An example would be an image buffers produced or modified on CPU but
> encoded with HW.
Actually, in the proposal we're working on, constraints may come from
user-space too. Rendering APIs (ie. mesa) will need to expose
constraints for buffers they can render on or texture from.
Constraints would be opaque for users like compositors (ie. programs
that merely pass constraints around and merge them don't need to
understand them), but not for user-space drivers.
WARNING: multiple messages have this Message-ID (diff)
From: Simon Ser <contact@emersion.fr>
To: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Cc: Robert Beckett <bob.beckett@collabora.com>,
Tomasz Figa <tfiga@chromium.org>,
Benjamin Gaignard <benjamin.gaignard@st.com>,
James Jones <jajones@nvidia.com>,
linux-media <linux-media@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
"Andrew F . Davis" <afd@ti.com>, Liam Mark <lmark@codeaurora.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Daniel Stone <daniels@collabora.com>,
"kernel@collabora.com" <kernel@collabora.com>,
Ezequiel Garcia <ezequiel@collabora.com>,
Laura Abbott <labbott@kernel.org>
Subject: Re: [RFC] Experimental DMA-BUF Device Heaps
Date: Thu, 27 Aug 2020 10:05:31 +0000 [thread overview]
Message-ID: <HLs4Vl86o7Bizqo_-jyz_sHLhvnePm1DoLc9c_96NjYt-GeGwjX1NLz_lScgmmDBMvulyYsgzqiIXhs9yhYxsbompEotRDwtz9uNDAp7ZWs=@emersion.fr> (raw)
In-Reply-To: <a1663f6e74eca50f19b44416cdeb346a7b836108.camel@collabora.com>
On Tuesday, August 25, 2020 10:26 PM, Nicolas Dufresne <nicolas.dufresne@collabora.com> wrote:
> > I don't think we can do this in a system-agnostic way. What I'd like to
> > see is an API for the kernel to expose opaque constraints for each
>
> Please, take into consideration that constraints can also come from
> userspace. These days, there exist things we may want to do using the
> CPU, but the SIMD instructions and the associated algorithm will
> introduce constraints too. If these constraints comes too opaque, but
> you will also potentially limit some valid CPU interaction with HW in
> term of buffer access. CPU constraints todays are fairly small and one
> should be able to express them I believe. Of course, these are not
> media agnostic, some constraints may depends on the media (like an
> image buffer, a matrix buffer or audio buffer) and the associated
> algorithm to be used.
>
> An example would be an image buffers produced or modified on CPU but
> encoded with HW.
Actually, in the proposal we're working on, constraints may come from
user-space too. Rendering APIs (ie. mesa) will need to expose
constraints for buffers they can render on or texture from.
Constraints would be opaque for users like compositors (ie. programs
that merely pass constraints around and merge them don't need to
understand them), but not for user-space drivers.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-08-27 10:05 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-16 17:22 [RFC] Experimental DMA-BUF Device Heaps Ezequiel Garcia
2020-08-16 17:22 ` Ezequiel Garcia
2020-08-17 15:18 ` Brian Starkey
2020-08-17 15:18 ` Brian Starkey
2020-08-18 3:49 ` James Jones
2020-08-18 3:49 ` James Jones
2020-08-20 8:15 ` Ezequiel Garcia
2020-08-20 8:15 ` Ezequiel Garcia
2020-08-23 20:04 ` James Jones
2020-08-23 20:04 ` James Jones
2020-08-23 20:46 ` Laurent Pinchart
2020-08-23 20:46 ` Laurent Pinchart
2020-08-23 22:53 ` James Jones
2020-08-23 22:53 ` James Jones
2020-08-31 15:08 ` Laurent Pinchart
2020-08-31 15:08 ` Laurent Pinchart
2020-08-27 14:52 ` Simon Ser
2020-08-27 14:52 ` Simon Ser
2020-08-31 3:04 ` DMA-BUF Heaps BoF notes (Re: [RFC] Experimental DMA-BUF Device Heaps) Ezequiel Garcia
2020-08-31 3:04 ` Ezequiel Garcia
2020-08-20 8:07 ` [RFC] Experimental DMA-BUF Device Heaps Ezequiel Garcia
2020-08-20 8:07 ` Ezequiel Garcia
2020-08-20 9:14 ` Brian Starkey
2020-08-20 9:14 ` Brian Starkey
2020-08-18 4:13 ` John Stultz
2020-08-18 4:13 ` John Stultz
2020-08-20 8:36 ` Ezequiel Garcia
2020-08-20 8:36 ` Ezequiel Garcia
2020-08-20 15:54 ` Laurent Pinchart
2020-08-20 15:54 ` Laurent Pinchart
2020-08-25 20:26 ` Nicolas Dufresne
2020-08-25 20:26 ` Nicolas Dufresne
2020-08-27 10:05 ` Simon Ser [this message]
2020-08-27 10:05 ` Simon Ser
2020-09-01 7:32 ` Daniel Vetter
2020-09-01 7:32 ` Daniel Vetter
2020-09-08 5:43 ` Laurent Pinchart
2020-09-08 5:43 ` Laurent Pinchart
2020-09-08 8:36 ` Daniel Vetter
2020-09-08 8:36 ` Daniel Vetter
2020-09-16 17:01 ` Daniel Vetter
2020-09-16 17:01 ` 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='HLs4Vl86o7Bizqo_-jyz_sHLhvnePm1DoLc9c_96NjYt-GeGwjX1NLz_lScgmmDBMvulyYsgzqiIXhs9yhYxsbompEotRDwtz9uNDAp7ZWs=@emersion.fr' \
--to=contact@emersion.fr \
--cc=afd@ti.com \
--cc=benjamin.gaignard@st.com \
--cc=bob.beckett@collabora.com \
--cc=daniels@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=ezequiel@collabora.com \
--cc=jajones@nvidia.com \
--cc=kernel@collabora.com \
--cc=labbott@kernel.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=lmark@codeaurora.org \
--cc=nicolas.dufresne@collabora.com \
--cc=tfiga@chromium.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 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.