When targetting iOS and using gyp to generate the build files, it is not
possible to select files to build depending on the architecture. Due to
that, the skia code was disabling all optimisation when SK_BUILD_FOR_IOS
was defined.
Since it is possible to select the correct optimised version when using
gn, this pessimisation is hurting the build. Introduce a new define to
disable the optimisation SK_BUILD_NO_OPTS. It will be used by Chromium
when building skia for iOS with gyp but not gn.
Define SK_BUILD_NO_OPTS along-side SK_BUILD_FOR_IOS for all files that
look like build configuration (Xcode projects, gyp configuration files,
public.bzl) in order to avoid introducing breakage on those builds.
BUG=607933
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2002423002
Review-Url: https://codereview.chromium.org/2002423002
- remove dead code
- rewrite float -> int converters
The strategy for the new converters is:
- convert input to double
- floor/ceil/round in double space
- pin that double to [SK_MinS32, SK_MaxS32]
- truncate that double to int32_t
This simpler strategy does not work:
- floor/ceil/round in float space
- pin that float to [SK_MinS32, SK_MaxS32]
- truncate that float to int32_t
SK_MinS32 and SK_MaxS32 are not representable as floats:
they round to the nearest float, ±2^31, which makes the
pin insufficient for floats near SK_MinS32 (-2^31+1) or
SK_MaxS32 (+2^31-1).
float only has 24 bits of precision, and we need 31.
double can represent all integers up to 50-something bits.
An alternative is to pin in float to ±2147483520, the last
exactly representable float before SK_MaxS32 (127 too small).
Our tests test that we round as floor(x+0.5), which can
return different numbers than round(x) for negative x.
So this CL explicitly uses floor(x+0.5).
I've updated the tests with ±inf and ±NaN, and tried to
make them a little clearer, especially using SK_MinS32
instead of -SK_MaxS32.
I have not timed anything here. I have never seen any of these
methods in a profile.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2012333003
Review-Url: https://codereview.chromium.org/2012333003
Adds a new GrUserStencilSettings class that describes in abstract terms
how a draw will use the stencil (e.g. kAlwaysIfInClip, kSetClipBit,
etc.). GrPipelineBuilder now only defines the GrUserStencilSettings.
When the GrPipeline is finalized, the user stencil settings are then
translated into concrete GrStencilSettings.
At this point, GrClipMaskManager only needs to tell the GrAppliedClip
whether or not there is a stencil clip. It does not need to modify
stencil settings and GrPipelineBuilder does not need
AutoRestoreStencil.
This is one step of the stencil overhaul. In the future it will also
allow us to clean up the special case handling for nvpr and the
stateful fClipMode member of GrClipMaskManager.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1962243002
Committed: https://skia.googlesource.com/skia/+/12dbb3947e1aaf205b4fcf13b40e54e50650eb37
Review-Url: https://codereview.chromium.org/1962243002
Reason for revert:
This seems to be breaking nanobench on the Windows bots with:
Caught exception 3221225477 EXCEPTION_ACCESS_VIOLATION
GrDrawTarget::stencilPath +c7
GrStencilAndCoverPathRenderer::onDrawPath +fd
GrDrawContext::internalDrawPath +509
GrDrawContext::drawPath +223
GrBlurUtils::drawPathWithMaskFilter +250
SkGpuDevice::drawPath +2ea
SkCanvas::onDrawPath +2e3
SkRecordDraw +2e6
SkBigPicture::playback +e5
SkCanvas::onDrawPicture +12c
SkCanvas::drawPicture +145
SkRecordDraw +2e6
SkBigPicture::playback +e5
SkCanvas::onDrawPicture +12c
SkCanvas::drawPicture +145
SkRecordDraw +261
SkBigPicture::playback +e5
SkCanvas::onDrawPicture +12c
SkCanvas::drawPicture +145
SkMultiPictureDraw::draw +bf
SKPBench::drawMPDPicture +1e0
SKPBench::onDraw +34
Benchmark::draw +32
time +92
setup_gpu_bench +6e
nanobench_main +77b
Original issue's description:
> Separate user and raw stencil settings
>
> Adds a new GrUserStencilSettings class that describes in abstract terms
> how a draw will use the stencil (e.g. kAlwaysIfInClip, kSetClipBit,
> etc.). GrPipelineBuilder now only defines the GrUserStencilSettings.
> When the GrPipeline is finalized, the user stencil settings are then
> translated into concrete GrStencilSettings.
>
> At this point, GrClipMaskManager only needs to tell the GrAppliedClip
> whether or not there is a stencil clip. It does not need to modify
> stencil settings and GrPipelineBuilder does not need
> AutoRestoreStencil.
>
> This is one step of the stencil overhaul. In the future it will also
> allow us to clean up the special case handling for nvpr and the
> stateful fClipMode member of GrClipMaskManager.
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1962243002
>
> Committed: https://skia.googlesource.com/skia/+/12dbb3947e1aaf205b4fcf13b40e54e50650eb37TBR=bsalomon@google.com,cdalton@nvidia.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/1969693003
Adds a new GrUserStencilSettings class that describes in abstract terms
how a draw will use the stencil (e.g. kAlwaysIfInClip, kSetClipBit,
etc.). GrPipelineBuilder now only defines the GrUserStencilSettings.
When the GrPipeline is finalized, the user stencil settings are then
translated into concrete GrStencilSettings.
At this point, GrClipMaskManager only needs to tell the GrAppliedClip
whether or not there is a stencil clip. It does not need to modify
stencil settings and GrPipelineBuilder does not need
AutoRestoreStencil.
This is one step of the stencil overhaul. In the future it will also
allow us to clean up the special case handling for nvpr and the
stateful fClipMode member of GrClipMaskManager.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1962243002
Review-Url: https://codereview.chromium.org/1962243002
Currently this class was just used for resource handles when building up
a shader. However, I want to now use this class for things like objects
owned/held by the GrVkResourceProvider which are used by other classes.
An example of this will be for GrVkRenderTargets to hold a handle to a
collection of compatible render passes without having to own/hold onto
the render passes themselves.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1955893002
Review-Url: https://codereview.chromium.org/1955893002
It's always nice to kill off a synchronization primitive.
And while less terse, I think this new code reads more clearly.
... and, SkOncePtr's tests were the only thing now using sk_num_cores()
outside of SkTaskGroup, so I've hidden it as static inside SkTaskGroup.cpp.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1953533002
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Review-Url: https://codereview.chromium.org/1953533002
Implemented as a different subclass for SkColorShader (which is also private) partly to make the CL clearer/simpler, and partly for flatten/unflatten compatibility. Later I'm sure we could combine these if that proves useful.
Lots of TODOs at the moment, but still valuable to get reviewed.
Note: this ignores the question (for the moment) about how to interpret SkColor in the larger world. That needs to happen, but this CL is more focused on what *else* to do besides handle the old-style input (and old-style pipeline).
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1934313002
Review-Url: https://codereview.chromium.org/1934313002
Renames some classes to avoid confusion with FontConfig.
Removed direct calls to FontConfig instead of calling FCI.
Moves the globals and factory to one (optional) file.
Moves font management code from typeface to font manager.
Adds index to fonts created from streams.
Associates FCI typefaces with the FCI instance which provides its identity.
Simplifies the singleton initialization.
Review-Url: https://codereview.chromium.org/1936213002
Reason for revert:
From what I can tell, this compiles on 2015 but not 2013.
Original issue's description:
> Add initial implementation of GrShape and GrStyle classes and tests
>
> The initial intent is to use GrShape to simplify the mask blur code paths. However, I also want to use this to explore a more unified drawing code flow for different geometry types. The goal is to have a single representation for geometries+styling that attempts to always keep the geometry in the simplest form (e.g. preferring rrects to paths). It also allows for converting styling information into modified geometry and for computing consistent keys.
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1822723003
>
> Committed: https://skia.googlesource.com/skia/+/c885dacfe4625af8b0e2e5c6e8a8ae8dc2d620a8TBR=egdaniel@google.com,bsalomon@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/1918203002
The initial intent is to use GrShape to simplify the mask blur code paths. However, I also want to use this to explore a more unified drawing code flow for different geometry types. The goal is to have a single representation for geometries+styling that attempts to always keep the geometry in the simplest form (e.g. preferring rrects to paths). It also allows for converting styling information into modified geometry and for computing consistent keys.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1822723003
Review URL: https://codereview.chromium.org/1822723003
The main goal of this refactorization is to allow Vulkan to use separate
sampler and texture objects in the shader and descriptor sets and combine
them into a sampler2d in the shader where needed.
A large part of this is separating how we store samplers and uniforms in the
UniformHandler. We no longer need to store handles to samplers besides when
we are initially emitting code. After we emit code all we ever do is loop over
all samplers and do some processor independent work on them, so we have no need
for direct access to individual samplers.
In the GLProgram all we ever do is set the sampler uniforms in the ctor and never
touch them again, so no need to save sampler info there. The texture access on
program reuse just assume that they come in the same order as we set the texture
units for the samplers
For Vulkan, it is a similar story. We create the descriptor set layouts with the samplers,
then when we get new textures, we just assume they come in in the same order as we
set the samplers on the descriptor sets. Thus no need to save direct vulkan info.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1885863004
Committed: https://skia.googlesource.com/skia/+/45b61a1c4c0be896e7b12fd1405abfece799114f
Review URL: https://codereview.chromium.org/1885863004
Reason for revert:
breaking bots
Original issue's description:
> Refactor how we store and use samplers in Ganesh
>
> The main goal of this refactorization is to allow Vulkan to use separate
> sampler and texture objects in the shader and descriptor sets and combine
> them into a sampler2d in the shader where needed.
>
> A large part of this is separating how we store samplers and uniforms in the
> UniformHandler. We no longer need to store handles to samplers besides when
> we are initially emitting code. After we emit code all we ever do is loop over
> all samplers and do some processor independent work on them, so we have no need
> for direct access to individual samplers.
>
> In the GLProgram all we ever do is set the sampler uniforms in the ctor and never
> touch them again, so no need to save sampler info there. The texture access on
> program reuse just assume that they come in the same order as we set the texture
> units for the samplers
>
> For Vulkan, it is a similar story. We create the descriptor set layouts with the samplers,
> then when we get new textures, we just assume they come in in the same order as we
> set the samplers on the descriptor sets. Thus no need to save direct vulkan info.
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1885863004
>
> Committed: https://skia.googlesource.com/skia/+/45b61a1c4c0be896e7b12fd1405abfece799114fTBR=bsalomon@google.com,jvanverth@google.com,cdalton@nvidia.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/1896013003
The main goal of this refactorization is to allow Vulkan to use separate
sampler and texture objects in the shader and descriptor sets and combine
them into a sampler2d in the shader where needed.
A large part of this is separating how we store samplers and uniforms in the
UniformHandler. We no longer need to store handles to samplers besides when
we are initially emitting code. After we emit code all we ever do is loop over
all samplers and do some processor independent work on them, so we have no need
for direct access to individual samplers.
In the GLProgram all we ever do is set the sampler uniforms in the ctor and never
touch them again, so no need to save sampler info there. The texture access on
program reuse just assume that they come in the same order as we set the texture
units for the samplers
For Vulkan, it is a similar story. We create the descriptor set layouts with the samplers,
then when we get new textures, we just assume they come in in the same order as we
set the samplers on the descriptor sets. Thus no need to save direct vulkan info.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1885863004
Review URL: https://codereview.chromium.org/1885863004
- 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
