Change-Id: I238d29ba0250224fa593845ae65192653f58faff
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528156
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Adding double-parens around an `if ((false))` squelches the warning.
In other cases, you can squelch the warning by assigning the
always-constant(-on-this-machine) check into a constexpr bool.
Change-Id: I5a344fb45779c5bd2865edb3cffaf839ba9a5d85
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/504597
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
The previous CLs have removed the last significant differences between
SkSL::String and std::string. This CL removes SkSL::String entirely and
replaces it with std::string throughout the code.
Apologies for the very long CL, but I have done my best to make it as
simple and reviewable as possible. The vast majority of changes are
simple replacement of `SkSL::String` with `std::string`. In the rare
spots where code is moved from one place to another, it is logically
unchanged.
Change-Id: I39563d2db45da229f17f4504dfd63e00bde7a96e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/503339
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Our SkVM code generator will always convert `pow(x, y)` into an
`approx_powf` call. However, in many cases, `x` or `y` might boil down
to an immediate value, and for some immediates, we can reduce the
operation into something much simpler:
- `pow(1, y)` is always 1
- `pow(2, y)` can be converted to `approx_pow2(y)`
- `pow(x, 0.5)` can be converted into `sqrt(x)`.
- `pow(x, 1)` can be converted to `x`
- `pow(x, 2)` can be converted to `x * x`
We could go further if there is a need, e.g. `pow(x, 4)` can become
`a = x * x; return a * a`, but these seemed like the best places to
start.
Change-Id: I02b9d4d3f5067581ebad5e53b2d1d7befa308300
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/502308
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
The skvm implementation of pow2 uses a clever bit-twiddling trick to
generate a floating-point value that can be cast to integer, then bit-
punned to float, to generate its result. However, the bit trick fails
for large inputs, and the bit-punning step generates a nonsense result.
This is now fixed by using a well-positioned clamp.
Change-Id: I55143a98324f5f518d0875149a0b6ce6d734ded0
Bug: skia:12847
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/497283
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Change-Id: Ibff6f08e569b5365732404a56fc3b9bf7c2fa1f9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/487377
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Simplified - "no static instructions"
Added to skslc with .cpp -> .html
Change-Id: I0b56ea0480f868ca4182acb7a23c03acf7f57519
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473659
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Julia Lavrova <jlavrova@google.com>
This CL adds the trace op and tests the builder commands, but it is not
yet hooked up to the SkVM code generator or debugger.
Change-Id: Iaa64293dfd0973e299eb480cb2b43672b0886c32
Bug: skia:12741
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/484439
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This reverts commit 062652067b.
Reason for revert: design change removes need for this op
Original change's description:
> Add SkVM op `trace_done` to indicate completion of debug tracing.
>
> This op can be used to invoke a callback function and dump the log to
> disk when it is ready. SkRuntimeEffect doesn't have any other viable
> mechanisms for detecting that a paint has completed, AFAIK. We can
> wait for ~SkRTShader to occur, but there's no guarantee that this will
> happen quickly, and the SkPaint with the SkRTShader shader can be reused
> over and over again.
>
> Unlike other trace ops, this only needs a trace mask, not an execution
> mask (we are unconditionally done at the end of main).
>
> Change-Id: I6f7ee41f2005b65940d36dee892279d4f245509f
> Bug: skia:12708
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/479876
> Auto-Submit: John Stiles <johnstiles@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
Bug: skia:12708
Change-Id: Ic4c4f5dd72541195f07ca32035267a20a82536e7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/481577
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This op can be used to invoke a callback function and dump the log to
disk when it is ready. SkRuntimeEffect doesn't have any other viable
mechanisms for detecting that a paint has completed, AFAIK. We can
wait for ~SkRTShader to occur, but there's no guarantee that this will
happen quickly, and the SkPaint with the SkRTShader shader can be reused
over and over again.
Unlike other trace ops, this only needs a trace mask, not an execution
mask (we are unconditionally done at the end of main).
Change-Id: I6f7ee41f2005b65940d36dee892279d4f245509f
Bug: skia:12708
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/479876
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
I ran into a snag while trying to hook up SkRuntimeEffect with debug
tracing. Runtime effects only have access to a skvm::Builder, and are
never exposed to the full skvm::Program. SkVMBlitter is responsible for
assembling the full skvm::Program, but is oblivious to runtime effects
and nested skvm sub-programs. Additionally, multiple runtime effects can
(and often do) coexist within a paint.
This CL changes how debug traces are enabled. skvm::Program no longer
has a `attachDebugTrace` method. Instead, this method lives on the
skvm::Builder. Calling `attachDebugTrace` generates a "trace-hook ID"
(which is actually an index into a vector of TraceHook pointers).
Every trace opcode now includes this trace hook ID. When the Builder
assembles a final Program, it copies the TraceHooks into the Program.
The skvm interpreter uses the trace hook ID on the op to dispatch a
trace command to its associated TraceHook.
From a user perspective, this doesn't change very much, but it does
mean that the SkVM Code Generator now supplies a TraceHook for us
(since it adds trace ops to the Builder and needs to know the proper
trace-hook ID).
Change-Id: I8bd5fea24f477f81470fae8ba41be45f76949407
Bug: skia:12708
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/479597
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Previously, the trace opcodes took a single mask argument, which was
computed as `execution mask & trace mask`. This led to extra bit_ands in
the output, as this value would be need to be recalculated every time
the execution mask changed.
To reduce this cost on program size, the trace ops now take two mask
arguments and require that both must be true. We have four register
slots at our disposal in an Op, which is more than we need, so this
doesn't really cost us anything.
(As an extra minor optimization, if one of the masks is "always-on", we
optimize it away. This avoids burning a register just to hold a ~0
immediate value.)
Change-Id: I9eb71292a1983e71b03c7ac842534beb3d6bbf17
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/478456
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Reusing the same opcode for enter and exit didn't have any real upside,
and forced us to deal with a fake immediate-value.
Change-Id: I35cab4d196f55b6f5e3040074c731b298720d62b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/477157
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This provides a callback mechanism for the interpreter when a trace
opcode is encountered. The callbacks are only invoked when the trace
mask is enabled.
Change-Id: I55db22e18106ae09e4ab0a503533d830282c772c
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473139
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This will be used to populate a trace buffer for the SkSL debugger.
See http://go/sksl-tracing for details and rationale.
Change-Id: I4c218c65ff01c339cf460e97e41566860a694720
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/468436
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
The code was original target for LLVM 10. I have updated it
to use LLVM 14. This does not fully complete the LLVM code because
there are still missing ops: array32, from_fp16, to_fp16,
load64, store64, load128, store128.
args.gn:
extra_cflags = [
"-DSKVM_LLVM",
"-isystem",
"../llvm-project/include",
]
extra_ldflags = [
"-L../llvm-project/lib",
"-lLLVM",
]
Running:
env DYLD_LIBRARY_PATH=/Users/herb/bin/llvm/lib ./out/SkVM-LLVM/dm
Change-Id: I79e3d3d62b29ed8bdad22890d4db5bc160ba4bf6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/460316
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Herb Derby <herb@google.com>
This is a reland of ea17e2499d
Original change's description:
> Reland "uniform Ptr (UPtr) is a sub class of Ptr"
>
> This is a reland of cef047a490
>
> Fix strides in SkVMTest to be the right size.
>
> Original change's description:
> > uniform Ptr (UPtr) is a sub class of Ptr
> >
> > A pointer for a Uniform (UPtr) is a sub type of a Ptr. Everywhere you
> > can use a Ptr a UPtr will work, but you can't use Ptr where you need
> > a UPtr. All the UPtr instructions uniformF, gather32, etc are expected
> > to be hoisted and therefore loaded only once. While the varyings
> > instructions like load32, etc. are expected to remain in the body
> > of the loop, and be evaluated each time through the loop.
> >
> > Change-Id: I4fe6458c2a4614872ed67cda1e81b05ea8a9e69e
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/436297
> > Commit-Queue: Herb Derby <herb@google.com>
> > Reviewed-by: Brian Osman <brianosman@google.com>
>
> Change-Id: I858fa1224452ec801b6186fede353849edc895b5
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/436564
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Herb Derby <herb@google.com>
Change-Id: I774e710724c99a41d0d160e88a2b723f66e03861
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/436821
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
This reverts commit ea17e2499d.
Reason for revert: blocking the android roll on a build failure
Original change's description:
> Reland "uniform Ptr (UPtr) is a sub class of Ptr"
>
> This is a reland of cef047a490
>
> Fix strides in SkVMTest to be the right size.
>
> Original change's description:
> > uniform Ptr (UPtr) is a sub class of Ptr
> >
> > A pointer for a Uniform (UPtr) is a sub type of a Ptr. Everywhere you
> > can use a Ptr a UPtr will work, but you can't use Ptr where you need
> > a UPtr. All the UPtr instructions uniformF, gather32, etc are expected
> > to be hoisted and therefore loaded only once. While the varyings
> > instructions like load32, etc. are expected to remain in the body
> > of the loop, and be evaluated each time through the loop.
> >
> > Change-Id: I4fe6458c2a4614872ed67cda1e81b05ea8a9e69e
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/436297
> > Commit-Queue: Herb Derby <herb@google.com>
> > Reviewed-by: Brian Osman <brianosman@google.com>
>
> Change-Id: I858fa1224452ec801b6186fede353849edc895b5
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/436564
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Herb Derby <herb@google.com>
TBR=herb@google.com,brianosman@google.com,skcq-be@skia-corp.google.com.iam.gserviceaccount.com
Change-Id: I0ffc93a04f5329838d422ad9e42aba09b9ba0064
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/436639
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Derek Sollenberger <djsollen@google.com>
This is a reland of cef047a490
Fix strides in SkVMTest to be the right size.
Original change's description:
> uniform Ptr (UPtr) is a sub class of Ptr
>
> A pointer for a Uniform (UPtr) is a sub type of a Ptr. Everywhere you
> can use a Ptr a UPtr will work, but you can't use Ptr where you need
> a UPtr. All the UPtr instructions uniformF, gather32, etc are expected
> to be hoisted and therefore loaded only once. While the varyings
> instructions like load32, etc. are expected to remain in the body
> of the loop, and be evaluated each time through the loop.
>
> Change-Id: I4fe6458c2a4614872ed67cda1e81b05ea8a9e69e
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/436297
> Commit-Queue: Herb Derby <herb@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
Change-Id: I858fa1224452ec801b6186fede353849edc895b5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/436564
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Herb Derby <herb@google.com>
This reverts commit cef047a490.
Reason for revert: DM test failures on some Windows/Linux devices
Original change's description:
> uniform Ptr (UPtr) is a sub class of Ptr
>
> A pointer for a Uniform (UPtr) is a sub type of a Ptr. Everywhere you
> can use a Ptr a UPtr will work, but you can't use Ptr where you need
> a UPtr. All the UPtr instructions uniformF, gather32, etc are expected
> to be hoisted and therefore loaded only once. While the varyings
> instructions like load32, etc. are expected to remain in the body
> of the loop, and be evaluated each time through the loop.
>
> Change-Id: I4fe6458c2a4614872ed67cda1e81b05ea8a9e69e
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/436297
> Commit-Queue: Herb Derby <herb@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
TBR=herb@google.com,brianosman@google.com,skcq-be@skia-corp.google.com.iam.gserviceaccount.com
Change-Id: I785973be1493643e7d5a3da482bc4ab07d186865
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/436559
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Derek Sollenberger <djsollen@google.com>
A pointer for a Uniform (UPtr) is a sub type of a Ptr. Everywhere you
can use a Ptr a UPtr will work, but you can't use Ptr where you need
a UPtr. All the UPtr instructions uniformF, gather32, etc are expected
to be hoisted and therefore loaded only once. While the varyings
instructions like load32, etc. are expected to remain in the body
of the loop, and be evaluated each time through the loop.
Change-Id: I4fe6458c2a4614872ed67cda1e81b05ea8a9e69e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/436297
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
If we manage to fix all the existing cases of variable shadowing, we
could enable -Wshadow.
Change-Id: I169ff3bac8517869132297c8e98bd9bd4248a349
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/436100
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Note: I have changed from using a byte offset for index to
an ordinary array index at the builder interface, but the
builder converts this to a byte offset for the instruction.
This makes the API easier to use.
I've added pushArray, and pushArrayF to the Uniforms, and
convenience methods on the builder to take Uniforms.
I've expanded the tests to use the new API.
Change-Id: Id538e826a96d4d242ae6482acc711d84c9041239
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/432036
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Forgot to load the pointer to the array in the arm64 case.
This is a reland of fe2506f3ca
Bug=skia:11822
Original change's description:
> Reland "add op array32 for indirect uniform access"
>
> This is a reland of ac2d053ccf
>
> The original CL was reverted because of a bug in the hash
> function.
>
> Bug=skia:11822
>
> Original change's description:
> > add op array32 for indirect uniform access
> >
> > Change-Id: I6249594a2348c7b24e4f057cce2f4e8a6a2c4409
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/431676
> > Reviewed-by: Brian Osman <brianosman@google.com>
> > Commit-Queue: Herb Derby <herb@google.com>
>
> Change-Id: I94604f5589c72d342c39cad44540d810ed7f31a1
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/432797
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Herb Derby <herb@google.com>
Change-Id: I185fc9554dcb6aa7ce367814ce2c69603074c434
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/433356
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Herb Derby <herb@google.com>
This reverts commit fe2506f3ca.
Reason for revert: Breaks unit test on M1 mac
Original change's description:
> Reland "add op array32 for indirect uniform access"
>
> This is a reland of ac2d053ccf
>
> The original CL was reverted because of a bug in the hash
> function.
>
> Bug=skia:11822
>
> Original change's description:
> > add op array32 for indirect uniform access
> >
> > Change-Id: I6249594a2348c7b24e4f057cce2f4e8a6a2c4409
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/431676
> > Reviewed-by: Brian Osman <brianosman@google.com>
> > Commit-Queue: Herb Derby <herb@google.com>
>
> Change-Id: I94604f5589c72d342c39cad44540d810ed7f31a1
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/432797
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Herb Derby <herb@google.com>
TBR=herb@google.com,brianosman@google.com,skcq-be@skia-corp.google.com.iam.gserviceaccount.com
Change-Id: I3dccc04dc5a867bb45a99044991056b22f5b6fe3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/433278
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Herb Derby <herb@google.com>
This is a reland of ac2d053ccf
The original CL was reverted because of a bug in the hash
function.
Bug=skia:11822
Original change's description:
> add op array32 for indirect uniform access
>
> Change-Id: I6249594a2348c7b24e4f057cce2f4e8a6a2c4409
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/431676
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Herb Derby <herb@google.com>
Change-Id: I94604f5589c72d342c39cad44540d810ed7f31a1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/432797
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Herb Derby <herb@google.com>
This reverts commit ac2d053ccf.
Reason for revert: This has somehow impacted a bunch of the CPU SkSL tests: https://gold.skia.org/search?blame=ac2d053ccfe80775b8144c069bf1f8660a5e8f9a&corpus=gm
I didn't notice if the hash and/or instruction comparison functions were updated to accommodate the extra data. Might be relevant?
Original change's description:
> add op array32 for indirect uniform access
>
> Change-Id: I6249594a2348c7b24e4f057cce2f4e8a6a2c4409
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/431676
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Herb Derby <herb@google.com>
TBR=herb@google.com,brianosman@google.com
Change-Id: Id5fc865b265d4c61a8d4fc853a6a0ecf7c2fb066
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/432376
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Change-Id: I6249594a2348c7b24e4f057cce2f4e8a6a2c4409
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/431676
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Herb Derby <herb@google.com>
This is just like mul(F32,F32) but optimizes 0*x == 0.
Use it in SkSLVMGenerator; sksl already applies this optimization.
PS2 has a sneaky version using % as a fast_mul() operator, and
PS3 has a sneakier version using ** instead.
We could of course write this all out using fast_mul() the long way,
but I found that quickly became difficult to read.
Change-Id: Iae35ce54411abc00e7729e178eb6a10f151a5304
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/368838
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
We can of course use allow_jit to test with and without JIT!
This testing was the only reason Program::dropJIT() was public. Given
how tricky its implementation is, I'd rather keep it a private detail
than exposed API, in case one day we find need to make it impossible.
Change-Id: Ifa256355309d9baf1bae506d75951381dce9b53c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/367896
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
We have a global flag controlling whether skvm::Programs JIT,
and this adds a per-Program flag to skvm::Builder::done().
Use it for single-color color filtering, and add a unit test.
Change-Id: I3a87761c8c6b818111d03c97b31f8b30d9f2c194
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/367856
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
store() returns a success bool only because it can, because it wasn't
going to return any sort of skvm::Value anyway. But it should never
fail given a well-formed skvm::PixelFormat, e.g. one from
SkColorType_to_PixelFormat. So move the "error handling" inside, really
just asserting/assuming it doesn't fail.
And similarly, skvm::SkColorType_to_PixelFormat() can no longer fail, so
have it return the skvm::PixelFormat directly instead of the bool I used
to stage things back when building this out.
Change-Id: I6dc3b6da32cdaaef377fe59b8c94846e902841ee
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/367796
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
These have a kind of neat way of encoding the lane index, using the Q
bit to pick the lower or upper 64 bits of the register, then the S bit
to pick the 32-bit lane within those 64 bits. Usually Q=1 distinguishes
a 128-bit op from a Q=0 64-bit op, so its repurposing here is at first
surprising, but actually very fitting.
I'd eventually like load64/128 to use these like this:
Reg tmp0 = alloc_tmp(2),
tmp1 = (Reg)(tmp0+1);
if (scalar) { a->ld24s(tmp0, arg[immA], 0); }
else { a->ld24s(tmp0, arg[immA] ); }
mark_tmp_as_dst(tmp0, tmp1);
where the mechanism to track up to four registers per value and
implement mark_tmp_as_dst(...) for more than one argument is what I'm
still working on.
Change-Id: I944e571de19f65d41f462406ce35f0f2a35bb381
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/360700
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
store64 and store128 will use the st?.4s instructions,
and load64/load128 the ld?.4s. The tricky bit for both
of course is that they load and store more than a single
register, and that those registers need to be adjacent.
Change-Id: I613d06cbcc6e00bfc16b1a2c88412dbbbb1c55ed
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/356344
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This makes almost all existing code read more clearly.
Change-Id: I314331d9aa2ecb4664557efc7972e1a820afc250
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/352085
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
We've been assuming that all Ops with the same arguments produce the
same value and deduplicating them, which results in a simple common
subexpression eliminator.
But we can't soundly dedup two identical loads with a store between;
that store could change the memory those loads read, producing different
values, as demonstrated by the first new unit test.
Then, by similar reasoning, it may first seem fine to deduplicate
stores, e.g.
store32 arg(0), v1
store32 arg(0), v1
That second store certainly does look redundant. But if we slot a
different store between, it's no longer redundant:
store32 arg(0), v1
store32 arg(0), v2
store32 arg(0), v1
If we dedup those two v1 stores, we'll skip the second and be left with
v2 in our buffer instead of v1. This is the second new unit test.
Now, uniform32 and gather ops also touch memory... are they safe to
dedup? Surprisingly, yes! Uniforms are easy: they're read-only. No
way to store to uniforms, so no intervening store can invalidate them.
Gathers are a little fuzzier, in that the buffer we gather from is
uniform in practice, but not strictly required to be... it's not
impossible to construct a program that gathers from a buffer that the
program also stores to, but you'd have to go out of your way to do it,
and it's not a pattern we use today, and SkVM does not provide the
synchronization primitives you'd need to make attempting that even
vaguely sensible. So gathers in practice can also be deduplicated.
In general it's safe to dedup an operation unless it touches _varying
memory_, i.e. loads and stores. uniform32 and gathers touch
non-varying memory, so they're safe, and while index is varying, it
doesn't touch memory.
Change-Id: Ia275f0ab2708d3f71e783164b419436b90f103a9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/350608
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
I noticed is_always_varying() is a little wrong, and this new test demos
how. This isn't terribly important: in most practical situations
gathers will indeed be varying.
Change-Id: I456d4c7287147726c49ebb5af5af347c65cd21d4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/350602
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
The new unit test demonstrates load/store reordering is error-prone.
At head we're allowing loads from a given pointer to reorder later than
a store to that same pointer, and boy, that's just not sound. In the
scenario constructed by the test we reorder this swap,
x = load32 X
y = load32 Y
store32 X y
store32 Y x
using schedule() (following Op argument data dependencies) into
y = load32 Y
store32 X y
x = load32 X
store32 Y x
which moves `x = load32 X` illegally past `store X y`.
We write `y` twice instead of swapping `x` and `y`.
It's not impossible to implement that extra reordering constraint: I
think it's easiest to think about by adding implicit use edges in
schedule() from stores to prior loads of the same pointer. But that'd
be a little complicated to implement, and doesn't handle aliasing at
all, so I decided to ponder on other approaches that handle a wider
range of programs or would have a simpler implementation to reason
about. I ended up walking through this rough chain of ideas:
0) reorder using only Op argument data dependencies (HEAD)
1) don't let load(ptr) pass store(ptr) (above)
2) don't let any load pass any store (allows aliasing)
3) don't reorder any Op that touches memory
4) don't reorder any Op, period.
This CL is 4). It's certainly the easiest and cheapest implementation.
It's not clear to me that we need this scheduling, and should we find we
really want it I'll come back and work back through the list until we
find something that meets our needs.
(Hoisting of uniforms is unaffected here.)
Change-Id: I7765b1d16202e0645b11295f7e30c5e09f2b7339
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/350256
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Should allow us to test sksl->skvm portably using dump().
Change-Id: If55e8e144f04643c02bd65baa84158ac1bf441b5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/346336
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
None of these earliest testing tools are useful anymore
now that we can do useful work with SkVM and SkVMBlitter.
Change-Id: I8b25ef6ddd101c4ff8617c6742343dedb4764922
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/345456
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>
Change-Id: I233398bf34411231d44613d89aed28935fe30a28
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/340796
Commit-Queue: Herb Derby <herb@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
This finishes up the existing SkVM ops on arm64.
I wish I had a unit test for this, but there's no diffs drawing RGBA F32.
Change-Id: I53725769fa2e7a1701f7360905205356e1ea18cb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/340718
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Nothing too tricky here.
Change-Id: I48e51c301e53efc63fc92c378fe45a0e5a2df7e6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/340520
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Much like store64, load64 really wants to use ld2.4s but that needs a
way to allocate adjacent registers. So, just like store64, do it
manually, this time with uzp (unzip).
Change-Id: Ie10cc8d2df57390d1c6709bd7485bb5158375078
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/340519
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Ideally we'd use st2.4s here but that needs its inputs in adjacent
registers, and I don't have a mechanism for that (yet). So instead
interlace manually using zip1/zip2.
Tested by SkVM_64bit.
Change-Id: I7b05fcd1f4398012755fc4f0d4e39743d0c69a94
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/340518
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Change-Id: If22eabb68b9293f5bc1d275535135d9760fe1ae5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/339578
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
