content: perf tests for GpuMemoryBuffers mapping and data coherency

content: perf tests for GpuMemoryBuffers mapping and data coherency

Alternate perftest using GMB unit tests.

The idea is to benchmark how the hardware, on different usages of 
GpuMemoryBuffer, performs when a native buffer object is mapped into the CPU. 
In particular this test aims to capture the effects of data coherency and could 
be extended further to answer the following:

- measure memory mapping performance of GpuMemoryBuffer using shared memory
  (fallback case) and also native implementation of it.
- what if the Renderer process (client) just writes into the buffer object?
- what's the effect of reading from a write-combining (WC) memory? can we
  avoid read backs?
- should it be UC and/or WC mapped, to get a faster access?
- what the effect of clients doing sequential writes or non-sequential?  If
  the latter, a WC mapping may end up being very slow.

Besides, this CL mimics Chrome OS vgem_fb_test.c but using CC and content to
get a close to real feeling of the things. It's rather important to stress
native buffers, so GL and etc needs to work together with a 3D (non-fake)
output surface. These tests are running on top of content/ architecture.

TEST=content_perftests --gtest_filter=GpuMemoryBufferPerf* --ozone-platform=gbm --ozone-use-surfaceless
BUG=475633

[vignatti (out of this project), 2015-06-30 00:10:11]

tiago.vignatti@intel.com changed reviewers:
+ reveman@chromium.org

[vignatti (out of this project), 2015-06-30 00:10:12]

reveman, you been thinking it like this? I'd need to add the other operations
then to only read the buffer, etc. PTAL.

[reveman, 2015-06-30 21:19:53]

seems good in general. can you make Map test smaller instead of including all
the code from the unit test?

[vignatti (out of this project), 2015-07-01 13:52:52]

tiago.vignatti@intel.com changed reviewers:
+ dongseong.hwang@intel.com

[vignatti (out of this project), 2015-07-01 14:03:58]

On 2015/06/30 21:19:53, reveman wrote:
> seems good in general. can you make Map test smaller instead of including all
> the code from the unit test?

PTAL again, reveman. Thank you.

[vignatti (out of this project), 2015-07-01 14:20:47]

Just want to add some information here to show the usefulness this CL. Map by
itself is already quite useful. We can see that VGEM is taking way more time to
map than the fallback case (shared-memory): 
https://gist.githubusercontent.com/tiagovignatti/5e2b2e434c5ea8d3cbe5/raw/141...

for testing purposes, I've tried also a native implementation that executes DRM
Intel specific calls instead VGEM. The results are better than VGEM:
https://gist.githubusercontent.com/tiagovignatti/9a7c0cfa0523c04adc43/raw/568...

Idea is to enhance now this with other tests that would show how memory behaves
when doing different operation (read, write and read & write) in the mapped
buffer, so we can get a better feeling on what kind of features of the mapped
memory we would like to use for Chromium.

[vignatti (out of this project), 2015-07-01 17:31:26]

this CL depends on the up coming NativePixmapManager
(https://codereview.chromium.org/1128113011/)