content: perf tests for GpuMemoryBuffers mapping and data coherency

content: perf tests for GpuMemoryBuffers mapping and data coherency

The idea is to benchmark how the hardware, on different usages of
GpuMemoryBuffer, performs when the native buffer object (bo) is mapped into
the CPU. In particular this test aims to capture the effects of data coherency
and 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.

(Note that content/child directory is not a strong requirement; I've only
placed this perf test there cause the foundation's of it got stolen from
child_thread_impl_browsertest.cc)

TEST=content_browsertests --ozone-platform=gbm --ozone-use-surfaceless --no-sandbox --gtest_filter=ChildThreadImplGpuMemoryBufferPerfTests*
BUG=475633

[vignatti (out of this project), 2015-06-17 00:55:48]

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

[vignatti (out of this project), 2015-06-18 19:55:59]

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

[vignatti (out of this project), 2015-06-18 20:05:03]

reveman, this is something I'm using to test GpuMemoryBuffer mapping time. It's
useful to benchmark the underlying buffer handling system that we eventually
going to use in CrOS. For example, I've applied dshwang's CL (1134993003) and
noticed that GpuMemoryBuffer shared memory is faster than VGEM (something we
need to fix!).

Let me know what do you think about this and/or how we can enhance it further.

[reveman, 2015-06-18 21:08:58]

I think this is useful

https://codereview.chromium.org/1187793006/diff/20001/content/child/child_thr...
File content/child/child_thread_impl_perftest.cc (right):

https://codereview.chromium.org/1187793006/diff/20001/content/child/child_thr...
content/child/child_thread_impl_perftest.cc:1: // Copyright 2015 The Chromium
Authors. All rights reserved.
hm, this is a browser perf test. is _perftest.cc the correct prefix for that?

https://codereview.chromium.org/1187793006/diff/20001/content/child/child_thr...
content/child/child_thread_impl_perftest.cc:26: enum MemoryOperation {
kMemoryOperationWrite, kMemoryOperationNoop };
would this make more sense as separate tests? Map, Write, ReadWrite, etc.

https://codereview.chromium.org/1187793006/diff/20001/content/child/child_thr...
content/child/child_thread_impl_perftest.cc:47: NativeBufferFlag
native_buffer_flag_;
do we need this as a member?

https://codereview.chromium.org/1187793006/diff/20001/content/child/child_thr...
content/child/child_thread_impl_perftest.cc:82: return "fallback";
"fallback" can be confusing as kEnableNativeBuffers doesn't necessarily mean
that native buffers are used. We might fallback if not available. maybe just ""
and "native"

https://codereview.chromium.org/1187793006/diff/20001/content/child/child_thr...
content/child/child_thread_impl_perftest.cc:138: "us", true);
can we just have one result per test? Map shows time to execute map, Write shows
time to write into buffer, etc.

https://codereview.chromium.org/1187793006/diff/20001/content/child/child_thr...
content/child/child_thread_impl_perftest.cc:160:
EXPECT_EQ(memcmp(static_cast<char*>(planes[plane]) + y * strides[plane],
this does more than write..

[vignatti (out of this project), 2015-06-18 21:59:46]

Thanks for reviewing. I'll be working on this now then.

https://codereview.chromium.org/1187793006/diff/20001/content/child/child_thr...
File content/child/child_thread_impl_perftest.cc (right):

https://codereview.chromium.org/1187793006/diff/20001/content/child/child_thr...
content/child/child_thread_impl_perftest.cc:1: // Copyright 2015 The Chromium
Authors. All rights reserved.
On 2015/06/18 21:08:57, reveman wrote:
> hm, this is a browser perf test. is _perftest.cc the correct prefix for that?

I don't know where to add this test to be honest. I just thought that it should
end with _perftest.cc prefix given it is a perf test :) Any idea where is the
best place to fit this in?

https://codereview.chromium.org/1187793006/diff/20001/content/child/child_thr...
content/child/child_thread_impl_perftest.cc:26: enum MemoryOperation {
kMemoryOperationWrite, kMemoryOperationNoop };
On 2015/06/18 21:08:57, reveman wrote:
> would this make more sense as separate tests? Map, Write, ReadWrite, etc.

Acknowledged.

https://codereview.chromium.org/1187793006/diff/20001/content/child/child_thr...
content/child/child_thread_impl_perftest.cc:47: NativeBufferFlag
native_buffer_flag_;
On 2015/06/18 21:08:58, reveman wrote:
> do we need this as a member?

Acknowledged.

https://codereview.chromium.org/1187793006/diff/20001/content/child/child_thr...
content/child/child_thread_impl_perftest.cc:82: return "fallback";
On 2015/06/18 21:08:57, reveman wrote:
> "fallback" can be confusing as kEnableNativeBuffers doesn't necessarily mean
> that native buffers are used. We might fallback if not available. maybe just
""
> and "native"

Acknowledged.

https://codereview.chromium.org/1187793006/diff/20001/content/child/child_thr...
content/child/child_thread_impl_perftest.cc:138: "us", true);
On 2015/06/18 21:08:57, reveman wrote:
> can we just have one result per test? Map shows time to execute map, Write
shows
> time to write into buffer, etc.

