[PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)

[Marek Olšák]

Can this be implemented as a wrapper on top of libdrm? So that the
tree (or hash table) isn't created for UMDs that don't need it.

Marek

On Tue, Jul 31, 2018 at 6:13 AM, Christian König
<ckoenig.leichtzumerken at gmail.com> wrote:
> Am 31.07.2018 um 11:54 schrieb Zhang, Jerry (Junwei):
>>
>> On 07/31/2018 05:04 PM, Christian König wrote:
>>>
>>> Am 31.07.2018 um 10:58 schrieb Zhang, Jerry (Junwei):
>>>>
>>>> On 07/31/2018 04:13 PM, Christian König wrote:
>>>>>
>>>>> Am 31.07.2018 um 10:05 schrieb Zhang, Jerry (Junwei):
>>>>>>
>>>>>> On 07/31/2018 03:03 PM, Christian König wrote:
>>>>>>>
>>>>>>> Am 31.07.2018 um 08:58 schrieb Zhang, Jerry (Junwei):
>>>>>>>>
>>>>>>>> On 07/30/2018 06:47 PM, Christian König wrote:
>>>>>>>>>
>>>>>>>>> Am 30.07.2018 um 12:02 schrieb Junwei Zhang:
>>>>>>>>> [SNIP]
>>>>>>>>> Please double check if that is still up to date.
>>>>>>>>
>>>>>>>>
>>>>>>>> We may have to replace drm_gem_object_reference() with
>>>>>>>> drm_gem_object_get().
>>>>>>>>
>>>>>>>> On 2nd thought, do we really need to do reference every time?
>>>>>>>
>>>>>>>
>>>>>>> Yes, that's a must have. Otherwise the handle could be freed and
>>>>>>> reused already when we return.
>>>>>>>
>>>>>>>> if UMD find the same gem object for 3 times, it also need to
>>>>>>>> explicitly free(put) that object for 3 times?
>>>>>>>
>>>>>>>
>>>>>>> Correct yes. Thinking more about this the real problem is to
>>>>>>> translate the handle into a structure in libdrm.
>>>>>>>
>>>>>>> Here we are back to the problem Marek and Michel has been working on
>>>>>>> for a while that we always need to be able to translate a handle into a bo
>>>>>>> structure.....
>>>>>>>
>>>>>>> So that needs to be solved before we can upstream the changes.
>>>>>>
>>>>>>
>>>>>> Thanks for your info.
>>>>>> It's better to fix that before upstream.
>>>>>
>>>>>
>>>>> Thinking more about this the hash currently used in libdrm is not
>>>>> adequate any more.
>>>>>
>>>>> E.g. we now need to be able to find all BOs based on their handle.
>>>>> Since the handles are dense either an r/b tree or a radix tree now sounds
>>>>> like the best approach to me.
>>>>
>>>>
>>>> Not sure the exact reason that we added hash table in libdrm.
>>>
>>>
>>> The reason for that was that when a kernel function returns a handle we
>>> need to make sure that we always use the same struct amdgpu_bo for it.
>>>
>>> Otherwise you run into quite some problems with syncing etc...
>>
>>
>> Thanks for your explanation.
>>
>>>
>>>> But it really costs much less time than calling IOCTL to find BO by
>>>> their handles.
>>>
>>>
>>> Well we could just completely drop the kernel implementation and use an
>>> userspace implementation.
>>
>>
>> Do you mean to implement finding bo by cpu address in libdrm completely?
>
>
> Yes, exactly.
>
>> e.g. to create a tree to manage bo handle in libdrm?
>
>
> I mean when we need to create a tree to map the handle to a BO you could
> also create a tree to map the CPU pointer to the BO directly and avoid the
> IOCTL overhead completely.
>
> Christian.
>
>
>>
>> Jerry
>>
>>>
>>> And yes I agree when we need a tree anyway it would probably be faster
>>> than calling the IOCTL to find the BO.
>>>
>>> Christian.
>>>
>>>>
>>>> In this case, UMD seems not to be able to get BO handle and try to
>>>> verify it by cpu address then.
>>>> In another word, UMD would like to find if the memory is created as BO
>>>> or system memory, I suppose.
>>>>
>>>> Regards,
>>>> Jerry
>>>>
>>>>
>>>>>
>>>>> Christian.
>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Jerry
>>>>>
>>>>>
>>>> _______________________________________________
>>>> 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
>
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx