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.romant...@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 <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

Reply via email to