[PATCH] drm/ttm: Don't inherit GEM object VMAs in child process
christian.koenig at amd.com
Fri Jan 7 08:56:47 UTC 2022
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:
>>> 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
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
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.
>>>> Let's talk about this on Mondays call. Thanks for giving the whole
More information about the amd-gfx