<div dir="ltr">Hello,<div>i've updated patch simply,</div><div>but that seems requires additional checking because in call <i>dri3_handle_present_event </i>potentially may happens reset of '<i>busy</i>' with condition '<i>buf->pixmap == ie->pixmap</i>'</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 6, 2018 at 9:03 PM, Thomas Hellstrom <span dir="ltr"><<a href="mailto:thellstrom@vmware.com" target="_blank">thellstrom@vmware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<div><div class="h5"><br>
<br>
On 04/06/2018 04:51 PM, Daniel Stone wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Sergii,<br>
<br>
On 6 April 2018 at 09:12, Sergii Romantsov <<a href="mailto:sergii.romantsov@gmail.com" target="_blank">sergii.romantsov@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Commit 3160cb86aa92 adds optimization with flag 'reallocate'.<br>
Processing of flag causes buffers freeing while pointer<br>
is still hold in caller stack and than again used to be freed.<br>
</blockquote>
Thanks a lot for writing this. I take it the core of the problem is<br>
that dri3_handle_present_event() can be called whilst we're inside<br>
dri3_get_buffer(), which wasn't the case before.<br>
<br>
This was only introduced as of a727c804a2c1, and I'm not sure I fully<br>
follow the rationale for that commit. Thomas, why do we need to<br>
process the events? I guess we could also fake it by turning 'busy'<br>
into a refcount, which would be incremented/decremented as it is today<br>
when posting buffers and getting Idle events, but also when we're<br>
holding a local pointer which we can't have stolen from under us.<br>
<br>
Cheers,<br>
Daniel<br>
</blockquote>
<br></div></div>
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...<span class="HOEnZb"><font color="#888888"><br>
<br>
/Thomas<br>
<br>
</font></span></blockquote></div><br></div>