0

I'm currently using atrace on Android to record and analyze the state of the OS during a video workload. Specifically, I'm monitoring the system's BufferQueue sizes throughout the execution. atrace logs the sizes of these buffers as they are queued/acquired over time.

However, in some of my traces, this leads to impossible situations. The C|171|SurfaceView|x lines denote 'x' as being the number of textures queued in the buffer. For example, sometimes during a single acquire, two buffers are removed instead of one (which should be impossible):

     Binder_5-4526   (  171) [002] ...1  1621.656462: tracing_mark_write: B|171|queueBuffer
     Binder_5-4526   (  171) [002] ...1  1621.656493: tracing_mark_write: C|171|SurfaceView|2
surfaceflinger-171   (  171) [002] ...1  1621.664886: tracing_mark_write: B|171|acquireBuffer
surfaceflinger-171   (  171) [002] ...1  1621.664978: tracing_mark_write: C|171|SurfaceView|0
Shookit
  • 1,162
  • 2
  • 13
  • 29

1 Answers1

1

In the BufferQueueConsumer.cpp file in Android's platform code (e.g., https://android.googlesource.com/platform/frameworks/native/+/android-5.0.1_r1/libs/gui/BufferQueueConsumer.cpp), check out the acquireBuffer function.

In certain situations (e.g., the buffer is out of date), the function may decide to drop a buffer from the queue. There is no atrace indication of this event happening, you will simply see the buffer's size jump from 2 to 0.

There's also potential for closely interleaved queueBuffer/acquireBuffer commands where they print some unexpected buffer size transitions.

Shookit
  • 1,162
  • 2
  • 13
  • 29