as I said in the comment, I think right now I prefer spam everything on the
screen to understand why VGEM for example is recording quite different numbers
(https://gist.githubusercontent.com/tiagovignatti/02497f1f3d81e20649ab/raw/d41...).

Alternatively I think we could print out the mean and the standard deviation
capture this dispersion. wdyt?

https://codereview.chromium.org/1187793006/diff/20001/content/child/child_thr...
content/child/child_thread_impl_perftest.cc:160:
EXPECT_EQ(memcmp(static_cast<char*>(planes[plane]) + y * strides[plane],
On 2015/06/18 21:08:58, reveman wrote:
> this does more than write..

Acknowledged.

[vignatti (out of this project), 2015-06-19 23:38:51]

reveman, PTAL. I think it's closer a bit now from what you were suggesting.

[reveman, 2015-06-22 20:41:57]

https://codereview.chromium.org/1187793006/diff/20001/content/child/child_thr...
File content/child/child_thread_impl_perftest.cc (right):

https://codereview.chromium.org/1187793006/diff/20001/content/child/child_thr...
content/child/child_thread_impl_perftest.cc:1: // Copyright 2015 The Chromium
Authors. All rights reserved.
On 2015/06/18 at 21:59:45, vignatti wrote:
> On 2015/06/18 21:08:57, reveman wrote:
> > hm, this is a browser perf test. is _perftest.cc the correct prefix for
that?
> 
> I don't know where to add this test to be honest. I just thought that it
should end with _perftest.cc prefix given it is a perf test :) Any idea where is
the best place to fit this in?

Does this need to be an integration test (browsertest)? Can you implement these
perf tests as unit tests similar to gpu_memory_buffer_impl_unittests.cc instead?

[dshwang, 2015-06-25 10:52:11]

hi Tiago, it's really nice test framework.

https://codereview.chromium.org/1187793006/diff/60001/content/child/child_thr...
File content/child/child_thread_impl_perftest.cc (right):

https://codereview.chromium.org/1187793006/diff/60001/content/child/child_thr...
content/child/child_thread_impl_perftest.cc:36: ChildGpuMemoryBufferManager*
child_gpu_memory_buffer_manager_ = NULL;
nullptr.
why don't BufferPerfTest have this as member?

https://codereview.chromium.org/1187793006/diff/60001/content/child/child_thr...
content/child/child_thread_impl_perftest.cc:38: static const int kNumRuns = 30;
'static' is not needed because of anonymous namespace

https://codereview.chromium.org/1187793006/diff/60001/content/child/child_thr...
content/child/child_thread_impl_perftest.cc:54: static NativeBufferFlag
native_buffer_flag_;
why don't ChildThreadImplGpuMemoryBufferPerfTest have this as member?

https://codereview.chromium.org/1187793006/diff/60001/content/child/child_thr...
content/child/child_thread_impl_perftest.cc:56: enum MemoryOperation {
kMemoryOperationWrite, kMemoryOperationNoop };
unused

https://codereview.chromium.org/1187793006/diff/60001/content/child/child_thr...
content/child/child_thread_impl_perftest.cc:90: perf_test::PrintResult(
This test measures only Map time even in "time_to_execute_map_native: Write"
case. In addition, it's too verbose. Could you print avg or sum time after
kNumRuns times execution?

https://codereview.chromium.org/1187793006/diff/60001/content/child/child_thr...
content/child/child_thread_impl_perftest.cc:199: buffer_->Write(planes);
I think Map and Unmap should be out of 'for block', because Map seems to be as
expensive as Write.

In addition, this test print out only Map time.

[vignatti (out of this project), 2015-06-25 14:41:28]

On 2015/06/22 20:41:57, reveman wrote:
> Does this need to be an integration test (browsertest)? Can you implement
these
> perf tests as unit tests similar to gpu_memory_buffer_impl_unittests.cc
instead?

reveman, I think it needs to be an integration test.

IIUC GL and raster threads are actually the same thread when using unittests, so
the logged timestamps are not close to reality as we would like to have. So we
need all the infrastructure of Renderer, Browser and GPU process in place for
that (Ozone GBM makes this as an even stronger requirement, per CL 1208603002)
which is what browsertest gives for us.

[reveman, 2015-06-25 14:55:48]

On 2015/06/25 at 14:41:28, tiago.vignatti wrote:
> On 2015/06/22 20:41:57, reveman wrote:
> > Does this need to be an integration test (browsertest)? Can you implement
these
> > perf tests as unit tests similar to gpu_memory_buffer_impl_unittests.cc
instead?
> 
> reveman, I think it needs to be an integration test.
> 
> IIUC GL and raster threads are actually the same thread when using unittests,
so the logged timestamps are not close to reality as we would like to have. So
we need all the infrastructure of Renderer, Browser and GPU process in place for
that (Ozone GBM makes this as an even stronger requirement, per CL 1208603002)
which is what browsertest gives for us.

I'm confused. What does GL and raster threads have to do with this? We're not
doing any of that in GMB unit tests. What is it that you want to measure that is
not currently done by our GMB unit tests and could be accomplished by adding a
gpu_memory_buffer_impl_perftests.cc?

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

On 2015/06/25 14:55:48, reveman wrote:
> I'm confused. What does GL and raster threads have to do with this? We're not
> doing any of that in GMB unit tests. What is it that you want to measure that
is
> not currently done by our GMB unit tests and could be accomplished by adding a
> gpu_memory_buffer_impl_perftests.cc?

you're right, reveman. We can perform and measure all the different intended
memory accesses by using the same infrastructure of
gpu_memory_buffer_impl_unittests.cc. We won't need GL and raster stuff in
principle, so let's just start simple.

This will require something like CL 1208603002 though.

[vignatti (out of this project), 2015-07-03 16:30:05]

closing this CL in favour of https://codereview.chromium.org/1220753005, which
is content_perftests based.