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

[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?
e.g. to create a tree to manage bo handle in libdrm?

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
>