<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Nov 2, 2018 at 3:39 AM Koenig, Christian <<a href="mailto:Christian.Koenig@amd.com">Christian.Koenig@amd.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div text="#000000" bgcolor="#FFFFFF">
<div class="m_7102524736659915582moz-cite-prefix">Am 31.10.18 um 23:12 schrieb Marek Olšák:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr">On Wed, Oct 31, 2018 at 3:59 AM Koenig, Christian <<a href="mailto:Christian.Koenig@amd.com" target="_blank">Christian.Koenig@amd.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Am 30.10.18 um 16:59 schrieb Michel Dänzer:<br>
> On 2018-10-30 4:52 p.m., Marek Olšák wrote:<br>
>> On Tue, Oct 30, 2018, 11:49 AM Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>> wrote:<br>
>>> On Tue, Oct 30, 2018, 4:20 AM Michel Dänzer <<a href="mailto:michel@daenzer.net" target="_blank">michel@daenzer.net</a>> wrote:<br>
>>><br>
>>>> On 2018-10-29 10:15 p.m., Marek Olšák wrote:<br>
>>>>> You and I discussed this extensively internally a while ago. It's<br>
>>>> expected<br>
>>>>> and correct behavior. Mesa doesn't unmap some buffers and never will.<br>
>>>> It doesn't need to keep mapping the same buffer over and over again<br>
>>>> though, does it?<br>
>>>><br>
>>> It doesnt map it again. It just doesnt unmap. So the next map call just<br>
>>> returns the pointer. It's correct to stop the counter wraparound.<br>
>>><br>
>> Mesa doesn't track whether a buffer is already mapped. Libdrm tracks that.<br>
>> It's a feature of libdrm to return the same pointer and expect infinite<br>
>> number of map calls.<br>
> That's not what the reference counting in libdrm is intended for. It's<br>
> for keeping track of how many independent callers have mapped the<br>
> buffer. Mesa should remember that it mapped a buffer and not map it again.<br>
<br>
Well if Mesa just wants to query the existing mapping then why not add a <br>
amdgpu_bo_get_cpu_ptr() which just queries if a CPU mapping exists and <br>
if yes returns the appropriate pointer or NULL otherwise?<br>
<br>
I mean when we want to abstract everything in libdrm then we just need <br>
to add the functions we need to use this abstraction.<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</blockquote>
<br>
That it doesn't help old Mesa is unfortunate, but this is clearly a bug in Mesa.<br>
<br>
If old Mesa is broken then we should fix it by updating it and not add workarounds for specific clients in libdrm.<br></div></blockquote><div><br></div><div>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.<br></div><div><br></div><div>Marek<br></div></div></div>