<div dir="ltr"><div>I've started spiking a bit on how to transition the system to what we've been calling the new buffer semantics¹, and come up with a plan. We've already landed the ipc plumbing, now we have to make use of it to its potential.<br><br></div><div>Obviously, the number one thing to avoid is regressions in performance or functionality while transitioning. So, we'll get the new semantics up to par, and then switch the default from rpc exchange_buffer() to rpc submit_buffer().<br><br></div><div>With the ability to send buffers without a client request, we're really turning the system around and eliminating the need for mc::BuffeQueue::client_acquire(). As this is one of the 4 important entry points to BufferQueue, it seems difficult to have BufferQueue service both the exchange/next_buffers swapping, and the new buffer semantics; especially as we have a semi-nice mc::BufferStream interface that we could write a new implementation for.<br></div><div><br></div><div>BufferQueue's unit test is tied to mc::BufferQueue, and has some threading cruft from back when we had to wait more often. BufferQueue actually has a simple locking strategy these days... just lock at the top of the member function. BufferQueue's unit test is also the guard we have against regressions, so we shouldn't move the test in order to have less regressions.<br><br></div><div>So, I've started writing an integration-level test that currently tests BufferQueue in terms of production/consumption² Instead of relying on threading to tease out the different patterns, the patterns are just specified to be ones of interest (eg, overproduction, starving the consumer). Its not complete (meaning, covers all the cases that BufferQueueTest does) yet.<br><br></div><div>Once that test is roughly on-par with the BufferQueue test, we start writing the client-side and server-side production code for the new buffer system. Once that's done and tested, we'll probably have to do a bit of careful study using some of the latency tools Alexandros has been working on, and some of the benchmarks before flipping the new-buffer-semantics switch to "on". <br></div><div><br></div><div>Sharing the plan just to see if everyone's on the same page. Not blocked on anything right now, but somewhere down the road, we might want to deprecate at least the rpc call to next_buffer() or exchange_buffer(), as well as come up with the client api that nested or multimedia can use to manage the client buffers.<br><br></div><div>Thanks,<br></div><div>Kevin<br></div><div><br></div><div>¹ Currently, we just let clients hold own one buffer. A few compelling cases (multimedia decoding, AV synchronization, nested latency optimizations, SET_BUFFER_COUNT from the mali driver, and lp: #1369763) suggest that we should let advanced clients manage their own buffers. <br><br>² <a href="https://code.launchpad.net/~kdub/mir/bstream-integration-test/+merge/263014">https://code.launchpad.net/~kdub/mir/bstream-integration-test/+merge/263014</a></div></div>