[Mesa-dev] [PATCH v5 03/12] gallium: add common pipe_screen reference counting functions
Marek Olšák
maraeo at gmail.com
Wed Aug 9 20:12:12 UTC 2017
OK. This patch is:
Reviewed-by: Marek Olšák <marek.olsak at amd.com>
Marek
On Wed, Aug 9, 2017 at 9:53 PM, Rob Herring <robh at kernel.org> wrote:
> On Wed, Aug 9, 2017 at 2:18 PM, Marek Olšák <maraeo at gmail.com> wrote:
>> Hi Rob,
>>
>> This is not enough to do screen reference counting. There are primary
>> FDs and render node FDs, and we want to have only one pipe_screen for
>> all kinds of FDs pointing to the same device.
>>
>> Imagine someone creates a pipe_screen with a render node FD, and then
>> creates another pipe_screen with a primary FD. We want to return the
>> same pipe_screen instance in both cases.
>>
>> The pipe_screen should use the render node FD for everything if it was
>> created first with that FD. However, it also needs to keep the primary
>> FD in order to be able to do GEM_FLINK when required.
>>
>> libdrm_amdgpu handles all those cases correctly. It has "fd", which is
>> the main one, but also has "flink_fd" for GEM_FLINK. If "fd" is a
>> primary FD or there is no primary FD, "fd == flink_fd". If "fd" is a
>> render node and a primary FD has also been used to create the device
>> object, "fd" is the render node and "flink_fd" is the primary FD for
>> GEM_FLINK.
>>
>> The code:
>> https://cgit.freedesktop.org/mesa/drm/tree/amdgpu/amdgpu_device.c
>>
>> I can't accept this patch, because it effectively disables that
>> amdgpu_device code.
>
> This patch alone doesn't change any driver. I think you mean patch #8
> which converts amdgpu and which could be dropped (though I'd like to
> keep the radeon winsys parts). However, I believe I've maintained the
> behavior for amdgpu.
>
> The amdgpu winsys does not use the fd in these functions (the screen
> fd will be -1). The only change should be that the mutex is removed
> and the pipe_reference is moved from ws->reference to
> ws->base.screen->reference. It's still using the device in the hash
> table.
>
> Rob
More information about the mesa-dev
mailing list