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...
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.
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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
