| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 5373609d90d8f84b75718b15f3522f9d2f4226cb.
Reason for revert: doesn't look like we'll need this.
Original change's description:
> add knob to turn off fancy SkJumper features
>
> This is a new public API for testing (layout tests).
>
> Change-Id: I10345231bad373c741b1e9656e546000538121b3
> Reviewed-on: https://skia-review.googlesource.com/17712
> Reviewed-by: Florin Malita <fmalita@chromium.org>
> Commit-Queue: Mike Klein <mtklein@chromium.org>
>
Change-Id: Ieed2576d7fc06528384b7476508610e0e29b894f
Reviewed-on: https://skia-review.googlesource.com/17719
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
|
|
|
|
|
|
|
|
|
| |
This is a new public API for testing (layout tests).
Change-Id: I10345231bad373c741b1e9656e546000538121b3
Reviewed-on: https://skia-review.googlesource.com/17712
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
|
|
|
|
|
|
|
|
|
|
| |
Using the float iota was just an expedient to write the stage...
this CL adds the U32 iota that dither really wants.
Change-Id: I7990b10afd0c5277186b6b8e730245d291bcef0c
Reviewed-on: https://skia-review.googlesource.com/17441
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
|
|
|
|
|
|
|
| |
Change-Id: I17ac13b9d1ea6765e2c1a2b53aa6975eab408856
Reviewed-on: https://skia-review.googlesource.com/16713
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I think we can dither generically as a pipeline stage.
I'm not married to where the dither happens, or the implementation,
which is mostly cribbed from
https://en.wikipedia.org/wiki/Ordered_dithering.
BUG=skia:3302,skia:6224
Change-Id: If7f6b22a523ca0b34cb03c0aa97b6734c34e0133
Reviewed-on: https://skia-review.googlesource.com/15161
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Herb Derby <herb@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For whatever reason, if I swap the condition in the if_then_else tests
from < to >= and swap the then/else values, I can use constants in
hsl_to_rgb. Still don't understand why, but I'll take it. I suspect it
has something to do with SSE, IEEE, and NaN, but I don't care enough to
speculate any more concretely.
This does that, removes C() and _f, updates some comments, and adds a
guard in build_stages.py to yell if it sees trouble like LCPI40_4...
This reminds me to try -ffast-math soon. I think that was mostly held
back by constants.
Change-Id: I3f8a37a4d4642f77422ce3261b750061e9e604a3
Reviewed-on: https://skia-review.googlesource.com/14942
Reviewed-by: Herb Derby <herb@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Looks like the color-space images have this well tested (even without
lab_to_xyz) and the diffs look like rounding/FMA.
The old plan to keep loads and stores outside callback was:
1) awkward, with too many pointers and pointers to pointers to track
2) misguided... load and store stages march ahead by x,
working at ptr+0, ptr+8, ptr+16, etc. while callback
always wants to be working at the same spot in the buffer.
I spent a frustrating day in lldb to understood 2). :/
So now the stage always store4's its pixels to a buffer in the context
before the callback, and when the callback returns it load4's them back
from a pointer in the context, defaulting to that same buffer.
Instead of passing a void* into the callback, we pass the context
itself. This lets us subclass the context and add our own data...
C-compatible object-oriented programming.
Change-Id: I7a03439b3abd2efb000a6973631a9336452e9a43
Reviewed-on: https://skia-review.googlesource.com/13985
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've tried a couple of ideas for approx_powf():
1) accumulate integer powers of x, then 4th roots, then 16th roots
2) continue 1) all the way to 256th roots
3) decompose into pow2 and log2, exploiting IEEE float layout
4) slightly tune constants used in 3)
5) accumulate integer powers of x, then 3+4) with different tuning
6) follow a source online, basically 5 with finesse
7) a new source quoting and improving on the method in 6).
7) seems perfect, enough that maybe we can explore improving its speed
at cost of precision. Might be nice to get rid of those divides. If we
allow a small tolerance (2-5) in our tests, we could use the very simple
fast forms from 3) (e.g. PS 5). I wish I had some images to look at!
Anything involving roots seems to be subverted by poor rsqrt precision.
This change of course affects the pipelines created by the tests for
exponential and full parametric gamma curves. What's less obvious is
that it also means SkJumper can now for the first time run the pipeline
created by the mixed gamma curves test. This means we now need to relax
our tolerance for the table-based channel, just like we did when
implementing table_{r,g,b,a}.
This took me an embarassingly long time to figure out. *face palm*
Change-Id: I451ee3c970a0a4a4e285f8aa8f6ef709a654d247
Reviewed-on: https://skia-review.googlesource.com/13656
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Matt Sarett <msarett@google.com>
Reviewed-by: Herb Derby <herb@google.com>
|
|
|
|
|
|
|
|
|
|
|
| |
In testing, it didn't really seem like we're getting anything out of
doing an interpolated lookup, so this just does a single rounded lookup.
Change-Id: If85ba68675945b442076519dd7f1bf7540d1628d
Reviewed-on: https://skia-review.googlesource.com/13646
Commit-Queue: Matt Sarett <msarett@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Matt Sarett <msarett@google.com>
|
|
|
|
|
|
|
| |
Change-Id: I738da1dac2ef5b74ef34cca14938c0b6cce2fe16
Reviewed-on: https://skia-review.googlesource.com/13596
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This lets us temporarily escape to piece of code outside
SkRasterPipeline. We should be able to use this to replace
- parametric_{r,g,b,a}
- table_{r,g,b,a}
- color_lookup_table
- shader_adapter*
* We want to obsolete shader_adapter for other reasons anyway,
but we _could_ replace it with this if we want to.
Change-Id: I42b657b3c19c679796ed1876856cae0c8471307e
Reviewed-on: https://skia-review.googlesource.com/12102
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Herb Derby <herb@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This splits SkImageShaderContext into three parts:
- SkJumper_GatherCtx: always, already done
- SkJumper_SamplerCtx: when bilinear or bicubic
- MiscCtx: other little bits (the matrix, paint color, tiling limits)
Thanks for the snazzy allocator that allows this Herb!
Both SkJumper and SkRasterPipeline_opts.h should be speaking all the
same types now.
I've copied the comments about bilinear/bicubic to SkJumper with little
typo fixes and clarifications.
Change-Id: I4ba7b7c02feba3f65f5292169a22c060e34933c6
Reviewed-on: https://skia-review.googlesource.com/13269
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
| |
SkJumper_GatherCtx is a prefix of SkImageShaderContext, so
this is a no-op. It helps to keep things straight, and I
do want to split apart the GatherCtx from a new SamplingCtx.
Change-Id: I9c5f436b096624c2809e1f810e9bcd6c6b00b883
Reviewed-on: https://skia-review.googlesource.com/13264
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
|
|
|
|
|
|
|
| |
Change-Id: I70bd64d114a2460534bcb51d356e13d9bc3b8603
Reviewed-on: https://skia-review.googlesource.com/11491
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This doesn't change any of the generated .S files, but it does cut a few
misc. sections from the intermediate .o files. It's nice to get those
sections out of the way, and one day we might be able to find ways to
cut everything but .text... that'd allow us to switch the supicious
section sniffing code from a blacklist (no .const, no .literal, etc.) to
a more foolproof whitelist (.text or bust).
The remaining sections are only in ELF objects (aarch64.o, vfp4.o):
.comment (notes the version of Clang/LLVM that compiled it)
.note.GNU-stack (we manually add this back in build_stages.py)
and vfp4.o has two more sections that I don't understand yet:
.ARM.exidx (I'd have thought -fno-unwind-tables would cut this)
.ARM.attributes
While doing this, I've tried to make the ARM flags a bit more compact.
Change-Id: I30ef6acb2a917ec938c5358c3f970fe04b6d7afa
Reviewed-on: https://skia-review.googlesource.com/11485
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We don't _really_ need the Android NDK. We just need <arm_neon.h>
(which comes from Clang, not the NDK) and a smattering of <stdint.h>
([u]intN_t), <string.h> (memcpy) and <stddef.h> (size_t).
The idea here is solely to make it easier to run build_stages.py.
If this becomes a pain to maintain, I'm happy to go back to the NDK.
Change-Id: Ic6bb287646b6160ac42ac6e4d5290a66a7e92425
Reviewed-on: https://skia-review.googlesource.com/10980
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Generalize section types to avoid, adding another type (.rodata).
I've kept K for iota only. Maybe one day...
Change-Id: Ie5678a2ea00fefe550bc0e6dcab32f98c31d3fae
Reviewed-on: https://skia-review.googlesource.com/9403
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Herb Derby <herb@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Nothing too interesting here.
- 4x5 matrix is the same as 2x3 and 3x4, but bigger.
- luminance to alpha is pretty boring indeed.
Change-Id: I24893df15d1e22cbb500d946e1bbb58aa1522c8c
Reviewed-on: https://skia-review.googlesource.com/9385
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
|
|
|
|
|
|
|
| |
Change-Id: Icbd41e3dde9b39a61ccbe8e7622334ae53e5212a
Reviewed-on: https://skia-review.googlesource.com/8922
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The multiply by 0x77800000 is quite slow when the input is denormalized.
We don't mind flushing those values (in the range of 1e-5) to zero.
Implement portable load_f16() / store_f16() too.
Change-Id: I125cff1c79ca71d9abe22ac7877136d86707cb56
Reviewed-on: https://skia-review.googlesource.com/8467
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
|
|
Change-Id: If9f73e712e429564fef58ccb838c212ec8d2e68c
Reviewed-on: https://skia-review.googlesource.com/8525
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Herb Derby <herb@google.com>
|