[PATCH libdrm] libdrm_amdgpu: add kernel semaphore support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux