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

[Christian König]

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