Remove non-PIC specializations of media SIMD YUV conversion routines.

Remove non-PIC specializations of media SIMD YUV conversion routines.

This change is made with an eye towards supporting different color ranges in YUV conversion (namely, YUVJ420P). This will require passing in a pointer to a conversion table, so the non-PIC code which hardcodes the table address is problematic (it is likely possible to code around this and maintain some of the slight perf gain of the non-PIC code, but it would require even more ugly, difficult-to-maintain code).

This will cause a small performance regression for platforms where PIC code is not required (32-bit Windows only afaik).

The nearest-neighbor scaling routines take the biggest perf hit (up to 20%), but are currently not actually used anywhere. The rest (straight conversion, and bilinear scaling) didn't show an appreciable performance hit in my tests.

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

[rileya (GONE FROM CHROMIUM), 2014-04-21 21:15:36]

I'd originally done this in another CL that added YUVJ support, but it seemed
like it'd be cleaner as a standalone change.

As noted in the description I didn't see an appreciable perf difference (in
32bit Windows) for anything but the nearest-neighbor scaling code (which is
currently not used anywhere as far as I can tell; we always use the bilinear
scaling version instead).

I'd like to land https://codereview.chromium.org/238353008/ before this and
watch the perf graphs, as my one-off tests on a single Windows machine may not
be representative.

[scherkus (not reviewing), 2014-04-22 18:13:50]

lgtm

OOC can we remove the nearest neighbour code?

I'm not a fan of leaving in unused code -- source control can take care of
keeping a copy

[rileya (GONE FROM CHROMIUM), 2014-04-23 18:19:54]

It looks like it still is used as a fallback for very large frames
(https://code.google.com/p/chromium/codesearch#chromium/src/media/base/yuv_con...),
and I don't see a trivial way of removing that usage, so I think it's probably
best left for some more thought and a future CL.

[scherkus (not reviewing), 2014-04-23 18:23:37]

On 2014/04/23 18:19:54, rileya wrote:
> It looks like it still is used as a fallback for very large frames
>
(https://code.google.com/p/chromium/codesearch#chromium/src/media/base/yuv_con...),
> and I don't see a trivial way of removing that usage, so I think it's probably
> best left for some more thought and a future CL.

Sounds good .. FWIW I'm extremely suspect of all those comments and code. Seems
like the buffer size could be computed rather than a fixed constant...

[rileya (GONE FROM CHROMIUM), 2014-04-29 15:11:06]

The CQ bit was checked by rileya@chromium.org

[commit-bot: I haz the power, 2014-04-29 15:11:23]

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

[commit-bot: I haz the power, 2014-04-29 16:37:44]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-04-29 16:37:45]

Try jobs failed on following builders:
  win_chromium_rel on tryserver.chromium

[rileya (GONE FROM CHROMIUM), 2014-04-30 21:59:33]

The CQ bit was checked by rileya@chromium.org

[commit-bot: I haz the power, 2014-04-30 21:59:52]

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

[commit-bot: I haz the power, 2014-04-30 22:53:40]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-04-30 22:53:40]

Try jobs failed on following builders:
  linux_chromium_chromeos_rel on tryserver.chromium

[rileya1, 2014-04-30 22:54:54]

The CQ bit was checked by rileya@google.com

[commit-bot: I haz the power, 2014-04-30 22:55:49]

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

[commit-bot: I haz the power, 2014-05-01 00:28:18]

Change committed as 267390