Re: [PATCH libdrm] libdrm_amdgpu: add kernel semaphore support

From: zhoucm1 <david1.zhou@amd.com>
To: "Christian König" <deathsimple@vodafone.de>,
	"Marek Olšák" <maraeo@gmail.com>,
	"Dave Airlie" <airlied@gmail.com>
Cc: amd-gfx mailing list <amd-gfx@lists.freedesktop.org>,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH libdrm] libdrm_amdgpu: add kernel semaphore support
Date: Wed, 19 Jul 2017 09:55:23 +0800	[thread overview]
Message-ID: <596EBC0B.5050905@amd.com> (raw)
In-Reply-To: <5f0903fc-b5dd-56bd-713c-e35a750e480d@vodafone.de>


On 2017年07月18日 21:57, Christian König wrote:
> Am 18.07.2017 um 04:29 schrieb zhoucm1:
>>
>>
>> On 2017年07月18日 01:35, Christian König wrote:
>>> Am 17.07.2017 um 19:22 schrieb Marek Olšák:
>>>> On Sun, Jul 16, 2017 at 11:36 PM, Dave Airlie <airlied@gmail.com> 
>>>> wrote:
>>>>>> I can take a look at it, I just won't have time until next week 
>>>>>> most likely.
>>>>> I've taken a look, and it's seemingly more complicated than I'm
>>>>> expecting I'd want to land in Mesa before 17.2 ships, I'd really
>>>>> prefer to just push the new libdrm_amdgpu api from this patch. If I
>>>>> have to port all the current radv code to the new API, I'll most
>>>>> definitely get something wrong.
>>>>>
>>>>> Adding the new API so far looks like
>>>>> https://cgit.freedesktop.org/~airlied/drm/log/?h=drm-amdgpu-cs-submit-raw 
>>>>>
>>>>>
>>>>> https://cgit.freedesktop.org/~airlied/drm/commit/?h=drm-amdgpu-cs-submit-raw&id=e7f85d0ca617fa41e72624780c9035df132e23c4 
>>>>>
>>>>> being the API, and whether it should take a uint32_t context id or
>>>>> context handle left as an open question in the last patch in the
>>>>> series.
>>>>>
>>>>> However to hook this into radv or radeonsi will take a bit of
>>>>> rewriting of a lot of code that is probably a bit more fragile than
>>>>> I'd like for this sort of surgery at this point.
>>>>>
>>>>> I'd actually suspect if we do want to proceed with this type of
>>>>> interface, we might be better doing it all in common mesa code, and
>>>>> maybe bypassing libdrm_amdgpu altogether, which I suppose the API 
>>>>> I've
>>>>> written here is mostly already doing.
>>>> Well, we plan to stop using the BO list ioctl. The interface has
>>>> bo_list_handle in it. Will we just set it to 0 when add the chunk for
>>>> the inlined buffer list i.e. what radeon has?
>>>
>>> Yeah, exactly that was my thinking as well.
>> Just one thought, Could we remove and not use bo list at all? 
>> Instead, we expose api like amdgpu_bo_make_resident with proper 
>> privilege to user mode? That way, we will obviously short CS ioctl.
>
> Not really, but I'm working on per process resources now. E.g. you 
> specify a flag that a resource is always bound to the process and 
> always used instead of specifying it every time.
>
> The tricky part is that you then can't export that resource to other 
> processes, so it only works for buffers/textures which aren't 
> exchanged with anybody.
Yeah, Making bo resident obviously doesn't work for imported/foreign 
BOs, but imported BOs are always pinned when exported to others, aren't 
they?
Combining your per process resources, we can have a try, I think.

Regards,
David Zhou
>
> Regards,
> Christian.
>
>>
>> David Zhou
>>>
>>> Christian.
>>>
>>>> Marek
>>>
>>>
>>> _______________________________________________
>>> amd-gfx mailing list
>>> amd-gfx@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
>

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