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