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 <thellst...@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.romant...@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
>
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to