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