Re: [PATCH] procfs/dmabuf: Add /proc/<pid>/task/<tid>/dmabuf_fds

From: Pekka Paalanen <ppaalanen@gmail.com>
To: "Christian König" <christian.koenig@amd.com>
Cc: Michal Hocko <mhocko@suse.com>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	Szabolcs Nagy <szabolcs.nagy@arm.com>,
	dri-devel@lists.freedesktop.org, Andrei Vagin <avagin@gmail.com>,
	Kalesh Singh <kaleshsingh@google.com>, Hui Su <sh_def@163.com>,
	Michel Lespinasse <walken@google.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
	Jeffrey Vander Stoep <jeffv@google.com>,
	Daniel Jordan <daniel.m.jordan@oracle.com>,
	kernel-team <kernel-team@android.com>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	Kees Cook <keescook@chromium.org>, Jann Horn <jannh@google.com>,
	linaro-mm-sig@lists.linaro.org,
	Hridya Valsaraju <hridya@google.com>,
	Bernd Edlinger <bernd.edlinger@hotmail.de>,
	Suren Baghdasaryan <surenb@google.com>,
	Alexey Gladkov <gladkov.alexey@gmail.com>,
	kernel list <linux-kernel@vger.kernel.org>,
	Minchan Kim <minchan@kernel.org>,
	Yafang Shao <laoar.shao@gmail.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux API <linux-api@vger.kernel.org>
Subject: Re: [PATCH] procfs/dmabuf: Add /proc/<pid>/task/<tid>/dmabuf_fds
Date: Fri, 29 Jan 2021 16:13:34 +0200	[thread overview]
Message-ID: <20210129161334.788b8fd0@eldfell> (raw)
In-Reply-To: <c95af15d-8ff4-aea0-fa1b-3157845deae1@amd.com>

[-- Attachment #1.1: Type: text/plain, Size: 3017 bytes --]

On Fri, 29 Jan 2021 13:18:01 +0100
Christian König <christian.koenig@amd.com> wrote:

> Am 28.01.21 um 11:01 schrieb Pekka Paalanen:
> > On Wed, 27 Jan 2021 12:01:55 +0100
> > Christian König <christian.koenig@amd.com> wrote:
> >  
> >> Somewhat correct. This interface here really doesn't make sense since
> >> the file descriptor representation of DMA-buf is only meant to be used
> >> for short term usage.
> >>
> >> E.g. the idea is that you can export a DMA-buf fd from your device
> >> driver, transfer that to another process and then import it again into a
> >> device driver.
> >>
> >> Keeping a long term reference to a DMA-buf fd sounds like a design bug
> >> in userspace to me.  
> > Except keeping the fd is exactly what userspace must do if it wishes to
> > re-use the buffer without passing a new fd over IPC again. Particularly
> > Wayland compositors need to keep the client buffer dmabuf fd open after
> > receiving it, so that they can re-import it to EGL to ensure updated
> > contents are correctly flushed as EGL has no other API for it.  
> 
> Hui what??? I'm not that deep into the EGL specification, but from the 
> kernel side that is utterly nonsense.
> 
> Could be that re-importing triggers something in userspace, but this 
> sounds strongly like a workaround to me which shouldn't be necessary.

Hi,

there was a pretty long discussion about exactly this on #dri-devel
today, starting at 12:30:
https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=dri-devel&highlight_names=&date=2021-01-29

The conclusion is that indeed, it is no longer necessary to re-import
to EGL all the time. It should be enough (at least with all Mesa
drivers) to call glEGLImageTargetTexture2DOES() every time you want to
ensure you get the updated buffer contents.

So now people across various projects are thinking how to keep the
EGLImage and not re-import on every update.

> > That is my vague understanding, and what Weston implements. You can say
> > it's a bad userspace API design in EGL, but what else can we do?  
> 
> Please open up a bug report with your EGL driver if that is really 
> necessary.

Sure, I would hope there is no such case anymore.

> DMA-bufs shared using a file descriptor should be coherent when 
> written/read from a GPU or other hardware device. What is possible is 
> that you need to do something special for CPU access.
> 
> In other words once a DMA-buf is imported and available as 
> handle/texture/image inside EGL it doesn't needs to be flushed/synced 
> explicitly again.

There is still the case where the some GL drivers sometimes need
to make a copy when turning the dmabuf into a GL texture[IRC log]. But
indeed, that seems to be not EGL's concern.

> 
> Re-importing it adds quite a huge CPU overhead to both userspace as well 
> as the kernel.

Perhaps, but so far it seems no-one has noticed the overhead, with Mesa
at least.

I happily stand corrected.

Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel