Code review comment for lp:~mir-team/mir/enable-dynamic-buffer-queue
Revision history for this message
| Gerry Boland (gerboland) wrote | # |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
Just a probably stupid question from me:
> (2) That's a bit surprising. For most of the year or so since I implemented
> bypass, 3 buffers was the minimum. Less than that and the client/server would
> be waiting for each other indefinitely (hence visibly freeze). And a month ago
> I could still reproduce some deadlocks, sometimes. But I can't today. It looks
> like possibly:
> (a) Alan's newish async client buffer swapping solved the primary problem,
> as there is now significant time during swap_buffers where the client owns
> zero buffers. So that leaves the minimum 2 available for the server to bypass
> with, and then release one back to the client. Also...
> (b) Bug 1319765 was unsolved around the time I was seeing deadlocks most
> recently so that could have been all of the remaining deadlocks, now solved.
>
> Although I'm not yet 100% confident, it does look like bypass can now work
> with only two buffers. A win for performance!
If the client is being blocked from having any buffer to render into, doesn't that reduce the amount of time it has a buffer to render into? So for a client which takes just under 16ms to render each frame, and the server holds onto 2 buffers for >1ms, then the client will keep missing vsync?