Re: [PATCH libdrm 1/2] amdgpu: prevent an integer wraparound of cpu_map_count

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Nov 2, 2018 at 3:39 AM Koenig, Christian <Christian.Koenig@xxxxxxx> wrote:
Am 31.10.18 um 23:12 schrieb Marek Olšák:
On Wed, Oct 31, 2018 at 3:59 AM Koenig, Christian <Christian.Koenig@xxxxxxx> wrote:
Am 30.10.18 um 16:59 schrieb Michel Dänzer:
> On 2018-10-30 4:52 p.m., Marek Olšák wrote:
>> On Tue, Oct 30, 2018, 11:49 AM Marek Olšák <maraeo@xxxxxxxxx> wrote:
>>> On Tue, Oct 30, 2018, 4:20 AM Michel Dänzer <michel@xxxxxxxxxxx> wrote:
>>>
>>>> On 2018-10-29 10:15 p.m., Marek Olšák wrote:
>>>>> You and I discussed this extensively internally a while ago. It's
>>>> expected
>>>>> and correct behavior. Mesa doesn't unmap some buffers and never will.
>>>> It doesn't need to keep mapping the same buffer over and over again
>>>> though, does it?
>>>>
>>> It doesnt map it again. It just doesnt unmap. So the next map call just
>>> returns the pointer. It's correct to stop the counter wraparound.
>>>
>> Mesa doesn't track whether a buffer is already mapped. Libdrm tracks that.
>> It's a feature of libdrm to return the same pointer and expect infinite
>> number of map calls.
> That's not what the reference counting in libdrm is intended for. It's
> for keeping track of how many independent callers have mapped the
> buffer. Mesa should remember that it mapped a buffer and not map it again.

Well if Mesa just wants to query the existing mapping then why not add a
amdgpu_bo_get_cpu_ptr() which just queries if a CPU mapping exists and
if yes returns the appropriate pointer or NULL otherwise?

I mean when we want to abstract everything in libdrm then we just need
to add the functions we need to use this abstraction.

That can be future work for the sake of cleanliness and clarity, but it would be a waste of time and wouldn't help old Mesa.

That it doesn't help old Mesa is unfortunate, but this is clearly a bug in Mesa.

If old Mesa is broken then we should fix it by updating it and not add workarounds for specific clients in libdrm.

It's not a workaround. We made a decision with amdgpu to share code by moving portions of the Mesa winsys into libdrm. The map_count is part of that. It's highly desirable to continue with code sharing. There is nothing broken with Mesa. Mesa won't check whether a buffer is already mapped. That's the responsibility of libdrm as part of code sharing and we don't want to duplicate the same logic in Mesa. It's all part of the intended design.

Marek
_______________________________________________
amd-gfx mailing list
amd-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux