Passing in a large buffer along with a source colour space that
used a CLUT would cause apply() to read freed heap memory, or
for smaller buffers read possibly re-used stack memory.
The code previously likely lucked out due to optimizations
removing most or all of the subsequent stack allocations.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2759
Change-Id: I39f357bce080c4d737a83dd019f0d1ccbc56f995
Reviewed-on: https://skia-review.googlesource.com/2759
Commit-Queue: Robert Aftias <raftias@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
Reason for revert:
Broke bots
Original issue's description:
> Explicit control in tools of ANGLE frontend and backend
>
> Update the ANGLE test GL context, GrContextFactory, and config parsing to allow explicit control of ANGLE front/backend.
>
> This will allow us to explicitly test ES2 vs ES3 interfaces to ANGLE as well as D3D9, D3D11, and OpenGL backends.
>
> Also makes the angle api types valid in all builds (but will just fail when SK_ANGLE=1 or not on windows for the d3d backends).
>
> BUG=skia:5804
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2381033002
>
> Committed: https://skia.googlesource.com/skia/+/50094fb489543655df026be4e4f99e09e57a1f49TBR=brianosman@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:5804
Review-Url: https://codereview.chromium.org/2384483003
Update the ANGLE test GL context, GrContextFactory, and config parsing to allow explicit control of ANGLE front/backend.
This will allow us to explicitly test ES2 vs ES3 interfaces to ANGLE as well as D3D9, D3D11, and OpenGL backends.
Also makes the angle api types valid in all builds (but will just fail when SK_ANGLE=1 or not on windows for the d3d backends).
BUG=skia:5804
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2381033002
NOTREECHECKS=true
NOTRY=true
NOPRESUBMIT=true
Review-Url: https://codereview.chromium.org/2381033002
This lets them pick up runtime CPU specializations. Here I've plugged in SSE4.1. This is still one of the N prelude CLs to full 8-at-a-time AVX.
I've moved the union of the stages used by SkRasterPipelineBench and SkRasterPipelineBlitter to SkOpts... they'll all be used by the blitter eventually. Picking up SSE4.1 specialization here (even still just 4 pixels at a time) is a significant speedup, especially to store_srgb(), so much that it's no longer really interesting to compare against the fused-but-default-instruction-set version in the bench. So that's gone now.
That left the SkRasterPipeline unit test as the only other user of the EasyFn simplified interface to SkRasterPipeline. So I converted that back down to the bare-metal interface, and EasyFn and its friends became SkRasterPipeline_opts.h exclusive abbreviations (now called Kernel_Sk4f). This isn't really unexpected: SkXfermode also wanted to build up its own little abstractions, and once you build your own abstraction, the value of an additional EasyFn-like layer plummets to negative.
For simplicity I've left the SkXfermode stages alone, except srcover() which was always part of the blitter. No particular reason except keeping the churn down while I hack. These _can_ be in SkOpts, but don't have to be until we go 8-at-a-time.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2752
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Change-Id: I3b476b18232a1598d8977e425be2150059ab71dc
Reviewed-on: https://skia-review.googlesource.com/2752
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
We used to step at a 4-pixel stride as long as possible, then run up to 3 times, one pixel at a time. Now replace those 1-at-a-time runs with a single tail stamp if there are 1-3 remaining pixels.
This style is simply more efficient: e.g. we'll blend and lerp once for 3 pixels instead of 3 times. This should make short blits significantly more efficient. It's also more future-oriented... AVX+ on Intel and SVE on ARM support masked loads and stores, so we can do the entire tail in one direct step.
This also makes it possible to re-arrange the code a bit to encapsulate each stage better. I think generally this code reads more clearly than the old code, but YMMV. I've arranged things so you write one function, but it's compiled into two specializations, one for tail=0 (Body) and one for tail>0 (Tail). It's pretty tidy.
For now I've just burned a register to pass around tail. It's 2 bits now, maybe soon 3 with AVX, and capped at 4 for even the craziest new toys, so there are plenty of places we can pack it if we want to get clever.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2717
Change-Id: I45852a3e5d4c5b5e9315302c46601aee0d32265f
Reviewed-on: https://skia-review.googlesource.com/2717
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Gradients (and other shaders) are going to end up serializing this
particular color space very frequently, so we want a shorthand way of
writing it out. I think it's also helpful to have a clearer way of
creating it (vs. NewNamed(kSRGB_Named)->makeLinearGamma()).
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2377763002
Review-Url: https://codereview.chromium.org/2377763002
I've even found the code that's making this happen, just don't know why.
I've added a test to assert that it's safe to assume malloc() is 8-byte aligned.
Test should compile this time.
CQ_INCLUDE_TRYBOTS=master.client.skia.android:Test-Android-Clang-NexusPlayer-CPU-Moorefield-x86-Release-GN_Android-Trybot
Change-Id: I48714b99670c20704adf4f7f216da0d60d7d9bcd
Reviewed-on: https://skia-review.googlesource.com/2662
Reviewed-on: https://skia-review.googlesource.com/2703
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This reverts commit If8a2898ab3a77571622eb125c97f676e029b902c.
Reason for revert:
../../../../../work/skia/tests/OverAlignedTest.cpp: In function 'void test_OverAligned(skiatest::Reporter*, sk_gpu_test::GrContextFactory*)':
../../../../../work/skia/tests/OverAlignedTest.cpp:19:33: error: invalid operands of types 'void*' and 'int' to binary 'operator&'
REPORTER_ASSERT(r, SkIsAlign8(p));
^
ninja: build stopped: subcommand failed.
Original issue's description:
> Focus -Wno-over-aligned to just 32-bit x86 Android.
>
> I've even found the code that's making this happen, just don't know why.
> I've added a test to assert that it's safe to assume malloc() is 8-byte aligned.
>
> BUG=skia:
>
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2662
>
> CQ_INCLUDE_TRYBOTS=master.client.skia.android:Test-Android-Clang-NexusPlayer-CPU-Moorefield-x86-Release-GN_Android-Trybot
>
TBR=mtklein@chromium.org,bungeman@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: Ic9b30ce980d8d5155528a6f2b4e1913e5fa95dc0
Reviewed-on: https://skia-review.googlesource.com/2702
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
I've even found the code that's making this happen, just don't know why.
I've added a test to assert that it's safe to assume malloc() is 8-byte aligned.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2662
CQ_INCLUDE_TRYBOTS=master.client.skia.android:Test-Android-Clang-NexusPlayer-CPU-Moorefield-x86-Release-GN_Android-Trybot
Change-Id: If8a2898ab3a77571622eb125c97f676e029b902c
Reviewed-on: https://skia-review.googlesource.com/2662
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Reason for revert:
Let's see if reverting this helps the roll.
Original issue's description:
> My take on SkAlign changes.
>
> Like the other change, it makes SkAlignN(x) macros work for pointers, and makes the macros themselves just syntax sugar for SkAlign<N>(x). We can still decide if we want to sed away the macros independently.
>
> This just does it in a somewhat less repetitive way, and adds some tests.
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2368293002
>
> No public API changes.
> TBR=reed@google.com
>
> Committed: https://skia.googlesource.com/skia/+/e1a5f4e292384046678edc5c1e360b3e13dc118cTBR=cblume@chromium.org,mtklein@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review-Url: https://codereview.chromium.org/2372083002
This cleans up 3 remaining sites using , that probably meant ;
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2605
Change-Id: I5e48bcd85d72a205d2b0c860461dab1ec793dd18
Reviewed-on: https://skia-review.googlesource.com/2605
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Like the other change, it makes SkAlignN(x) macros work for pointers, and makes the macros themselves just syntax sugar for SkAlign<N>(x). We can still decide if we want to sed away the macros independently.
This just does it in a somewhat less repetitive way, and adds some tests.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2368293002
No public API changes.
TBR=reed@google.com
Review-Url: https://codereview.chromium.org/2368293002
In one case the fuzzer was switching the picture's op code to an invalid value
In the other two the fuzzer was maxing out the number of points passed to drawPoints and the number of characters passed to drawTextRSXform. In these cases the validation would fail but still return a pointer into the data stream.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2593
Change-Id: Id6d4e6b7bcbae38ace7ad1d92ffcfa5c02f9fb61
Reviewed-on: https://skia-review.googlesource.com/2593
Reviewed-by: Mike Reed <reed@google.com>
properties (color space), bounds, and (optional) alphaType.
We were being pretty inconsistent before. Raster was honoring all
components of the info. GPU was using the supplied color type, but
propagating the source's color space. All call sites were saying N32.
What we want to do is propagate the original device's color space, and
pick a good format from that. Rather than force all the clients to
jump through hoops constructing an SkImageInfo that meets our criteria,
just have them supply the few bits we care about, and do everything else
internally.
This also lets us always use RGBA on GPU, but N32 on raster.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2349373004
Committed: https://skia.googlesource.com/skia/+/53c38087949252d27cde668368a3eeb59cc2eb00
Review-Url: https://codereview.chromium.org/2349373004
Reason for revert:
DM crash and/or TSAN failure
Original issue's description:
> Change SkSpecialImage::makeSurface and makeTightSurface to take output
> properties (color space), bounds, and (optional) alphaType.
>
> We were being pretty inconsistent before. Raster was honoring all
> components of the info. GPU was using the supplied color type, but
> propagating the source's color space. All call sites were saying N32.
>
> What we want to do is propagate the original device's color space, and
> pick a good format from that. Rather than force all the clients to
> jump through hoops constructing an SkImageInfo that meets our criteria,
> just have them supply the few bits we care about, and do everything else
> internally.
>
> This also lets us always use RGBA on GPU, but N32 on raster.
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2349373004
>
> Committed: https://skia.googlesource.com/skia/+/53c38087949252d27cde668368a3eeb59cc2eb00TBR=robertphillips@google.com,reed@google.com,bsalomon@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review-Url: https://codereview.chromium.org/2366723004
properties (color space), bounds, and (optional) alphaType.
We were being pretty inconsistent before. Raster was honoring all
components of the info. GPU was using the supplied color type, but
propagating the source's color space. All call sites were saying N32.
What we want to do is propagate the original device's color space, and
pick a good format from that. Rather than force all the clients to
jump through hoops constructing an SkImageInfo that meets our criteria,
just have them supply the few bits we care about, and do everything else
internally.
This also lets us always use RGBA on GPU, but N32 on raster.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2349373004
Review-Url: https://codereview.chromium.org/2349373004
Reason for revert:
fHeapIndex is not used in release, need to hide behind SK_DEBUG. Failing on Perf-Android-Clang-NVIDIA_Shield-GPU-TegraX1-arm64-Release-GN_Android_Vulkan.
Original issue's description:
> Some Vulkan memory fixes and cleanup
>
> * Switch back to not setting transfer_dst on all buffers
> * Add some missing unit tests
> * Add tracking of heap usage for debugging purposes
> * Fall back to non-device-local memory if device-local allocation fails
>
> BUG=skia:5031
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2356343003
>
> Committed: https://skia.googlesource.com/skia/+/c5850e9fdb62cc4ae5ed2b6af51aea92cac07455TBR=egdaniel@google.com,brianosman@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:5031
Review-Url: https://codereview.chromium.org/2358123004
For now, this is just the color space (of the original
requesting device). This is used when constructing
intermediate rendering surfaces, so that we ensure we
land in a surface that's similar/compatible to the
final consumer of the DAG's output.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2357273002
Review-Url: https://codereview.chromium.org/2357273002
