This is my super lazy fix for the attached, completely unimportant
false-postive bug. I haven't even paused to consider whether
colorCount=1 makes sense here.
An alternative is to use sk_ieee_double_divide() here to say "divide by
zero is fine, man". But I kind of like this: wScale will hoist out of
the loop just fine, and it's nice to have the pos==nullptr checks near
each other.
PS3: yep, we can.
Bug: oss-fuzz:24242
Change-Id: I380ff2610405488cdaf475c34617bc9b4427ade9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/304019
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@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>
Bug: oss-fuzz:24246
Change-Id: Ib99a359b2f0c6ee55180734d6ae933b90e4f6ca8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303920
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: Brian Osman <brianosman@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
This also makes the effects deserialization available via compile flag.
Change-Id: Ib6692499a619205ac480a8823ce7de12c0a5a723
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303596
Reviewed-by: Nathaniel Nifong <nifong@google.com>
When we free a vk buffer cause of memory budget, we need to make sure the
buffer is unmapped before calling free on it. However, the old code was
calling unmap even on cpu backed vk buffers. The cpu data gets uploaded
during the unmap call via a transfer buffer. This puts us in a death spiril
of creating and trying to free resources due to budget issues.
This hopefully fixes the attached chromium bugs. I am not sure why the
allocator was eventually crashing but before the crash we ended up in this
craziness of creating and destroying buffers. Maybe we ended un OOMing and
messing with the allocator? Anyways getting rid of the spiril hopefully
gets rid of the crash.
Bug: chromium:1107173, chromium:1106889
Change-Id: I225738df092b4cf5f8b3c97123e06d82358c9b8b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303917
Auto-Submit: Greg Daniel <egdaniel@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
This test code is templated, but not really generic (it's only meant to
work with two specific classes) so it doesn't need to live in a header.
Change-Id: I38d4f2cc9637207eca678fc81ff35ebbd7e69fce
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303656
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
We have unit tests for over-aligned allocation requests (which I know
caught bad addresses on other platforms, but my guess is that wasm's
malloc just so happened to produce pointers at 16 byte boundaries when
they were run). And in the wild, we only would ever allocate things on 8
bytes anyways, so it'd never trigger then. This is mostly to ensure that
if were ever to request something at 16bytes on wasm, the block
allocator's address padding will kick in and do the right thing.
Change-Id: I4b9e3ae5775e453cbbe05bebe4dbe69742a51354
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303658
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Bug: skia:10477
Change-Id: I46a48185977a409225583aea58f5fd31cf306d4c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303266
Reviewed-by: Eric Boren <borenet@google.com>
Commit-Queue: Ravi Mistry <rmistry@google.com>
RGBA U16/F16 diffs both look pretty much good here.
There are a few F16 diffs to look at, but those are likely one-off diffs
in effect implementation (e.g. SkRasterPipeline clamping somewhere we've
since decided to not clamp in the new SkVM implementation).
Last thing TODO is JIT 64-bit loads and stores to get this all to JIT.
Change-Id: Iadc65c1fc13c32d67d7c7243312d4c90d921dbde
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303272
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Change-Id: Idf969d9f3bcf5522fcc5c66642a056617eb62daa
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303664
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@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>
This also brings indirect draw support to CanvasKit because Emscripten
will expose WEBGL_multi_draw through these extensions.
Bug: skia:10419
Change-Id: Icea3fedb846bb932e7d19f8f4a1e5646e25d4c2d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303263
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Jim Van Verth <jvanverth@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>
The next subclass I make will have a different description of the
glyphs position and bounds. Split the glyph info from the VertexData
and put it into its own class called GrGlyphVector.
Change-Id: Idaf9e914700832baf14bdb3bd1d8e8aeb8c63243
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303589
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Change-Id: I894658882da92cb221be8355c8b1c7590c09895f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303650
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This can be leveraged to build chains of test FPs in a controlled way.
At present, `inputFP` it is never set to anything other than null; as
such, all calls to TestCreate continue to set a null inputFP
(exactly as they do already).
Change-Id: I0d74f37a076ca338e44ff734816299beb1667c26
Bug: skia:10384
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/302668
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
When GrGLCaps::drawArraysBaseVertexIsBroken() is true, we have to stash
the vertex buffer away and defer binding until the draw call occurs. We
were forgetting to do this last-minute binding during onDrawIndirect.
Change-Id: I19a93cf2bd6d559e762e7ea1bca33a5e0fd4f03d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303584
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Sksg::Merge needs to preserve the fill type of the first path appended
in the stack.
Theoretically, one could append multiple paths with different fill types
using sksg::Merge, but in practice Skottie should never do that (append
mode with invertible shape only used for the very first mask in a stack).
TBR=
Change-Id: Ie9ac9187cc1c8baaae2bef439313a7700407f04a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303582
Reviewed-by: Florin Malita <fmalita@google.com>
Commit-Queue: Florin Malita <fmalita@google.com>
This will be leveraged in followup CLs.
Change-Id: Iccc6071867f0044fc3ab935fc18ac38dea0ebac2
Bug: skia:10384
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303585
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This is part of the effort to replace GrContext with the GrDirectContext/GrRecordingContext pair.
It also tries out, a bit, the context naming proposal (i.e., rContext and dContext).
Change-Id: Ib4d9881f820a7f8a8c525eba7448b1015526400c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303627
Reviewed-by: Adlai Holler <adlai@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This is part of a larger effort to clean up the SkImage API and require
users to provide the direct GPU context for manipulating GPU images.
Bug: skia:104662
Change-Id: Ic7fd675a6ec09f001266fd79efdf084368ab6cd5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303630
Commit-Queue: Adlai Holler <adlai@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Auto-Submit: Adlai Holler <adlai@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Helpful for bugs that require evolving global state over multiple
iterations, or bugs that don't repro 100% deterministically.
Change-Id: I4499a8783b00ccd079b79219cad2a4d45e467777
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303581
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
The SkMaskSubRun is just a temporary name while I pull out the
different subclasses.
Change-Id: I363742a98a0596ba3d282b918cc0492ab1e0e5d9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303357
Reviewed-by: Herb Derby <herb@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Herb Derby <herb@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>
Tessellation previously worked under the assumption that conservative
raster was always supported if we were using mixed samples, but this
is not the case in ANGLE. This CL checks for support before using
conservative raster and also disables the atlas if kAlpha8 does not
support MSAA.
Bug: skia:10419
Change-Id: I0bf429b3b7bb3f0e67c46552f08c689b7b816b57
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303480
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
