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

From: zhoucm1 <david1.zhou-5C7GfCeVMHo@public.gmane.org>
To: "Christian König"
	<deathsimple-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>,
	"Marek Olšák" <maraeo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"Dave Airlie" <airlied-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: dri-devel
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	amd-gfx mailing list
	<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: Re: [PATCH libdrm] libdrm_amdgpu: add kernel semaphore support
Date: Tue, 18 Jul 2017 10:29:22 +0800	[thread overview]
Message-ID: <596D7282.2020502@amd.com> (raw)
In-Reply-To: <24c27ce4-34ec-41a0-b8af-b63d9fd89ee3-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>


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.

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