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

[Sergii Romantsov]

Hello (ping) Thomas and Daniel,
any more suggestions? As i can see Eero has done a test-run and v2 also
looks good.

As alternative solution we also may try to call '*dri3_fence_await(draw->conn,
draw, buffer)'* with '*draw*'-parameter as '*NULL'.*
What do you think?

On Tue, Apr 10, 2018 at 11:10 AM, Sergii Romantsov <
sergii.romantsov at gmail.com> wrote:

> 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/20180416/6e5af50e/attachment.html>