[PATCH libdrm 1/2] amdgpu: prevent an integer wraparound of cpu_map_count
Marek Olšák
maraeo at gmail.com
Wed Oct 31 22:12:09 UTC 2018
On Wed, Oct 31, 2018 at 3:59 AM Koenig, Christian <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> wrote:
> >>> On Tue, Oct 30, 2018, 4:20 AM Michel Dänzer <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.
Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20181031/e2bebab8/attachment.html>
More information about the amd-gfx
mailing list