These don't return reliable portable results, so I don't want to promote
them as good ideas to use. You can get at least 5 different results
from these across the four main architectures we support, and they've
been the root cause of bugs uncovered only in production on undertested
platforms.
Luckily, unused outside of tests.
Change-Id: I532731fe4cddf127253341e5ace8d9c5c9ebb0f1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/326108
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
- add f32<->f16 functions to skvx
- add f32<->f16 x86 instructions to skvm::Assembler
- add f32<->f16 ops to skvm,
using the skvx functions in the interpreter
Still TODO:
use the new x86 instructions in the JIT
(For now like in many other ways, the aarch64 JIT
continues to languish. Will pick that back up one day.)
Change-Id: Ib8dc1ccdc75ecb23769ea4947d66d3ab22520f23
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/302942
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Current strategy: everything from the top
Things to look at first are the manual changes:
- added tools/rewrite_includes.py
- removed -Idirectives from BUILD.gn
- various compile.sh simplifications
- tweak tools/embed_resources.py
- update gn/find_headers.py to write paths from the top
- update gn/gn_to_bp.py SkUserConfig.h layout
so that #include "include/config/SkUserConfig.h" always
gets the header we want.
No-Presubmit: true
Change-Id: I73a4b181654e0e38d229bc456c0d0854bae3363e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/209706
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Hal Canary <halcanary@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Yet another surprising finding when looking at ARM code generation is
that passing these values to functions by const& does make a difference,
even when fully inlined. I can only guess that the compiler's somehow
more sure that way that the values won't change? Anyway, convert all
skvx functions that take Vec arguments to take const Vec& instead.
This tweak is enough to let the natural implementation of mull()
actually produce good code generation, so I've promoted that to SkVx.h
and added a unit test. Notice in the NEON case we've got a base case at
N=8 and two recursive cases, one down to 8 as usual when N > 8, but also
one up to 8 when N < 8.
This also is another big speedup for ARMv7 NEON, bringing it to nearly
the same speed as ARMv8 NEON on the same device.
Bug: chromium:952502
Change-Id: I0f19bab45cf02222ccc8090053ea2a4a380f1dfe
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/208582
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
- be more explicit about casting
- general rewrite for clarity
Cq-Include-Trybots: skia.primary:Test-Win2016-MSVC-GCE-CPU-AVX2-x86_64-Debug-All-MSRTC
Change-Id: I924d6d247e6b9afcefb27c690715fdad84635a5d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/207721
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
These replicate the base logic of Sk4px::Wide::div255() and
Sk4px::approxMulDiv255(), and will come in handy replacing them.
No platform specializations yet... want to remind myself what
codegen they get from these vanilla versions first, and then
I'll fill in the platform specific stuff as needed. The tests
should cover everything pretty exhaustively.
Change-Id: I5854d1bc0902a85cbb2351f669c4da7cc31a8775
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/207683
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Was starting to use this and ran into a few problems with clashing
symbols, namely SI and cast(). Seemed simple enough to not use SI,
and to move all the free-standing types into skvx: skvx::cast,
skvx::shuffle, etc.
Change-Id: Ia5d8ef6d0ae5375bf80d76be88d16f0c9cde56e7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/207340
Commit-Queue: Mike Klein <mtklein@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Guarding the implict constructors and scalar/vector
operations with std::is_convertible ought to make SkVx
types feel more like normal C types, allowing implicit
conversions exactly when the scalar equivalents would.
This shouldn't change the behavior of any code, or make
anything new possible... just nicer to read and write.
Change-Id: Iff4b89012c5b8c7f7933e6841c925b81186bc614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/201402
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Add SSE, SSE4.1, and NEON specializations.
The if_then_else() unit tests in SkVxTest.cpp should cover this.
I had to give up on my dream of not using Skia headers for now. There's
really no good way of knowing whether we've got SSE4.1 support in MSVC
except when we explicitly define SK_CPU_SSE_LEVEL=SK_CPU_SSE_LEVEL_SSE41.
This refactor to use SK_CPU_SSE_LEVEL let MSVC point out a slight
ordering problem that would cause an infinite loop calling any of
the specializions like sqrt(float2). I believe moving them after
the float4 specializations will fix that.
Change-Id: I83639f378a182716d1b37e92b6d725472698f874
Reviewed-on: https://skia-review.googlesource.com/c/195920
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
- remove ALWAYS_INLINE until we find we need it
- make bit_puns explicit
- implement everything recursively so, e.g.
sqrt(float8) picks up sqrt(float4) when
not otherwise specialized.
- implement SSE specializations:
of the operations I tested, only sqrt, rcp, and rsqrt
needed any help. The others look good as-is.
Change-Id: I1b679c7bd9a99f952272b118d7ade2469b55d604
Reviewed-on: https://skia-review.googlesource.com/c/190222
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Change-Id: Ie3e5b353f84e74d398a5350dc0baff5541789119
Reviewed-on: https://skia-review.googlesource.com/c/189982
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: Herb Derby <herb@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Obviously lots of these new operations like sqrt() will want platform
specialization. That'll come later.
Change-Id: Ia0758425d4ec5911968a3d0ad63fa387b9b4cb39
Reviewed-on: https://skia-review.googlesource.com/c/189848
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Change-Id: I1cb8113af243ed6327179d295835295834a752aa
Reviewed-on: https://skia-review.googlesource.com/c/189581
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
