Previously, this test layered its paints by calling
`addColorFragmentProcessor` multiple times. We intend to remove support
for multiple color FPs on a GrPaint in the near future, so we use input
fragment processors instead to generate the same result.
Change-Id: I33e82ce0067183189e69b2af0fe0c228d1d60f14
Bug: skia:10217
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303479
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
The helper class allows us to regenerate a "random" fragment processor
with the same seed as many times as desired. This lets us check the
`compatibleWithCoverageAsAlpha` optimization without needing to clone
the input FP; instead, we can actually generate the FP under test three
times in a row, with the same random seed.
In a followup CL (http://review.skia.org/303479/) we will also leverage
this helper class to regenerate the FP under test with the same random
seed, but with a different input.
Change-Id: I1cd83082a949d555f7898970c8a1cc3002818286
Bug: skia:10384
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303657
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This adds load/store ops for 64-bit values, with two load64 instructions
returning the low and high 32-bits each, and store64 taking both.
These are implemented in the interpreter and tested but not yet JIT'd
or hooked up for loading and storing 64-bit PixelFormats. Hopefully
those two CLs to follow shortly.
Change-Id: I7e5fc3f0ee5a421adc9fb355d0b6b661f424b505
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303380
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Everything was pretty much already plumbed through using
SkRasterPipeline, with a few key connections made here.
This support is mostly useful for differentially debugging my CLs
stacked on top of it.
Change-Id: I9c2f2ea6cd8890c057890409f21c7698857c599a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303651
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Previously, the blocks owned by a GrBlockAllocator provided block-level
metadata that users could control to track within a block. For types
like GrTAllocator (and a collection coming down the pipe), they need
to store a total count of allocations.
Since GrBlockAllocator is max-aligned, having them hold on to a single
extra int adds 4 to 12 bytes of padding for 8 and 16byte aligned
platforms. But, the old Block size already has 4 bytes of extra padding
since it was 28 bytes packed. This had been allowed to be allocation
data, for requests that were 4-byte aligned or less.
In practice, I think it's better to use that space for allocator-level
metadata so that a total count, or other high-level data, can be
packed into the data already held by GrBlockAllocator. Now GrTAllocator
instances should be 8-16 bytes smaller on those same platforms. Also
no longer writing into the struct-padded nether-realm, which is probably
just a good thing on principle.
Also cleans up how GrTAllocator's push_back() and emplace_back() are
tested to make sure all options are clearly covered.
Change-Id: If1da29132f3ec8df7a4056fcd834f760eb4693f5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303267
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Change-Id: I5bf9470a3d7822ea1edee7abf693037322e5d4e6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303265
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Auto-Submit: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Change-Id: I00a00e62dfb2021a2c380ef4217c1acec1f07672
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303258
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
This is part of a larger effort to force SkImage users to specify
the direct context they want to use when manipulating GPU images.
Chrome CL 2299194 (landed) enables the staging flag.
bug: skia:10466
Change-Id: I959db57dd8dca5c2622eb5ffaa7de161c4d6d8f0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/302643
Commit-Queue: Brian Salomon <bsalomon@google.com>
Auto-Submit: Adlai Holler <adlai@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
This CL tries to remove all uses of GrContext - replacing them with
either GrDirectContext or GrRecordingContext. Preferring the recording
context wherever possible.
Change-Id: I61af94928aa37bc82ff9923acffd57586610f695
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/302904
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Adlai Holler <adlai@google.com>
Change-Id: I166755b3e385fcea919a6daad8cc8407fda8c27a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303016
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Aligning with SkSamplingMode.
Bug: skia:10344
Change-Id: Ie303c3ca1d664d4c23f779b84c9a661076bd74d4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303022
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@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>
The current serialization format for variations stores only the values
(without the axis names) and relies on the order of the axes for
deserialization. Even after this deficiency is corrected, it will still
be needed for legacy skps.
Add a real test which ensures variable font printing works correctly
in Chromium. The old test was essentially testing MakeFromFontData
against itself instead of creating a font with variations as a user
would.
Bug: chromium:1070089
Change-Id: Ia6eaac91b2ac58795b7ba61c2b52b2f22ef079bd
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/299457
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Herb Derby <herb@google.com>
This makes reset() a little easier to follow, and enables more complex
use cases on top of GrBlockAllocator down the road.
Change-Id: Id79d20e2b394248c997259d6d5b5494fc1456acc
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/302678
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
This allows the iterator type/boilerplate to be reused for any other
data collection that sits above GrBlockAllocator, as long as its a fixed
"type" with indices into a block.
Also adds reverse iteration (which is useful for stack-like use cases).
Change-Id: Id9a205e8fb396a8558e360439240fd20c92c9700
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/302665
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
This is just minor little stuff I've been meaning to do,
with essentially no impact anywhere.
- Add an easy-to-flip switch to disable the JIT.
- Stop checking so carefully whether we hasJIT()
in test_jit_and_interpreter(). This was helpful
for making progress but now just gets in the way.
Change-Id: I08065ba1f42700f9d7d63f8303af357ec5fe11ae
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/302944
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
With this change if a backend Gr*Gpu wants to using staging buffers
they just add a generic GrStagingBufferManager member object. This
object can be used to get slices of upload buffers. Then they just need
to implement the virtual for taking ownership of buffers during submit.
We rely on our GrResourceCache to handle caching and reuse of these
buffers.
This change allows us to remove all other virtuals on GrGpu around
managing staging buffers.
Change-Id: I5db9a3c52133978ea89d6c0de440f434fbf91a51
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/300226
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Stephen White <senorblanco@google.com>
This reverts commit a56da9ee92.
Reason for revert: UBSAN complains in Vulkan OOPRDDL mode
Original change's description:
> Add a direct context arg to makeColorTypeAndColorSpace
>
> This is part of a larger effort to de-power SkImage and force users to
> specify the GPU context for all new images.
>
> Staging flag landed in Chrome CL 2296632.
>
> Bug: skia:10466
> Change-Id: I6b7bbec10369f7d8ee884dd1bcc234d332c30a6c
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/302290
> Commit-Queue: Adlai Holler <adlai@google.com>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Reviewed-by: Robert Phillips <robertphillips@google.com>
TBR=bsalomon@google.com,robertphillips@google.com,adlai@google.com
Change-Id: Ide36bed6966d3d92ad6b8d05f897d22d287b40b1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:10466
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/302824
Reviewed-by: Adlai Holler <adlai@google.com>
Commit-Queue: Adlai Holler <adlai@google.com>
This is part of a larger effort to de-power SkImage and force users to
specify the GPU context for all new images.
Staging flag landed in Chrome CL 2296632.
Bug: skia:10466
Change-Id: I6b7bbec10369f7d8ee884dd1bcc234d332c30a6c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/302290
Commit-Queue: Adlai Holler <adlai@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
C++ algorithms have largely standardized on a [begin, end) half-open
range, as seen in standard library containers. SkTQSort now adheres to
this model, and takes vec.begin() and vec.end() as its inputs.
To avoid confusion between inclusive and half-open ranges inside the
implementation, internal helper functions now take "left" and "count"
arguments instead of "left"/"right" or "begin"/"end". This avoids any
ambiguity.
(Although performance was not the main goal, this CL appears to
slightly improve our sorting benchmark on my machine.)
Change-Id: I5e96b6730be96cf23d001ee0915c69764b2c024a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/302579
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
We now rely on GrTextureEffect and GrBicbicEffect
to determine if shader-based tiling is required.
GrTextureProducer is still responsible for noticing that
the proxy is approximate because GrTextureEffect doesn't
consider that in its basic Make() factory (as opposed to
MakeSubset()).
Change-Id: I8e1aeb9edbcfa73ea0bf80b5256ee1ca21fe9c81
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301985
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This simplifies things like ConstantOutputForConstantInput and
invokeChild. It also removes the need for child indices: generated
FPs now directly refer to their children by slot number.
Change-Id: I69bbb042d5d72d21b999256f969c467702d0774d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/302436
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Change-Id: If51be35205b40c4a22979a4b49b031126af1dde7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/302500
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
In order to stage the transition from GrContext to GrDirectContext, both
of them will have to have the factories for a while.
This CL also removes all internal uses of the old (GrContext) factories.
Change-Id: Ibe1edd0818ea23a0d54257c55f35f12526047ef3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/302263
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Adlai Holler <adlai@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
This reverts commit 70474c1cb0.
Reason for revert: bot build failure
Original change's description:
> Remove custom SkSort algorithms.
>
> SortBench shows that SkTQSort and SkTHeapSort are inferior to std::sort.
> The difference is small on randomized inputs, but quite significant for
> semi-ordered inputs (forward/backward/repeated). There doesn't seem to
> to be any compelling advantage to SkTQSort.
>
> Nanobench results: https://screenshot.googleplex.com/9JOLV1d6Z0u
>
> (These performance numbers are from an optimized build my local machine;
> it's possible that we might see different results on the test bots.)
>
> Change-Id: Iaf19563041547eae7de2953be249129108f093b1
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/302295
> Commit-Queue: John Stiles <johnstiles@google.com>
> Reviewed-by: Mike Klein <mtklein@google.com>
TBR=mtklein@google.com,brianosman@google.com,johnstiles@google.com
Change-Id: I1126dd4cda95716dac225ad32d5b0e5cf3f09421
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/302447
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
SortBench shows that SkTQSort and SkTHeapSort are inferior to std::sort.
The difference is small on randomized inputs, but quite significant for
semi-ordered inputs (forward/backward/repeated). There doesn't seem to
to be any compelling advantage to SkTQSort.
Nanobench results: https://screenshot.googleplex.com/9JOLV1d6Z0u
(These performance numbers are from an optimized build my local machine;
it's possible that we might see different results on the test bots.)
Change-Id: Iaf19563041547eae7de2953be249129108f093b1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/302295
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
ConstColorProcessor contained three separate InputModes with their own
unique behaviors, but every (non-test) call site simply hardcoded one of
the InputModes.
This change also allows the actual const-color processor to remove the
inputFP entirely; it is never sampled.
The GM slide has been split into three separate slides as well.
Change-Id: I2b77f4eab4d655f06e3704fb6fde8d4f8c70a075
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301987
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
This is part of a larger effort to force users to provide a context
when manipulating GPU images which may be shared, instead of having
images themselves retain powerful context pointers.
Chrome flag landed in Chrome CL 2292800
Bug: skia:10466
Change-Id: Ic530a2c5eb1f4399db899d243ea944760fdf2055
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/300707
Commit-Queue: Adlai Holler <adlai@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
While testing on Linux with a configuration like
skia_enable_fontmgr_custom_directory=false
skia_enable_fontmgr_custom_embedded=false
skia_enable_fontmgr_custom_empty=true
skia_enable_gpu=true
skia_use_fontconfig=false
skia_use_freetype=true
skia_use_system_freetype2=false
the default typeface will be an empty typeface with no glyphs. This of
course leads to many test failures, which is fine.
However, this also leads to crashes when testing GPU Ops since the Op
factories may return nullptr to indicate no-op but the callers of those
factories currently do not expect nullptr or handle it as a no-op.
Change the callers of Op factories to treat nullptr as no-op.
Change-Id: I9eb1dfca4a8a9066a9cfb4c902d1f52d07763667
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301586
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
This makes batch texture ops consistent with singleton texture ops, and
images drawn through a texture producer.
Bug: chromium:1102578
Change-Id: I490b20940ef6f1899396b786369271ce7130e8a9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301540
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Change-Id: I9fa9f8785f48e884cf296a638347003d1687e7c0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301536
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Auto-Submit: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Change-Id: Ice75d0caa7b4beb2d982be094d62b54e71b45045
Bug: chromium:1101491
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301456
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
The SkPDFDocument::fTagTree::fRoot is set at document creation time.
This root will initially always be discardable, since no annotations
have been made. As a result it does not make sense to assert on it being
non-discardable, since it should be possible to create a PDF which just
happens to have no annotations added to it.
Change-Id: I2fe336c872805b6937f7c8ea275c0cb4d3438682
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301383
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
We are replacing GrContext with the GrDirectContext/GrRecordingContext
pair. This starts making that change visible to clients (and weaning
Skia off of GrContext).
Change-Id: I00cc9bf208499984de855a1646229bd7557fc925
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/300706
Reviewed-by: Adlai Holler <adlai@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Bug: skia:10416
Change-Id: I0ca7535a0e6507e6b2a9f4682788826972c5f3b8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/300296
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This reverts commit c8b721b086.
Reason for revert: Looks like it's causing build failures around
MakeRenderTargetContext on the roll.
Original change's description:
> Make SkGpuDevice hold a GrRecordingContext
>
> This makes the code reflect what is actually going on. During DDL
> recording the SkGpuDevice only holds a recording context.
>
> This can't land until the following Chrome-side CL lands:
>
> https://chromium-review.googlesource.com/c/chromium/src/+/2277964 (Add GrContext.h include to skia renderer for upcoming Skia roll)
>
> Change-Id: I69cfa744226c315c25f68fc509b7b59ec38bbf31
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/299867
> Commit-Queue: Robert Phillips <robertphillips@google.com>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Reviewed-by: Adlai Holler <adlai@google.com>
TBR=bsalomon@google.com,robertphillips@google.com,adlai@google.com
Change-Id: I6a362daf7c40e36ed9f068c5b2d477c16a3f778e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/300853
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
This makes the code reflect what is actually going on. During DDL
recording the SkGpuDevice only holds a recording context.
This can't land until the following Chrome-side CL lands:
https://chromium-review.googlesource.com/c/chromium/src/+/2277964 (Add GrContext.h include to skia renderer for upcoming Skia roll)
Change-Id: I69cfa744226c315c25f68fc509b7b59ec38bbf31
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/299867
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Adlai Holler <adlai@google.com>
