- Moves CPU feature detection to its own file.
- Cleans up some redundant feature detection scattered around core/ and opts/.
- Can now detect a few new CPU features:
* F16C -> Intel f16<->f32 instructions, added between AVX and AVX2
* FMA -> Intel FMA instructions, added at the same time as AVX2
* VFP_FP16 -> ARM f16<->f32 instructions, quite common
* NEON_FMA -> ARM FMA instructions, also quite common
* SSE and SSE3... why not?
This new internal API makes it very cheap to do fine-grained runtime CPU
feature detection. Redundant calls to SkCpu::Supports() should be eliminated
and it's hoistable out of loops. It compiles away entirely when we have the
appropriate instructions available at compile time.
This means we can call it to guard even a little snippet of 1 or 2 instructions
right where needed and let inlining hoist the check (if any at all) up to
somewhere that doesn't hurt performance. I've explained how I made this work
in the private section of the new header.
Once this lands and bakes a bit, I'll start following up with CLs to use it more
and to add a bunch of those little 1-2 instruction snippets we've been wanting,
e.g. cvtps2ph, cvtph2ps, ptest, pmulld, pmovzxbd, blendvps, pshufb, roundps
(for floor) on x86, and vcvt.f32.f16, vcvt.f16.f32 on ARM.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1890483002
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Committed: https://skia.googlesource.com/skia/+/872ea29357439f05b1f6995dd300fc054733e607
Review URL: https://codereview.chromium.org/1890483002
Reason for revert:
many unexpected GM diffs across GPU+CPU configs on Windows (hopefully just text masks on GPU?). seems like we pick a different srcover variant in some places.
Original issue's description:
> Move CPU feature detection to its own file.
>
> - Moves CPU feature detection to its own file.
> - Cleans up some redundant feature detection scattered around core/ and opts/.
> - Can now detect a few new CPU features:
> * F16C -> Intel f16<->f32 instructions, added between AVX and AVX2
> * FMA -> Intel FMA instructions, added at the same time as AVX2
> * VFP_FP16 -> ARM f16<->f32 instructions, quite common
> * NEON_FMA -> ARM FMA instructions, also quite common
> * SSE and SSE3... why not?
>
> This new internal API makes it very cheap to do fine-grained runtime CPU
> feature detection. Redundant calls to SkCpu::Supports() should be eliminated
> and it's hoistable out of loops. It compiles away entirely when we have the
> appropriate instructions available at compile time.
>
> This means we can call it to guard even a little snippet of 1 or 2 instructions
> right where needed and let inlining hoist the check (if any at all) up to
> somewhere that doesn't hurt performance. I've explained how I made this work
> in the private section of the new header.
>
> Once this lands and bakes a bit, I'll start following up with CLs to use it more
> and to add a bunch of those little 1-2 instruction snippets we've been wanting,
> e.g. cvtps2ph, cvtph2ps, ptest, pmulld, pmovzxbd, blendvps, pshufb, roundps
> (for floor) on x86, and vcvt.f32.f16, vcvt.f16.f32 on ARM.
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1890483002
> CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
>
> Committed: https://skia.googlesource.com/skia/+/872ea29357439f05b1f6995dd300fc054733e607TBR=fmalita@chromium.org,herb@google.com,reed@google.com,mtklein@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1892643003
- Moves CPU feature detection to its own file.
- Cleans up some redundant feature detection scattered around core/ and opts/.
- Can now detect a few new CPU features:
* F16C -> Intel f16<->f32 instructions, added between AVX and AVX2
* FMA -> Intel FMA instructions, added at the same time as AVX2
* VFP_FP16 -> ARM f16<->f32 instructions, quite common
* NEON_FMA -> ARM FMA instructions, also quite common
* SSE and SSE3... why not?
This new internal API makes it very cheap to do fine-grained runtime CPU
feature detection. Redundant calls to SkCpu::Supports() should be eliminated
and it's hoistable out of loops. It compiles away entirely when we have the
appropriate instructions available at compile time.
This means we can call it to guard even a little snippet of 1 or 2 instructions
right where needed and let inlining hoist the check (if any at all) up to
somewhere that doesn't hurt performance. I've explained how I made this work
in the private section of the new header.
Once this lands and bakes a bit, I'll start following up with CLs to use it more
and to add a bunch of those little 1-2 instruction snippets we've been wanting,
e.g. cvtps2ph, cvtph2ps, ptest, pmulld, pmovzxbd, blendvps, pshufb, roundps
(for floor) on x86, and vcvt.f32.f16, vcvt.f16.f32 on ARM.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1890483002
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Review URL: https://codereview.chromium.org/1890483002
Reason for revert:
We're getting sRGB non-8888 configs?
Original issue's description:
> sRGB support in Ganesh. Several pieces:
>
> sRGB support now also requires GL_EXT_texture_sRGB_decode, which allows
> us to disable sRGB -> Linear conversion when reading textures. This gives
> us an easy way to support "legacy" L32 mode. We disable decoding based on
> the pixel config of the render target. Textures can override that behavior
> (specifically for format-conversion draws where we want that behavior).
>
> Added sBGRA pixel config, which is not-really-a-format. It's just sRGBA
> internally, and the external format is BGR order, so TexImage calls will
> swizzle correctly. This lets us interact with sRGB raster surfaces on BGR
> platforms.
>
> Devices without sRGB support behave like they always have: conversion from
> color type and profile type ignores sRGB and always returns linear pixel
> configs.
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1789663002
>
> Committed: https://skia.googlesource.com/skia/+/9e3f1bf4e5cd8fc59554f986f36d6b034e99f9ebTBR=reed@google.com,bsalomon@google.com,robertphillips@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1814533003
sRGB support now also requires GL_EXT_texture_sRGB_decode, which allows
us to disable sRGB -> Linear conversion when reading textures. This gives
us an easy way to support "legacy" L32 mode. We disable decoding based on
the pixel config of the render target. Textures can override that behavior
(specifically for format-conversion draws where we want that behavior).
Added sBGRA pixel config, which is not-really-a-format. It's just sRGBA
internally, and the external format is BGR order, so TexImage calls will
swizzle correctly. This lets us interact with sRGB raster surfaces on BGR
platforms.
Devices without sRGB support behave like they always have: conversion from
color type and profile type ignores sRGB and always returns linear pixel
configs.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1789663002
Review URL: https://codereview.chromium.org/1789663002
- Move high-precision wall timers from tools/timer to SkTime.
- Implement SkTime::GetMSecs() in terms of SkTime::GetNSecs().
- Delete unused tools/timer code.
I have no idea what's going on there in src/animator.
I don't intend to investigate.
BUG=skia:
Committed: https://skia.googlesource.com/skia/+/70084cbc16ee8162649f2601377feb6e49de0217
CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Ubuntu-GCC-x86_64-Debug-CrOS_Link-Trybot
Review URL: https://codereview.chromium.org/1422513003
I'll be moving headers from src/core to include/private, so this guarantees
that anyone who was finding them via -Isrc/core can now find them via
-Iinclude/private.
This is purely mechanical, mostly to preserve my sanity, so it's likely
(harmless) overkill.
Chromium's GYP and GN builds already set -Iinclude/private for Skia builds.
BUG=skia:4126
Review URL: https://codereview.chromium.org/1265443002
Some of this is transitive, like SkRecords.h used by SkMiniRecorder.h
used by (public) SkPictureRecorder.h.
BUG=skia:
Review URL: https://codereview.chromium.org/1217293004
The interesting stuff is in SkPictureRecorder.{h,cpp}. The rest is mostly moving SkRecord from its own directories into core to avoid circular dependencies in GYP.
After plumbing SkRecord all the way through in Picture, I'll delete its old entry point include/record/SkRecording.h. For now it and record.gypi need to stay where they are to keep Chrome building.
BUG=skia:
R=reed@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/331573004
Every doc I've found about using Android's atomics says, "stop".
"* A handful of basic atomic operations. The appropriate pthread
* functions should be used instead of these whenever possible."
"... we recommend stopping from using these functions entirely. Very fortunately, GCC provides handy intrinsics functions that work with very reasonable performance and always provide a full barrier."
As far as I can tell, there's no code generation change here: both the __sync atomics and the android_ atomics use full memory barriers. (And now with this all unified, it'll be easier to get the real wins by switching everything to __atomic atomics, which are like __sync atomics but allow control over memory barriers.)
BUG=skia:
R=bungeman@google.com, djsollen@google.com, mtklein@google.com, reed@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/305593002
git-svn-id: http://skia.googlecode.com/svn/trunk@14896 2bbb7eff-a529-9590-31e7-b0007b416f81
Split off from https://codereview.chromium.org/140503007/.
The eventual goal is to create our Android.mk from gyp. This patch
adds an option for skia_android_framework with the right settings.
The follow-up (https://codereview.chromium.org/140503007/) will
use scripts to create the final makefile.
gyp/android_deps.gyp:
Use different dependencies for the framework than for building Skia
normally.
gyp/android_framework_lib.gyp:
Like skia_lib, specifies the minimum needed for building Skia, in this
case for the framework.
gyp/common_conditions.gypi:
Add settings specific to skia_android_framework. In some cases this
means turning off flags and defines.
gyp/common.gypi
Turn off SK_DEBUG and SK_DEVELOPER when building for the framework.
This allows the framework to create a single makefile which can be
modified to add SK_DEBUG and SK_DEVELOPER as desired.
gyp/common_variables.gypi:
Add skia_android_framework.
gyp/core.gyp:
Don't depend on cpufeatures, and add the cutils library for
skia_android_framework.
gyp/freetype.gyp:
skia_android_framework-specific options:
Don't include freetype_static as a dependency.
Include the proper folders.
Include the android library.
gyp/images.gyp:
Don't export libjpeg as a dependency for targets that include images
for the framework.
Also reorder image decoders to match the Android order, leaving our
most commonly used ones last (and therefore first in the chain for
trying them).
gyp/libwebp.gyp:
Use the system webp when building for the Android framework. Specify
the correct settings for the framework.
gyp/opts.gyp:
Specify a default set of files to compile when there are no possible
optimizations.
gyp/pdf.gyp:
Add dependencies for Android framework.
gyp/zlib.gyp:
Include the zlib folder, and undefine SK_ZLIB_INCLUDE.
BUG=skia:1975
R=djsollen@google.com
Committed: https://code.google.com/p/skia/source/detail?r=13298
Review URL: https://codereview.chromium.org/153093003
git-svn-id: http://skia.googlecode.com/svn/trunk@13304 2bbb7eff-a529-9590-31e7-b0007b416f81
Split off from https://codereview.chromium.org/140503007/.
The eventual goal is to create our Android.mk from gyp. This patch
adds an option for skia_android_framework with the right settings.
The follow-up (https://codereview.chromium.org/140503007/) will
use scripts to create the final makefile.
gyp/android_deps.gyp:
Use different dependencies for the framework than for building Skia
normally.
gyp/android_framework_lib.gyp:
Like skia_lib, specifies the minimum needed for building Skia, in this
case for the framework.
gyp/common_conditions.gypi:
Add settings specific to skia_android_framework. In some cases this
means turning off flags and defines.
gyp/common.gypi
Turn off SK_DEBUG and SK_DEVELOPER when building for the framework.
This allows the framework to create a single makefile which can be
modified to add SK_DEBUG and SK_DEVELOPER as desired.
gyp/common_variables.gypi:
Add skia_android_framework.
gyp/core.gyp:
Don't depend on cpufeatures, and add the cutils library for
skia_android_framework.
gyp/freetype.gyp:
skia_android_framework-specific options:
Don't include freetype_static as a dependency.
Include the proper folders.
Include the android library.
gyp/images.gyp:
Don't export libjpeg as a dependency for targets that include images
for the framework.
Also reorder image decoders to match the Android order, leaving our
most commonly used ones last (and therefore first in the chain for
trying them).
gyp/libwebp.gyp:
Use the system webp when building for the Android framework. Specify
the correct settings for the framework.
gyp/opts.gyp:
Specify a default set of files to compile when there are no possible
optimizations.
gyp/pdf.gyp:
Add dependencies for Android framework.
gyp/zlib.gyp:
Include the zlib folder, and undefine SK_ZLIB_INCLUDE.
BUG=skia:1975
R=djsollen@google.com
Review URL: https://codereview.chromium.org/153093003
git-svn-id: http://skia.googlecode.com/svn/trunk@13298 2bbb7eff-a529-9590-31e7-b0007b416f81
