[PATCH libdrm] libdrm_amdgpu: add kernel semaphore support
Christian König
deathsimple at vodafone.de
Mon Jul 17 17:35:55 UTC 2017
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.
Christian.
> Marek
More information about the dri-devel
mailing list