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
