| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
| |
The storage cost is the same, so might as well do this when building the pipeline instead of when running it. This also avoids the awkward cvtsi2ss instruction that screws with register renaming.
CQ_INCLUDE_TRYBOTS=skia.primary:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD
Change-Id: I1c7d5bad558870256a31e3da969eee5d80fb93a8
Reviewed-on: https://skia-review.googlesource.com/5782
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- explicitly separate bilinear_ stages in x and y too
BUG=skia:
CQ_INCLUDE_TRYBOTS=skia.primary:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD
Change-Id: Ib7b4f9d26ea6abe9171068e92424479d811ee606
Reviewed-on: https://skia-review.googlesource.com/5636
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) rename to bilerp_xy, for x,y in {n[egative], p[ositive};
2) pull out a save_xy stage to save off the original x,y;
3) also calculate the fractional x,y fx,fy once instead of 4 times.
1) is a pure refactor;
2) adds a stage but otherwise is nothing different;
3) changes images a little bit (fractional parts can vary a bit around powers of two).
This extends naturally to naive bicubic using 16 bicubic_xy stages.
CQ_INCLUDE_TRYBOTS=skia.primary:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD
Change-Id: I666de5c21e978abb4feb6e3225e5b5920ba6c5b9
Reviewed-on: https://skia-review.googlesource.com/5550
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Herb Derby <herb@google.com>
|
|
|
|
|
|
|
| |
Change-Id: I4ed750932cd6c768e21ca9f4a9e7f5f2408cfa4d
Reviewed-on: https://skia-review.googlesource.com/5323
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Most of this is plumbing through the full paint to shaders instead of just the filter quality.
CQ_INCLUDE_TRYBOTS=skia.primary:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD
Change-Id: I6afde07566afa3a4391c24dca7017a9a4f5ec700
Reviewed-on: https://skia-review.googlesource.com/5317
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Reed <reed@google.com>
|
|
|
|
|
|
|
|
|
| |
CQ_INCLUDE_TRYBOTS=skia.primary:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD
Change-Id: Ia7a133f515e29e16700aabc0633c77a703425f41
Reviewed-on: https://skia-review.googlesource.com/5239
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By stashing the scales in the context (i.e. on the stack), we can free up enough registers to really simplify how the bitmap sample stages interact.
Nearest neighbor is straightforward now: just call the appropriate gather_ function, and you're done. The source pixels end up in the source registers. If they're sRGB encoded, follow up with from_srgb_s
To bilerp, we bracket those 1 or 2 gather+from_srgb_s stages with a stage setting up each corner (x += dx, y += dy, save off scale) and a stage that accumulates into the d-registers (load saved scale, dr += scale * r, etc.). When all the samples are accumulated, copy the d-registers into the s-registers.
from_srgb_d and to_srgb are lightly sketched here and will be used in the next CL, where I apply this same factoring to non-bitmap loads and stores. This is a little tricky, because we don't actually have a float->float to_srgb yet.
CQ_INCLUDE_TRYBOTS=skia.primary:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD
Change-Id: I272a1f278f0ea1b29a2f07ac225f753faa8dae81
Reviewed-on: https://skia-review.googlesource.com/5271
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
|
|
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=5107
Change-Id: I5c30105501cbdb57896d9ec35737494eabd5998b
Reviewed-on: https://skia-review.googlesource.com/5107
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
|