[PATCH libdrm] libdrm_amdgpu: add kernel semaphore support
Christian König
deathsimple at vodafone.de
Tue Jul 18 13:57:34 UTC 2017
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.
Regards,
Christian.
>
> David Zhou
>>
>> Christian.
>>
>>> Marek
>>
>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
More information about the dri-devel
mailing list