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
