Update bench pictures to time image decode & upload costs

This CL allows bench_pictures to time the setup cost of decoding textures and uploading them to the GPU. We are working towards being able to decode and upload textures in a separate thread and this benching capability will allow us to evaluate our progress.

With this change we currently have (for tabl_ukwsj):

viewport mode	
		
	with purging	without purging
gpu     228.93	        3.51
raster  184.08	        2.73
		
tiled mode	
		
	with purging	without purging
gpu     783.52	        40.17
raster  607.62	        20.28

[robertphillips, 2013-12-18 14:03:36]

Adding Hal for SkDiscardableMemoryPool side

[bsalomon, 2013-12-18 14:51:36]

https://codereview.chromium.org/117583002/diff/40001/include/gpu/GrContext.h
File include/gpu/GrContext.h (right):

https://codereview.chromium.org/117583002/diff/40001/include/gpu/GrContext.h#...
include/gpu/GrContext.h:962: friend class SkTools_PictureRenderer; // Allow
access to purgeAllUnlocked for timings
If we move the impl to the test-only cpp then maybe we don't need the
friendship.

https://codereview.chromium.org/117583002/diff/40001/src/gpu/GrContext.cpp
File src/gpu/GrContext.cpp (right):

https://codereview.chromium.org/117583002/diff/40001/src/gpu/GrContext.cpp#ne...
src/gpu/GrContext.cpp:219: void GrContext::purgeAllUnlocked() {
How about purgeAllUnlockedResources ?


Should we move this into our test-only cpp file?

https://codereview.chromium.org/117583002/diff/40001/tools/bench_pictures_mai...
File tools/bench_pictures_main.cpp (right):

https://codereview.chromium.org/117583002/diff/40001/tools/bench_pictures_mai...
tools/bench_pictures_main.cpp:45: "(only makes sense with
--deferImageDecoding).");
I don't totally follow why this only makes sense with deferred decoding.

[robertphillips, 2013-12-18 15:59:13]

https://codereview.chromium.org/117583002/diff/40001/include/gpu/GrContext.h
File include/gpu/GrContext.h (right):

https://codereview.chromium.org/117583002/diff/40001/include/gpu/GrContext.h#...
include/gpu/GrContext.h:962: friend class SkTools_PictureRenderer; // Allow
access to purgeAllUnlocked for timings
On 2013/12/18 14:51:36, bsalomon wrote:
> If we move the impl to the test-only cpp then maybe we don't need the
> friendship.

Done.

https://codereview.chromium.org/117583002/diff/40001/src/gpu/GrContext.cpp
File src/gpu/GrContext.cpp (right):

https://codereview.chromium.org/117583002/diff/40001/src/gpu/GrContext.cpp#ne...
src/gpu/GrContext.cpp:219: void GrContext::purgeAllUnlocked() {
On 2013/12/18 14:51:36, bsalomon wrote:
> How about purgeAllUnlockedResources ?
> 
> 
> Should we move this into our test-only cpp file?

Done.

https://codereview.chromium.org/117583002/diff/40001/tools/bench_pictures_mai...
File tools/bench_pictures_main.cpp (right):

https://codereview.chromium.org/117583002/diff/40001/tools/bench_pictures_mai...
tools/bench_pictures_main.cpp:45: "(only makes sense with
--deferImageDecoding).");
On 2013/12/18 14:51:36, bsalomon wrote:
> I don't totally follow why this only makes sense with deferred decoding.

Done. You're right, if we allow it anytime we can compare the cost of just
uploading to VRAM to the cost of decoding and uploading to VRAM.

Case in point:

simple viewport 1500x1000
      lazydecode+purge    just purge    
gpu    271.83                45.24
8888   184.47                 2.73

[bsalomon, 2013-12-18 16:16:12]

lgtm

https://codereview.chromium.org/117583002/diff/60001/include/gpu/GrContext.h
File include/gpu/GrContext.h (right):

https://codereview.chromium.org/117583002/diff/60001/include/gpu/GrContext.h#...
include/gpu/GrContext.h:215: * and is only available if defined outside of Skia
(see bench_pictures).
maybe instead of "is only available if defined outside of Skia", "is not defined
in normal builds of Skia" 

It's not like we want to encourage clients to provide alternate definitions :)

[hal.canary, 2013-12-18 16:28:23]

On 2013/12/18 14:03:36, robertphillips wrote:
> Adding Hal for SkDiscardableMemoryPool side

As I mentioned in person, as long as only one thread is calling
SkDiscardableMemoryPool, SkGetGlobalDiscardableMemoryPool()->dumpPool() is the
thing to call.  Call SkGetGlobalDiscardableMemoryPool()->getRAMUsed() after
dumping to verify that all of DMs were in fact unlocked at the time.

looks good.

[robertphillips, 2013-12-18 17:25:50]

committed as r12742