Turn on MPD threading in nanobench.

Turn on MPD threading in nanobench.

Seems okay after this small patch to skip lockPixels() / unlockPixels().

BUG=skia:3149
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu13.10-GCE-NoGPU-x86_64-Release-TSAN-Trybot

Committed: https://skia.googlesource.com/skia/+/4f10844149bbc05f0259a1b3199c2f995756ed60

[mtklein, 2014-12-03 20:32:29]

The CQ bit was checked by mtklein@google.com

[commit-bot: I haz the power, 2014-12-03 20:33:17]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/773203003/20001

[commit-bot: I haz the power, 2014-12-03 20:33:18]

Note for Reviewers:
The CQ is waiting for an approval.
If you believe that the CL is not ready yet, or if you would like to L-G-T-M
with comments then please uncheck the CQ checkbox.

Waiting for LGTM from valid reviewer(s) till 2014-12-04 02:33 UTC

[mtklein, 2014-12-03 20:33:31]

The CQ bit was unchecked by mtklein@google.com

[mtklein, 2014-12-03 20:33:34]

The CQ bit was unchecked by mtklein@google.com

[mtklein, 2014-12-03 20:34:08]

The CQ bit was checked by mtklein@google.com

[mtklein, 2014-12-03 20:34:15]

mtklein@google.com changed reviewers:
+ robertphillips@google.com

[commit-bot: I haz the power, 2014-12-03 20:34:17]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/773203003/20001

[commit-bot: I haz the power, 2014-12-03 20:34:18]

Note for Reviewers:
The CQ is waiting for an approval.
If you believe that the CL is not ready yet, or if you would like to L-G-T-M
with comments then please uncheck the CQ checkbox.

Waiting for LGTM from valid reviewer(s) till 2014-12-04 02:34 UTC

[robertphillips, 2014-12-03 20:35:58]

lgtm

[mtklein, 2014-12-03 20:41:05]

FYI, switched to a stack copy of the bitmap so that non-texture non-plain-pixel
bitmaps (e.g. generators) work.

I figure this should be negligible cost, so might as well be super safe.

[mtklein, 2014-12-03 20:41:30]

The CQ bit was checked by mtklein@google.com

[commit-bot: I haz the power, 2014-12-03 20:42:16]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/773203003/40001

[commit-bot: I haz the power, 2014-12-03 21:07:44]

Committed patchset #3 (id:40001) as
https://skia.googlesource.com/skia/+/4f10844149bbc05f0259a1b3199c2f995756ed60

[reed2, 2014-12-04 11:45:47]

reed@chromium.org changed reviewers:
+ reed@chromium.org

[reed2, 2014-12-04 11:45:47]

I wonder if we can make the copy of the bitmap in the constructor of the
shader's "context" -- that may be a clearer place to document that we're going
from a 'immutable-sharable-state' to a per-thread-mutable one'.

[mtklein, 2014-12-04 14:23:06]

On 2014/12/04 11:45:47, reed2 wrote:
> I wonder if we can make the copy of the bitmap in the constructor of the
> shader's "context" -- that may be a clearer place to document that we're going
> from a 'immutable-sharable-state' to a per-thread-mutable one'.

Yes, as long as it's a stack-scoped copy, we can make it anywhere. 
Alternatively, if we bubbled this check up all the way to the SkBitmapProcState
constructor, we don't need any extra copy.  Though obviously we'd need to hang
on to that extra bit somehow.

We might also want to take a look at how much work it'd be to make
kBitmap::lockPixels() and SkBitmap::unlockPixels() non-const.

[reed1, 2014-12-04 14:29:27]

On 2014/12/04 14:23:06, mtklein wrote:
> On 2014/12/04 11:45:47, reed2 wrote:
> > I wonder if we can make the copy of the bitmap in the constructor of the
> > shader's "context" -- that may be a clearer place to document that we're
going
> > from a 'immutable-sharable-state' to a per-thread-mutable one'.
> 
> Yes, as long as it's a stack-scoped copy, we can make it anywhere. 
> Alternatively, if we bubbled this check up all the way to the
SkBitmapProcState
> constructor, we don't need any extra copy.  Though obviously we'd need to hang
> on to that extra bit somehow.
> 
> We might also want to take a look at how much work it'd be to make
> kBitmap::lockPixels() and SkBitmap::unlockPixels() non-const.

"bubbled this check up all the way to the SkBitmapProcState constructor" -- yes,
that is what I intended by "context" construction. I will try a CL that does
that.

[mtklein, 2014-12-04 14:33:32]

> "bubbled this check up all the way to the SkBitmapProcState constructor" --
yes,
> that is what I intended by "context" construction. I will try a CL that does
> that.

Now I'm confused.  Just to be super clear, either of
SkBitmapProcShader::SkBitmapProcShader or SkBitmapProcShader::onCreateContext
are fine places to do this check.  SkBitmapProcShader::onCreateContext is where
we're doing it today.  There'd be no copy needed in
SkBitmapProcShader::SkBitmapProcShader.