New Buffer Semantics Planning

[Kevin DuBois]

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.

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().

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.

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.

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.

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".

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.

Thanks,
Kevin

¹ 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.

²
https://code.launchpad.net/~kdub/mir/bstream-integration-test/+merge/263014
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20150625/56147e62/attachment.html>