[PATCH] drm/ttm: Don't inherit GEM object VMAs in child process

Christian König 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:
>>> [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 
     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.


> Thanks,
>    Felix
>> Regards,
>> Christian.
>>> Regards,
>>>     Felix
>>>> Let's talk about this on Mondays call. Thanks for giving the whole
>>>> context.
>>>> Regards,
>>>> Christian.
>>>>> Regards,
>>>>>      Felix

More information about the amd-gfx mailing list