Change-Id: I7adc1e01f4f9cec56e53e620ba4d04eae61f0b9e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/254899
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Hopefully this is a better name. "POD" is no longer accurate since we are storing GrPipeline's in this arena.
Bug: skia:9455
Change-Id: I610267633088b0af4f0cbb36f479bf5eb6c6d0cb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/254992
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Handy if you want to flush, or otherwise understand the underlying buffer(s).
Change-Id: I3d6610695c8603232192b26c687c6c74512165dd
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/254803
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Change-Id: I01259b685859e2d95e4b87c0f611ccc074bd5229
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/254807
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Reed <reed@google.com>
More cleaning to do if we like this idea...
Change-Id: I608143db085911565dd5f5426f7ee6436ec58cdf
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/254680
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Lots of x86 instructions can take their right hand side argument from
memory directly rather than a register. We can use this to avoid the
need to allocate a register for many constants.
The strategy in this CL is one of several I've been stewing over, the
simplest of those strategies I think. There are some trade offs
particularly on ARM; this naive ARM implementation means we'll load&op
every time, even though the load part of the operation can logically be
hoisted. From here on I'm going to just briefly enumerate a few other
approaches that allow the optimization on x86 and still allow the
immediate splats to hoist on ARM.
1) don't do it on ARM
A very simple approach is to simply not perform this optimization on
ARM. ARM has more vector registers than x86, and so register pressure
is lower there. We're going to end up with splatted constants in
registers anyway, so maybe just let that happen the normal way instead
of some roundabout complicated hack like I'll talk about in 2). The
only downside in my mind is that this approach would make high-level
program descriptions platform dependent, which isn't so bad, but it's
been nice to be able to compare and diff debug dumps.
2) split Op::splat up
The next less-simple approach to this problem could fix this by
splitting splats into two Ops internally, one inner Op::immediate that
guantees at least the constant is in memory and is compatible with
immediate-aware Ops like mul_f32_imm, and an outer Op::constant that
depends on that Op::immediate and further guarantees that constant has
been broadcast into a register to be compatible with non-immediate-aware
ops like div_f32. When building a program, immediate-aware ops would
peek for Op::constants as they do today for Op::splats, but instead of
embedding the immediate themselves, they'd replace their dependency with
the inner Op::immediate.
On x86 these new Ops would work just as advertised, with Op::immediate a
runtime no-op, Op::constant the usual vbroadcastss. On ARM
Op::immediate needs to go all the way and splat out a register to make
the constant compatible with immediate-aware ops, and the Op::constant
becomes a noop now instead. All this comes together to let the
Op::immediate splat hoist up out of the loop while still feeding
Op::mul_f32_imm and co. It's a rather complicated approach to solving
this issue, but I might want to explore it just to see how bad it is.
3) do it inside the x86 JIT
The conceptually best approach is to find a way to do this peepholing
only inside the JIT only on x86, avoiding the need for new
Op::mul_f32_imm and co. ARM and the interpreter don't benefit from this
peephole, so the x86 JIT is the logical owner of this optimization.
Finding a clean way to do this without too much disruption is the least
baked idea I've got here, though I think the most desirable long-term.
Cq-Include-Trybots: skia.primary:Test-Debian9-Clang-GCE-CPU-AVX2-x86_64-Debug-All-SK_USE_SKVM_BLITTER,Test-Debian9-Clang-GCE-CPU-AVX2-x86_64-Release-All-SK_USE_SKVM_BLITTER
Change-Id: Ie9c6336ed08b6fbeb89acf920a48a319f74f3643
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/254217
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
The matrices we're using can produce very slightly out of range color
channels. This gives surprising results when in shader blending is used
for color burn and color dodge. After this change we clamp the RGB
values to 0..1 before applying premul.
Adds a GM modeled on a blink layout test that shows the problem using
SkImageMakeFromYUVAPixmaps.
Bug: skia:9619
Change-Id: I446d39763a7f5a2f7c5f61d94d163927d851baa3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/253879
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
As we've learned there's not much advantage to working directly in i32
ops over f32... it's the same size, kind of a wash speed-wise, and f32
supports all operations we want where i32 supports only a subset. If we
really want to go fast, we need to focus on i16 operations, which are
both significantly faster and operate on twice as much data at a time.
(This is the same split as SkRasterPipeline, highp f32 and lowp i16.)
For now port everything to f32, with i16 to follow, perhaps much later.
There's a little here we could spin off to land first (uniformF, better
unpremul) but I think it might be easiest to land all at once.
Cq-Include-Trybots: skia.primary:Test-Debian9-Clang-GCE-CPU-AVX2-x86_64-Debug-All-SK_USE_SKVM_BLITTER
Change-Id: I6fa0fd2031a0de18456abf529cc5b0d8137ecbe0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/253704
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Reed <reed@google.com>
This centralizes the logic for whether a color type is normalized.
The change in SkRasterPipelineBlitter is minor, only now properly
treating kR16G16_float_SkColorType as unnormalized.
The change in SkColorSpaceXformSteps is more extreme given the way
it had been written, with all the newer color types now correct.
I think I'm making the right call on kA16_float_SkColorType?
Are there equivalent sites to update in Ganesh?
Change-Id: I32a40b31b86c5fde0dea2528122a4deda91c5545
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/253668
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
With these things exposed, I think Flutter will not need
CanvasKit to expose the very complex SkCodec API.
Change-Id: Iace1b496d1dcb8842181466e860e8f212aba7b48
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/253542
Reviewed-by: Leon Scroggins <scroggo@google.com>
This basically wraps up the old `uniforms` and `buf` params
into a new type that has push() and pushF() methods that return
a value you can pass directly to Builder::uniform32() and co.
I think this has uniforms about as streamlined as they can get.
Change-Id: I8f611f91b4a2d7cdb8f05ce0333669d2e3930be8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/252937
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
It's clearer and more efficient to emit uniforms
as we use them. The pattern to look for is something like
skvm::I32 val = p->uniform32(uniforms, buf->bytes());
buf->push_back(fVal);
where fVal holds the actual uniform value, and val is its program
counterpart.
Switching to SkTDArray lets us use friendlier methods like bytes() and
append(N) in the effect code.
It's a lot easier to follow this way once you get used to it and much
less error-prone. No need to split the can-we-do-it logic up from the
uniform emission, and so no chance to write logic twice that
acccidentally disagrees.
Effects now always emit uniforms when you call program(), which means we
occasionally do that twice, once when building the Key to look up cached
programs, and once again when building the program if the cache misses.
That's not that big of a deal... it reuses the same memory exactly, and
I've added some notes around the code and assertions that everything
matches up exactly. It only happens on cache miss, so it's dwarfed by
the cost of building and JITing the program anwyay.
Change-Id: I55a9252b11b2c0cd5f7ab8ace6df5fef29342c10
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/252837
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Rm unused function SkColorTypeIsGray.
Expect kGray_8 readback to work in tests.
Bug: skia:8962
Change-Id: Iad9d2be3e0a2e594e62dc681b79c59e0a833116a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/245162
Auto-Submit: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
- move some helpers to central spot
- add a color filter interface, the same as shader without (x,y)
- implement matrix color filter (pretty naively)
and color filter shader (pretty reasonably)
- extend GM to demonstrate
The new blitters with color filters are failing to JIT because they're
running out of registers. (They still work fine on the interpreter of
course.) I'm going to take a look to see whether there's something I
can do either in the effect program() code or in the optimizer to
rearrange to get it to fit and JIT.
Cq-Include-Trybots: skia.primary:Test-Debian9-Clang-GCE-CPU-AVX2-x86_64-Debug-All-SK_USE_SKVM_BLITTER
Change-Id: Ibdc1a5e7b9e7a14778efba583b7821bcd4f3062a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/252788
Reviewed-by: Mike Klein <mtklein@google.com>
This reverts commit 701522798a.
Reason for revert: Maybe blocking the Android roll
Original change's description:
> Fully embrace skcms types in SkColorSpace API
>
> Remove the SkMatrix44 getter entirely.
>
> Change-Id: I25bfe68a7a9b21d8a8696415b517cb79fc2d7a94
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/252596
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Mike Klein <mtklein@google.com>
TBR=mtklein@google.com,brianosman@google.com,reed@google.com
Change-Id: Ic277d54d4ac8c84f00405946c927a3aee4e33068
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/252801
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Remove the SkMatrix44 getter entirely.
Change-Id: I25bfe68a7a9b21d8a8696415b517cb79fc2d7a94
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/252596
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Change-Id: Ie704f0f83b1034ff8ee1a5d3cd194e555cae20a3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/252600
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Auto-Submit: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
This initializes more formats correctly with solid colors and relies
less on GrPixelConfig.
It also includes the changes to get gray8 read pixels working
and almost everything to initialize GL_RGB8 textures with data. Minor
stuff to follow to get RGB8 fully working and update test expectations.
Bug: skia:8962
Bug: skia:6718
Bug: skia:9358
Change-Id: Ic044b4c4badc37f14fb46c898cd3b3c21a6fc7fd
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/251199
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Change-Id: I7902e4355999f31bf92aa8294a2c1a32840249c2
Bug: chromium:960620
Change-Id: I7902e4355999f31bf92aa8294a2c1a32840249c2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/252479
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Remove the RGB/YUV helpers (use SkYUVMath instead), along with the
unused get20/set20.
Change-Id: Id83467a1b7f33657869e0a933af75387a4e36a88
Bug: skia:9543
Change-Id: Id83467a1b7f33657869e0a933af75387a4e36a88
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/252188
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Change-Id: I8ef13b78a5f2f49ff9c59db285b3e0e7ee708c9b
Bug: chromium:960620
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/252160
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
typename 'B0' is defined in sys/termios.h
Bug: none
Change-Id: I6a2e6eb1a91f123459087280b70493dab795bbd3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/249917
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Herb Derby <herb@google.com>
The conversion math for a given space can be fully derived
from the Kr and Kb terms (plus the headroom/footroom), so
avoid redundant values that can be wrong.
And, no need to list every possible value of an enum param,
especially when the generated doxygen links to the type's
documentation, which has all the values listed.
Change-Id: I64ce8cfd5ec7ff74dc3b878202b13d0d483e1db6
Bug: skia:9543
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/251764
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
The new webgpu_cpp.h hotness for native apps brings with it a new
namespace: wgpu. This is a straight substitution.
Note: no Skia API changes.
Change-Id: I12b26417e76838cd8fa2b39b8161cbaa2cd8fa78
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/251660
Commit-Queue: Stephen White <senorblanco@chromium.org>
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Dawn uses symbols in its API which Xlib.h #defines, which causes
compile-time conflicts. However, they do need to work in Chrome, so we
work around them the way Chrome does: by redefining them as static
constants (see https://cs.chromium.org/chromium/src/ui/gfx/x/x11.h).
Change-Id: Ibef0fd9976503cd606aa0fa646998df54675efb2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/250998
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Chrome is now using the newer version.
Bug: skia:8962
Change-Id: I8c38bde63e1e032281d19b0cc7cb8cf301061a9e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/251198
Commit-Queue: Greg Daniel <egdaniel@google.com>
Auto-Submit: Brian Salomon <bsalomon@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
When run on cooperative threads, we need to notify the threading system
when we're going to block (in any way, sleep or spin) so that it doesn't
wake that thread up expecting it to make forward progress.
This should cover SkOnce, SkSpinlock, SkSemaphore, and by extension
SkMutex. Not sure if there are others to hit, but really the only way
to find out is by deadlocked stack traces. This CL (obviously?) does
nothing to mark synchronization primitives used by Skia's dependencies,
and in general I don't think we can do anything about them.
See cr/275261423 for more background and discussion. It's not clear to
me that marking these symbols as weak is necessary, so I figured I'd
just try not doing that and seeing what breaks. I can always follow up
with weak symbols if proven necessary.
Bug: skia:9577
Change-Id: I2c03fe92c58ad506dd8a68bdc90a09b28f965149
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/251221
Commit-Queue: Mike Klein <mtklein@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
This reverts commit b74d5548a4.
Reason for revert: see if this fixes the android roll
Original change's description:
> Track device coordinate space as matrix
>
> This is a required step to be able to cleanly draw image filtered
> device layers with arbitrary matrices, instead of relying on
> SkMatrixImageFilter to apply the transformation.
>
> Bug: skia:9545
> Change-Id: I8d84679a281538875cf4a1b73565294fb7f89c86
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/249076
> Commit-Queue: Michael Ludwig <michaelludwig@google.com>
> Reviewed-by: Mike Reed <reed@google.com>
TBR=robertphillips@google.com,reed@google.com,michaelludwig@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: skia:9545
Change-Id: Ie374a7500cfbff35cb0782beb863086e118a005a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/249986
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
This CL begins pulling some of the work forward into onPrePrepare.
Change-Id: If049e0662db51b465b8b82aafebeef2323bddfd4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/249802
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Uses SkISize instead of separate width/height variables in many places.
No functional change.
Change-Id: If87b2c57e43d810f0820c4e3c9ef8e6b8ebd10ba
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/249886
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Bug: skia:9552
Change-Id: Ifa199048e6d38ccb28f055b77128971411203188
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/249800
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
This is a required step to be able to cleanly draw image filtered
device layers with arbitrary matrices, instead of relying on
SkMatrixImageFilter to apply the transformation.
Bug: skia:9545
Change-Id: I8d84679a281538875cf4a1b73565294fb7f89c86
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/249076
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Bug: skia:6718
Change-Id: Ia6363d74f016b076fa5e19a57d223f7c47b723c0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/248999
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Brings over skcms' encoding scheme, etc.
Change-Id: Ib8abec911acd1c50df3b201b4a9bde01b1cb123b
Bug: chromium:960620
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/249000
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
This change also allows for the remove of GrPixelConfigIsOpaque function.
Bug: skia:6718
Change-Id: I7e7b70f02d911eda67640d648fb6348091e0f55d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/248698
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Bug: skia:6718
Change-Id: I4d9c31bc0ca42a80e652de29462531587efef031
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/248257
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Bug: skia:6718
Change-Id: I0f9c7d89e732c59bdbe76ab45d42934029106efb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/247684
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
This api will replace ComputeTextureSize.
Change-Id: I9befd8706f44250805315bdb13a559cf81c7142d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/247337
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
