[PATCH libdrm] libdrm_amdgpu: add kernel semaphore support

[Michel Dänzer]

On 18/07/17 09:55 PM, zhoucm1 wrote:
> 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 at 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?

Only while being shared between different GPUs, not between different 
processes on the same GPU (e.g. DRI3). We'll still need to use some kind 
of BO list for that case.


-- 
Earthling Michel Dänzer            |                  http://www.amd.com
Libre software enthusiast          |                Mesa and X developer