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