const and non-const for container classes such as std::vector
and std::array.
Change-Id: I6ad49de7f2f2c379ba6c964115806d058c72cd7e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/233296
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Herb Derby <herb@google.com>
This is a reland of 0c9995dc51
PS2 skips program caching on G3/iOS/ARMv7 builds.
It doesn't seem important to cache programs on this build configuration
yet, maybe ever: we're not yet JITting on ARMv7, ARMv7 iOS is a dying
platform, and non-G3 builds, both local and bot, work fine for me so
maybe it's just an old toolchain? For now I'm just disabling caching by
returning nullptr. If the list of platforms grows much bigger or more
important, I may put back a spinlock-based best-effort caching.
Original change's description:
> thread-local caches?
>
> Here's another idea... these SkVMBlitter program caches are probably
> best thread-local. If there are a bunch of threads doing the same work
> with the same program, we don't need them fighting over that one slot in
> the cache, and if there are a bunch of threads doing _different_ work,
> they'll get the best cache behavior if they don't fight over slots in
> the LRU with different programs. Either way, seems like a win?
>
> (I've kept the try-acquire/release pattern just to make the focus of
> this change more clear. We can fold it through more if we like it.)
>
> Change-Id: Ib1ee270069c48446845ce27225652896661c5dfe
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/233060
> Commit-Queue: Mike Klein <mtklein@google.com>
> Reviewed-by: Herb Derby <herb@google.com>
Cq-Include-Trybots: skia.primary:Build-Mac-Clang-arm-Debug-iOS
Change-Id: I8d8ef5ab56b914c9c305bb1729b72c8bca373337
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/233237
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This reverts commit 0c9995dc51.
Reason for revert:
Breaks G3 --config=ios_armv7. Others seem ok?
third_party/skia/HEAD/src/core/SkVMBlitter.cpp:47:9: error: thread-local storage is not supported for the current target
thread_local static auto* cache = new SkLRUCache<Key, skvm::Program>{8};
Original change's description:
> thread-local caches?
>
> Here's another idea... these SkVMBlitter program caches are probably
> best thread-local. If there are a bunch of threads doing the same work
> with the same program, we don't need them fighting over that one slot in
> the cache, and if there are a bunch of threads doing _different_ work,
> they'll get the best cache behavior if they don't fight over slots in
> the LRU with different programs. Either way, seems like a win?
>
> (I've kept the try-acquire/release pattern just to make the focus of
> this change more clear. We can fold it through more if we like it.)
>
> Change-Id: Ib1ee270069c48446845ce27225652896661c5dfe
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/233060
> Commit-Queue: Mike Klein <mtklein@google.com>
> Reviewed-by: Herb Derby <herb@google.com>
TBR=mtklein@google.com,herb@google.com,reed@google.com
Change-Id: Ie93593490d793645492b6e964632c1e71b3e3ea6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/233236
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Here's another idea... these SkVMBlitter program caches are probably
best thread-local. If there are a bunch of threads doing the same work
with the same program, we don't need them fighting over that one slot in
the cache, and if there are a bunch of threads doing _different_ work,
they'll get the best cache behavior if they don't fight over slots in
the LRU with different programs. Either way, seems like a win?
(I've kept the try-acquire/release pattern just to make the focus of
this change more clear. We can fold it through more if we like it.)
Change-Id: Ib1ee270069c48446845ce27225652896661c5dfe
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/233060
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Additionally this changes removes the version of the call that that takes
a GrPixelConfig.
As part of this change many call sites that were calling getRTSampleCount
to just check renderability have been changed to call
isFormat[AsColorType]Renderable instead. This change has also started to
move us to just checking format renderability (without GrCT) in classes
that are specifically dealing with GrSurface (GrResourceProvider, GrGpu, etc.).
Bug: skia:6718
Change-Id: Icf4a1a21a81a44e6863a7cd2059d21b9833d581f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/233039
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Bug: skia:9321
frameRect is the raw data stored in the image file, and it may not
intersect with the image's canvas. Remove that assumption.
Change-Id: I12802c9c20c0cb3506e64e14b129650ef0767f95
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/233157
Auto-Submit: Leon Scroggins <scroggo@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Nigel Tao <nigeltao@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
GDI will not use a Symbol encoded cmap table if there is no Symbol
encoded name. Always output both Unicode and Symbol names (same data,
different name entries). This fixes test_symbolfont on GDI.
Change-Id: I05dea903b9c3914a852cf31472a19a6a06b274e0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/233079
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Fixes TecnoSpark Pro compiler bug failure.
Bug: skia:9313
Change-Id: I54c077a2db71f75d50ba483b6932ffd2e18d2814
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/232583
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
No need to contend if someone else is using the cache.
I switched the attributes back to the front of the declaration;
the line for try_acquire_program_cache() was getting long and
I couldn't find any satisfyingly clear place to break it.
Change-Id: I28c24c342b10c043091c0c46bd27153e44308967
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/233058
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Switch the guard define to SK_USE_SKVM_BLITTER to match the expectations
of setting up these easy-mode-defines bots (anything starting with SK_).
Change-Id: I7dafdb31a5b2147cac8428e49d4599e50d125ab6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/233059
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Maximum ring buffer size is based on the maxBufferLength of
the system. Also includes a sample for testing upload pressure.
Bug: skia:8243
Change-Id: I36863b725ba9cbcb02d575b2ab9695d186fcd529
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/232759
Reviewed-by: Greg Daniel <egdaniel@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Just a little no-op refactor. Makes more sense to group clusters of
red,green,blue,alpha channel values into Colors.
Change-Id: I83ab628d008d68ca6d22d97f3ddd155d3e36f949
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/232821
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Reviewed-by: Mike Reed <reed@google.com>
This is a reland of d1d4cbf2e4
PS2 delays the cache initialization until acquire_program_cache()
is first called, eliminating the static initializer and destructor
from the original CL.
Original change's description:
> begin caching Programs in SkVMBlitter
>
> My first drafts put caching inside SkVM.cpp, which I rejected for
> feeling a little too magic, and then in SkVMBuilder.cpp using a
> fingerprint of the skvm::Builder to skip Builder::done().
>
> This version makes an explicit Key structure holding all the parameters
> that currently matter to the Blitter, and caches using that. This is
> nice because it can be done much more cheaply than running the JIT, and
> much more cheaply even than running the Builder. It also makes the
> parameterization of the Blitter explicit, which I like.
>
> This does sometimes create programs that are equivalent but have
> different keys, but that's not that common, and it's pretty harmless.
> E.g. today if the device colorType() is opaque or premul, we'll think
> those are different programs, but actually end up making the exact
> same calls to Builder. No big deal, and maybe even gives us a
> suggestion to do something when the destination is opaque to skip work.
> I've left that as a TODO followup.
>
> We really only need a small cache to get a good hit rate. Running all
> GMs in one process serially, we're now down to 22 calls to done() from
> >100K at head (and >500K yesterday). (Would be 13 if we treated opaque
> and premul the same.)
>
> There are two places I'd like to have used tryAcquire() on an SkSpinlock
> but the thread safety static analysis is wrong and prevents me. Left
> some TODOs.
>
> Change-Id: I83a365fc895720c76b56b0e5a78f4c673fcd9d64
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/232817
> Commit-Queue: Mike Klein <mtklein@google.com>
> Reviewed-by: Herb Derby <herb@google.com>
Change-Id: Ib6a8528be1cd89ae32b09d63c14925d9ba2f529a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/233056
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This reverts commit d1d4cbf2e4.
Reason for revert: static initializers broken checks in Chrome Roll
e.g. gProgramCache{8}
Original change's description:
> begin caching Programs in SkVMBlitter
>
> My first drafts put caching inside SkVM.cpp, which I rejected for
> feeling a little too magic, and then in SkVMBuilder.cpp using a
> fingerprint of the skvm::Builder to skip Builder::done().
>
> This version makes an explicit Key structure holding all the parameters
> that currently matter to the Blitter, and caches using that. This is
> nice because it can be done much more cheaply than running the JIT, and
> much more cheaply even than running the Builder. It also makes the
> parameterization of the Blitter explicit, which I like.
>
> This does sometimes create programs that are equivalent but have
> different keys, but that's not that common, and it's pretty harmless.
> E.g. today if the device colorType() is opaque or premul, we'll think
> those are different programs, but actually end up making the exact
> same calls to Builder. No big deal, and maybe even gives us a
> suggestion to do something when the destination is opaque to skip work.
> I've left that as a TODO followup.
>
> We really only need a small cache to get a good hit rate. Running all
> GMs in one process serially, we're now down to 22 calls to done() from
> >100K at head (and >500K yesterday). (Would be 13 if we treated opaque
> and premul the same.)
>
> There are two places I'd like to have used tryAcquire() on an SkSpinlock
> but the thread safety static analysis is wrong and prevents me. Left
> some TODOs.
>
> Change-Id: I83a365fc895720c76b56b0e5a78f4c673fcd9d64
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/232817
> Commit-Queue: Mike Klein <mtklein@google.com>
> Reviewed-by: Herb Derby <herb@google.com>
TBR=mtklein@google.com,herb@google.com
Change-Id: I9a32f24b79054f7174d82bb8e6aca2a9f65894e8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/233037
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
I18N-34
Bug: skia:9307
Change-Id: I6d6e777e4f60d266aa7bea97def482f398a7dbc1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/232122
Auto-Submit: Konstantin Pozin <kpozin@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Sergey Ulanov <sergeyu@chromium.org>
My first drafts put caching inside SkVM.cpp, which I rejected for
feeling a little too magic, and then in SkVMBuilder.cpp using a
fingerprint of the skvm::Builder to skip Builder::done().
This version makes an explicit Key structure holding all the parameters
that currently matter to the Blitter, and caches using that. This is
nice because it can be done much more cheaply than running the JIT, and
much more cheaply even than running the Builder. It also makes the
parameterization of the Blitter explicit, which I like.
This does sometimes create programs that are equivalent but have
different keys, but that's not that common, and it's pretty harmless.
E.g. today if the device colorType() is opaque or premul, we'll think
those are different programs, but actually end up making the exact
same calls to Builder. No big deal, and maybe even gives us a
suggestion to do something when the destination is opaque to skip work.
I've left that as a TODO followup.
We really only need a small cache to get a good hit rate. Running all
GMs in one process serially, we're now down to 22 calls to done() from
>100K at head (and >500K yesterday). (Would be 13 if we treated opaque
and premul the same.)
There are two places I'd like to have used tryAcquire() on an SkSpinlock
but the thread safety static analysis is wrong and prevents me. Left
some TODOs.
Change-Id: I83a365fc895720c76b56b0e5a78f4c673fcd9d64
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/232817
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Adds a GrTextureResolveManager class and plumbs it through calls to
generate the drawing manager's dependency DAG. This new class is
currently unimplemented, but it wraps GrDrawingManager and will
eventually give limited access to functionality for making new tasks
that regenerate mipmaps and/or resolve MSAA. We will use this object
to move mipmap generation up to the DAG/proxy level.
Bug: skia:
Change-Id: Ie1deef21e7ae579a0262f2eeb93d451f0740d823
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/232633
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
By funnelling the no-arg Program constructor through the main one, we're
actually JITting a small program that doesn't do anything but loop
today. Skipping that saves _a whole lot_ of pointless mmap, mprotect,
munmap, Assembler calls, etc.
Change-Id: I88b3589177dfd86978b030644759a28e1783b702
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/232818
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This consolidates some duplicate code across newRTOpList and
newTextureOpList.
Bug: skia:
Change-Id: I3a3c150e20e3db279de476307c5281668c3fdd9a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/232836
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
When run over all GMs, this cuts the number of programs
we build and JIT from 531,012 down to 141,930.
Draws the same, of course.
Change-Id: Ia804ded23496a2f534fb94d047547c9b644f3cfc
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/232776
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This adds an isFormatRenderable call that doesn't take a GrColorType
which will be used in future changes. Also renamed the one that
takes a GrColorType to be more explixit what its use is.
Bug: skia:6718
Change-Id: Ib5a11aacccc4d94d21bc39be05f116ec3b23a3e6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/232757
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
A fragment of a larger CL
Change-Id: I1063186a411da280761187ebe644460afbd67430
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/232756
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
2x faster than calling drawVertices as the impl.
Lots more to do in future CLs
- much of the time is spent in malloc, as we cons-up private shaders.
we *could* create a private shader and wack its data for each draw
(breaking the immutable contract, but that may be ok for a raster-only
internal-use shader...)
- also spend time building the pipeline for each draw, even though
all that has changed is a color payload (and the ctm). A custome
stage(s) that exposed its private data could be reused with new
data...
Bug: skia:
Change-Id: I0ff15155e37c0af7931abd34c0883701a47a048a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/203168
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Reed <reed@google.com>
Change-Id: I095a69b801123225e1bd49573701e5e1632430eb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/232516
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
GrLumaColorFilterEffect implements constantOutputForConstantInput() but
doesn't opt in for this optimization.
Change-Id: I9ba22a5e6da5974ba75610ad33d37bc467e45689
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/232399
Commit-Queue: Florin Malita <fmalita@chromium.org>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Auto-Submit: Florin Malita <fmalita@chromium.org>
Reviewed-by: Brian Salomon <bsalomon@google.com>
When a single channel texture is used for a YUV channel we will
interpret it as kGray_8. When a single channel texture is used
as an A channel we will interpret it as kAlpha_8.
Change-Id: I0a02b849d214f63369dedf09b78195a293adc78e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/232142
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
All clients that used the flag (google3, chrome) have been updated
Change-Id: I08062301a02a4270cda7e5765e6d21c8ac82b691
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/232025
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Mike Reed <reed@google.com>
Change-Id: I0cdeb89c3b1efe4d59c65a14cca40a7c4b562972
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/232023
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
Test: built and ran Android
Bug: b/138674291
Change-Id: I7ee7a2489749cde7c4f384002856ca2ea1bd00d7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/232018
Commit-Queue: Stan Iliev <stani@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Currently Vulkan does not have a second layer table for external IO
GrColorTypes since it doesn't need any extra meta data it for both
read and write it always uses the GrColorType of the surface.
Also removed a few switches in the GrVkCaps to use the new table.
Bug: skia:6718
Change-Id: Ib4df5862051a235df0c7c0acc0540a6b56dee516
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/232020
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
The dst should always be fTarget. Otherwise we need to rethink our
model of when to mark mipmaps, etc. as dirty.
Bug: skia:
Change-Id: Ie4e98374df40d825801494bf335b0a5a2c6f459f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/230916
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Bug: skia:9281
Change-Id: I189dbf652580805641f8c4b9a6587cf15a9049dd
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/231256
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
This is basically a no-op, just trimming a tiny bit of silly codegen.
Change-Id: I0c20a22f1c9fb6226f9121eb8232b85f156a7f05
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/232061
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This reverts commit c326aaf134.
Reason for revert: ANGLE D3D es2 bots
Original change's description:
> Increase specificity of GrColorType computed for YUV planes
>
> When a single channel texture is used for a YUV channel we will
> interpret it as kGray_8. When a single channel texture is used
> as an A channel we will interpret it as kAlpha_8.
>
> Change-Id: I746f8d761d7779266a4106311a93d651266bb422
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/232017
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Robert Phillips <robertphillips@google.com>
TBR=bsalomon@google.com,robertphillips@google.com
Change-Id: I57a00d65c6226822a501b231e103016a45943e5e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/232138
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Add vpblendvb, vpcmpeqd, and vpcmpgtd, to implement select and eq/lt/gt.
I want to think just a touch bit more about neq, lte, and gte.
This is enough to JIT everything SkVMBlitter creates today.
There are 24 possible argument orders to vpblendvb,
so I'm sure I've got them wrong somehow, even with the new test.
Change-Id: I357664b866d8258a2b5438d520f47542ad581c50
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/232060
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Nothing particularly tricky. Very much like store8,
but with one fewer shuffle.
This lets some of the 565 blitters JIT!
Change-Id: I853905bda30a0cda89f3fcb5fef1dfe62725063b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/232059
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
