From: "Christian König" <christian.koenig@amd.com>
To: "Felix Kuehling" <felix.kuehling@amd.com>,
"Christian König" <ckoenig.leichtzumerken@gmail.com>,
"Daniel Vetter" <daniel@ffwll.ch>,
"Bhardwaj, Rajneesh" <rajneesh.bhardwaj@amd.com>,
"Adrian Reber" <adrian@lisas.de>
Cc: daniel.vetter@ffwll.ch, amd-gfx@lists.freedesktop.org,
David Yat Sin <david.yatsin@amd.com>,
dri-devel@lists.freedesktop.org, alexander.deucher@amd.com,
airlied@redhat.com
Subject: Re: [PATCH] drm/ttm: Don't inherit GEM object VMAs in child process
Date: Fri, 7 Jan 2022 09:56:47 +0100 [thread overview]
Message-ID: <386142cc-1df5-228c-af24-2187998d9307@amd.com> (raw)
In-Reply-To: <af705589-a601-9774-ec55-d1c244f756a9@amd.com>
Am 06.01.22 um 17:51 schrieb Felix Kuehling:
> Am 2022-01-06 um 11:48 a.m. schrieb Christian König:
>> Am 06.01.22 um 17:45 schrieb Felix Kuehling:
>>> Am 2022-01-06 um 4:05 a.m. schrieb Christian König:
>>> [SNIP]
>>> Also, why does your ACK or NAK depend on this at all. If it's the right
>>> thing to do, it's the right thing to do regardless of who benefits from
>>> it. In addition, how can a child process that doesn't even use the GPU
>>> be in violation of any GPU-driver related specifications.
>> The argument is that the application is broken and needs to be fixed
>> instead of worked around inside the kernel.
> I still don't get how they the application is broken. Like I said, the
> child process is not using the GPU. How can the application be fixed in
> this case?
Sounds like I'm still missing some important puzzle pieces for the full
picture to figure out why this doesn't work.
> Are you saying, any application that forks and doesn't immediately call
> exec is broken?
More or less yes. We essentially have three possible cases here:
1. Application is already using (for example) OpenGL or OpenCL to do
some rendering on the GPU and then calls fork() and expects to use
OpenGL both in the parent and the child at the same time.
As far as I know that's illegal from the Khronos specification
point of view and working around inside the kernel for something not
allowed in the first place is seen as futile effort.
2. Application opened the file descriptor, forks and then initializes
OpenGL/Vulkan/OpenCL.
That's what some compositors are doing to drop into the backround
and is explicitly legal.
3. Application calls fork() and then doesn't use the GPU in the child.
Either by not using it or calling exec.
That should be legal and not cause any problems in the first place.
But from your description I still don't get why we are running into
problems here.
I was assuming that you have case #1 because we previously had some
examples of this with this python library, but from your description it
seems to be case #3.
> Or does an application that forks need to be aware that some other part
> of the application used the GPU and explicitly free any GPU resources?
Others might fill that information in, but I think that was the plan for
newer APIs like Vulkan.
Regards,
Christian.
>
> Thanks,
> Felix
>
>
>> Regards,
>> Christian.
>>
>>> Regards,
>>> Felix
>>>
>>>
>>>> Let's talk about this on Mondays call. Thanks for giving the whole
>>>> context.
>>>>
>>>> Regards,
>>>> Christian.
>>>>
>>>>> Regards,
>>>>> Felix
>>>>>
next prev parent reply other threads:[~2022-01-07 8:57 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-08 20:53 [PATCH] drm/ttm: Don't inherit GEM object VMAs in child process Rajneesh Bhardwaj
2021-12-09 7:54 ` Christian König
2021-12-09 15:23 ` Bhardwaj, Rajneesh
2021-12-09 15:27 ` Christian König
2021-12-09 15:29 ` Bhardwaj, Rajneesh
2021-12-09 15:30 ` Christian König
2021-12-09 18:28 ` Felix Kuehling
2021-12-10 6:58 ` Christian König
2021-12-20 9:29 ` Daniel Vetter
2021-12-20 18:12 ` Bhardwaj, Rajneesh
2021-12-22 20:53 ` Daniel Vetter
2021-12-23 1:49 ` Bhardwaj, Rajneesh
2021-12-23 1:51 ` Bhardwaj, Rajneesh
2021-12-23 7:05 ` Christian König
2022-01-04 18:08 ` Felix Kuehling
2022-01-05 8:08 ` Christian König
2022-01-05 16:16 ` Felix Kuehling
2022-01-05 16:27 ` Felix Kuehling
2022-01-06 9:05 ` Christian König
2022-01-06 16:45 ` Felix Kuehling
2022-01-06 16:48 ` Christian König
2022-01-06 16:51 ` Felix Kuehling
2022-01-07 8:56 ` Christian König [this message]
2022-01-07 17:47 ` Felix Kuehling
2022-01-14 16:44 ` Daniel Vetter
2022-01-14 17:26 ` Christian König
2022-01-14 17:40 ` Felix Kuehling
2022-01-17 11:44 ` Christian König
2022-01-17 14:17 ` Felix Kuehling
2022-01-17 14:21 ` Christian König
2022-01-17 14:34 ` Felix Kuehling
2022-01-17 14:50 ` Marek Olšák
2022-01-17 16:23 ` Christian König
2022-01-10 17:30 ` Bhardwaj, Rajneesh
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=386142cc-1df5-228c-af24-2187998d9307@amd.com \
--to=christian.koenig@amd.com \
--cc=adrian@lisas.de \
--cc=airlied@redhat.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel@ffwll.ch \
--cc=david.yatsin@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=felix.kuehling@amd.com \
--cc=rajneesh.bhardwaj@amd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).