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

[Koenig, Christian]

Am 31.10.18 um 23:12 schrieb Marek Olšák:
On Wed, Oct 31, 2018 at 3:59 AM Koenig, Christian <Christian.Koenig at amd.com<mailto:Christian.Koenig at amd.com>> 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 at gmail.com<mailto:maraeo at gmail.com>> wrote:
>>> On Tue, Oct 30, 2018, 4:20 AM Michel Dänzer <michel at daenzer.net<mailto:michel at daenzer.net>> 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.

Regards,
Christian.


Marek

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20181102/79d5ad3d/attachment.html>