Validate texture sizes given to VDA

Validate texture sizes given to VDA

Make sure that the texture sizes as passed from the untrusted renderer to the
to the VDA on the GPU process match with the texture's size as the GPU
process has tracked it.

BUG=chromium:168293
TEST=local build, run on x86, snow

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=175101

[sheu, 2013-01-04 00:47:54]

I don't know if there is an existing bug number I should be using for this;
please advise.  The last two commits by cevans@ refer to bugs that I cannot
access.

[Ami GONE FROM CHROMIUM, 2013-01-04 01:23:30]

LGTM assuming the "run on x86, snow" TESTED line refers to running *and* HW
decode still works ;)

[sheu, 2013-01-04 01:29:10]

On 2013/01/04 01:23:30, Ami Fischman wrote:
> LGTM assuming the "run on x86, snow" TESTED line refers to running *and* HW
> decode still works ;)

SW decode works on x86, HW decode works on snow.  I don't have a HW-accelerated
x86 platform ATM; I'm gonna let the bots try that.

[commit-bot: I haz the power, 2013-01-04 01:29:49]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/sheu@chromium.org/11722023/1

[Chris Evans, 2013-01-04 01:31:49]

On 2013/01/04 01:29:49, I haz the power (commit-bot) wrote:
> CQ is trying da patch. Follow status at
> https://chromium-status.appspot.com/cq/sheu%40chromium.org/11722023/1

LGTM

Thanks for doing this. There's not a bug number. Could you file one, cc:me and
reference it in this CL? That'd be awesome.

[Ami GONE FROM CHROMIUM, 2013-01-04 01:34:16]

FWIW there is no bot coverage for HW decode on x86, since x86 platforms
only have h264 HW decoders (>=win7 & >=lumpy) and the bots build chromium
not Chrome, so no h264 for them.

[commit-bot: I haz the power, 2013-01-04 01:45:32]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/sheu@chromium.org/11722023/1

[commit-bot: I haz the power, 2013-01-04 04:44:36]

Change committed as 175101

[dwkang1, 2013-01-15 08:17:45]

https://chromiumcodereview.appspot.com/11722023/diff/1/content/common/gpu/med...
File content/common/gpu/media/gpu_video_decode_accelerator.cc (right):

https://chromiumcodereview.appspot.com/11722023/diff/1/content/common/gpu/med...
content/common/gpu/media/gpu_video_decode_accelerator.cc:235:
info->GetLevelSize(0, 0, &width, &height);
crbug says I don't have permission for 168293. So I leave a comment here.

Could you check this works well in Debug build? It seems that this line leads to
a DCHECK error in texture_manager.cc:37. According to the GetLevelSize() code,
the first argument of this call should be texture target.

[sheu, 2013-01-15 08:25:38]

https://chromiumcodereview.appspot.com/11722023/diff/1/content/common/gpu/med...
File content/common/gpu/media/gpu_video_decode_accelerator.cc (right):

https://chromiumcodereview.appspot.com/11722023/diff/1/content/common/gpu/med...
content/common/gpu/media/gpu_video_decode_accelerator.cc:235:
info->GetLevelSize(0, 0, &width, &height);
On 2013/01/15 08:17:46, dwkang1 wrote:
> crbug says I don't have permission for 168293. So I leave a comment here.
> 
> Could you check this works well in Debug build? It seems that this line leads
to
> a DCHECK error in texture_manager.cc:37. According to the GetLevelSize() code,
> the first argument of this call should be texture target.

It looks like you're right; I'll have to follow-up on this CL.  It turns out the
"face" argument isn't "face index", but "face target": 

http://code.google.com/searchframe#OAMlx_jo-ck/src/gpu/command_buffer/service...

Behavior is still correct in release build; we hit a NOTREACHED(), but default
to 0, which is what we want.  Still need to fix though.