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