[Mesa-dev] [PATCH] dri3: Prevent multiple freeing of buffers.

Sergii Romantsov sergii.romantsov at gmail.com
Tue Apr 10 08:10:54 UTC 2018


Hello,
i've updated patch simply,
but that seems requires additional checking because in call
*dri3_handle_present_event
*potentially may happens reset of '*busy*' with condition '*buf->pixmap ==
ie->pixmap*'

On Fri, Apr 6, 2018 at 9:03 PM, Thomas Hellstrom <thellstrom at vmware.com>
wrote:

> Hi,
>
>
> On 04/06/2018 04:51 PM, Daniel Stone wrote:
>
>> Hi Sergii,
>>
>> On 6 April 2018 at 09:12, Sergii Romantsov <sergii.romantsov at gmail.com>
>> wrote:
>>
>>> Commit 3160cb86aa92 adds optimization with flag 'reallocate'.
>>> Processing of flag causes buffers freeing while pointer
>>> is still hold in caller stack and than again used to be freed.
>>>
>> Thanks a lot for writing this. I take it the core of the problem is
>> that dri3_handle_present_event() can be called whilst we're inside
>> dri3_get_buffer(), which wasn't the case before.
>>
>> This was only introduced as of a727c804a2c1, and I'm not sure I fully
>> follow the rationale for that commit. Thomas, why do we need to
>> process the events? I guess we could also fake it by turning 'busy'
>> into a refcount, which would be incremented/decremented as it is today
>> when posting buffers and getting Idle events, but also when we're
>> holding a local pointer which we can't have stolen from under us.
>>
>> Cheers,
>> Daniel
>>
>
> The motivation for this commit IIRC was that with internal glretrace
> automated tests, we typically would end up with corrupt rendering due to
> invalid viewports after window resizes. The resize events were typically
> not picked up as fast with dri3 as with dri2, so due to the lack of
> documented strategy how to handle window- and viewport resizes with dri3
> clients, I tried to make it mimic dri2 where we had no such issues. The
> reason for the slow pick up was that dri3 was waiting for fences rather
> than on X replies...
>
> /Thomas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180410/a4ebacc6/attachment-0001.html>


More information about the mesa-dev mailing list