2019-12-16 14:17:25 +00:00
|
|
|
/*
|
|
|
|
* Copyright 2019 Google LLC
|
|
|
|
*
|
|
|
|
* Use of this source code is governed by a BSD-style license that can be
|
|
|
|
* found in the LICENSE file.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef SkRuntimeEffect_DEFINED
|
|
|
|
#define SkRuntimeEffect_DEFINED
|
|
|
|
|
2020-04-15 18:18:13 +00:00
|
|
|
#include "include/core/SkData.h"
|
2020-06-18 17:40:26 +00:00
|
|
|
#include "include/core/SkMatrix.h"
|
2019-12-16 14:17:25 +00:00
|
|
|
#include "include/core/SkString.h"
|
2020-07-20 15:18:23 +00:00
|
|
|
#include "include/private/GrTypesPriv.h"
|
2020-06-30 17:39:35 +00:00
|
|
|
#include "include/private/SkSLSampleUsage.h"
|
2019-12-16 14:17:25 +00:00
|
|
|
|
2020-06-18 17:40:26 +00:00
|
|
|
#include <string>
|
2019-12-16 14:17:25 +00:00
|
|
|
#include <vector>
|
|
|
|
|
2019-12-30 20:02:30 +00:00
|
|
|
#if SK_SUPPORT_GPU
|
2020-03-06 20:23:54 +00:00
|
|
|
#include "include/gpu/GrContextOptions.h"
|
2019-12-30 20:02:30 +00:00
|
|
|
#endif
|
|
|
|
|
2019-12-16 14:17:25 +00:00
|
|
|
class GrShaderCaps;
|
2020-01-02 13:03:40 +00:00
|
|
|
class SkColorFilter;
|
2019-12-26 13:43:05 +00:00
|
|
|
class SkShader;
|
2019-12-16 14:17:25 +00:00
|
|
|
|
|
|
|
namespace SkSL {
|
|
|
|
class ByteCode;
|
2019-12-30 20:02:30 +00:00
|
|
|
struct PipelineStageArgs;
|
2019-12-16 14:17:25 +00:00
|
|
|
struct Program;
|
2020-02-21 18:43:49 +00:00
|
|
|
class SharedCompiler;
|
2020-08-06 18:11:56 +00:00
|
|
|
} // namespace SkSL
|
2019-12-16 14:17:25 +00:00
|
|
|
|
2020-01-02 16:55:24 +00:00
|
|
|
/*
|
|
|
|
* SkRuntimeEffect supports creating custom SkShader and SkColorFilter objects using Skia's SkSL
|
|
|
|
* shading language.
|
2020-04-15 18:18:13 +00:00
|
|
|
*
|
|
|
|
* NOTE: This API is experimental and subject to change.
|
2020-01-02 16:55:24 +00:00
|
|
|
*/
|
|
|
|
class SK_API SkRuntimeEffect : public SkRefCnt {
|
2019-12-16 14:17:25 +00:00
|
|
|
public:
|
Remove 'in' variables from SkRuntimeEffect
Runtime effects previously allowed two kinds of global input variables:
'in' variables could be bool, int, or float. 'uniform' could be float,
vector, or matrix. Uniform variables worked like you'd expect, but 'in'
variables were baked into the program statically. There was a large
amount of machinery to make this work, and it meant that 'in' variables
needed to have values before we could make decisions about program
caching, and before we could catch some errors. It was also essentially
syntactic sugar over the client just inserting the value into their SkSL
as a string. Finally: No one was using the feature.
To simplify the mental model, and make the API much more predictable,
this CL removes 'in' variables entirely. We no longer need to
"specialize" runtime effect programs, which means we can catch more
errors up front (those not detected until optimization). All of the API
that referred to "inputs" (the previous term that unified 'in' and
'uniform') now just refers to "uniforms".
Bug: skia:10593
Change-Id: I971f620d868b259e652b3114f0b497c2620f4b0c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/309050
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
2020-08-10 18:26:16 +00:00
|
|
|
struct Uniform {
|
2019-12-18 16:23:12 +00:00
|
|
|
enum class Type {
|
|
|
|
kFloat,
|
|
|
|
kFloat2,
|
|
|
|
kFloat3,
|
|
|
|
kFloat4,
|
|
|
|
kFloat2x2,
|
|
|
|
kFloat3x3,
|
|
|
|
kFloat4x4,
|
|
|
|
};
|
|
|
|
|
|
|
|
enum Flags {
|
2020-04-15 18:18:13 +00:00
|
|
|
kArray_Flag = 0x1,
|
|
|
|
kMarker_Flag = 0x2,
|
|
|
|
kMarkerNormals_Flag = 0x4,
|
2020-04-30 21:12:03 +00:00
|
|
|
kSRGBUnpremul_Flag = 0x8,
|
2019-12-18 16:23:12 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
SkString fName;
|
|
|
|
size_t fOffset;
|
|
|
|
Type fType;
|
2020-07-20 15:18:23 +00:00
|
|
|
GrSLType fGPUType;
|
2019-12-18 16:23:12 +00:00
|
|
|
int fCount;
|
|
|
|
uint32_t fFlags;
|
2020-04-15 18:18:13 +00:00
|
|
|
uint32_t fMarker;
|
2019-12-18 16:23:12 +00:00
|
|
|
|
|
|
|
bool isArray() const { return SkToBool(fFlags & kArray_Flag); }
|
|
|
|
size_t sizeInBytes() const;
|
|
|
|
};
|
|
|
|
|
2020-03-23 14:44:12 +00:00
|
|
|
struct Varying {
|
|
|
|
SkString fName;
|
|
|
|
int fWidth; // 1 - 4 (floats)
|
|
|
|
};
|
|
|
|
|
2019-12-19 20:44:56 +00:00
|
|
|
// [Effect, ErrorText]
|
|
|
|
// If successful, Effect != nullptr, otherwise, ErrorText contains the reason for failure.
|
|
|
|
using EffectResult = std::tuple<sk_sp<SkRuntimeEffect>, SkString>;
|
|
|
|
static EffectResult Make(SkString sksl);
|
2019-12-16 14:17:25 +00:00
|
|
|
|
Remove 'in' variables from SkRuntimeEffect
Runtime effects previously allowed two kinds of global input variables:
'in' variables could be bool, int, or float. 'uniform' could be float,
vector, or matrix. Uniform variables worked like you'd expect, but 'in'
variables were baked into the program statically. There was a large
amount of machinery to make this work, and it meant that 'in' variables
needed to have values before we could make decisions about program
caching, and before we could catch some errors. It was also essentially
syntactic sugar over the client just inserting the value into their SkSL
as a string. Finally: No one was using the feature.
To simplify the mental model, and make the API much more predictable,
this CL removes 'in' variables entirely. We no longer need to
"specialize" runtime effect programs, which means we can catch more
errors up front (those not detected until optimization). All of the API
that referred to "inputs" (the previous term that unified 'in' and
'uniform') now just refers to "uniforms".
Bug: skia:10593
Change-Id: I971f620d868b259e652b3114f0b497c2620f4b0c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/309050
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
2020-08-10 18:26:16 +00:00
|
|
|
sk_sp<SkShader> makeShader(sk_sp<SkData> uniforms,
|
2020-04-15 18:18:13 +00:00
|
|
|
sk_sp<SkShader> children[],
|
|
|
|
size_t childCount,
|
|
|
|
const SkMatrix* localMatrix,
|
|
|
|
bool isOpaque);
|
2019-12-26 13:43:05 +00:00
|
|
|
|
Remove 'in' variables from SkRuntimeEffect
Runtime effects previously allowed two kinds of global input variables:
'in' variables could be bool, int, or float. 'uniform' could be float,
vector, or matrix. Uniform variables worked like you'd expect, but 'in'
variables were baked into the program statically. There was a large
amount of machinery to make this work, and it meant that 'in' variables
needed to have values before we could make decisions about program
caching, and before we could catch some errors. It was also essentially
syntactic sugar over the client just inserting the value into their SkSL
as a string. Finally: No one was using the feature.
To simplify the mental model, and make the API much more predictable,
this CL removes 'in' variables entirely. We no longer need to
"specialize" runtime effect programs, which means we can catch more
errors up front (those not detected until optimization). All of the API
that referred to "inputs" (the previous term that unified 'in' and
'uniform') now just refers to "uniforms".
Bug: skia:10593
Change-Id: I971f620d868b259e652b3114f0b497c2620f4b0c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/309050
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
2020-08-10 18:26:16 +00:00
|
|
|
sk_sp<SkColorFilter> makeColorFilter(sk_sp<SkData> uniforms);
|
|
|
|
sk_sp<SkColorFilter> makeColorFilter(sk_sp<SkData> uniforms,
|
2020-08-06 14:53:12 +00:00
|
|
|
sk_sp<SkColorFilter> children[],
|
|
|
|
size_t childCount);
|
2020-01-02 13:03:40 +00:00
|
|
|
|
2019-12-16 14:17:25 +00:00
|
|
|
const SkString& source() const { return fSkSL; }
|
2020-02-05 16:37:08 +00:00
|
|
|
uint32_t hash() const { return fHash; }
|
2020-01-08 18:19:58 +00:00
|
|
|
|
|
|
|
template <typename T>
|
|
|
|
class ConstIterable {
|
|
|
|
public:
|
|
|
|
ConstIterable(const std::vector<T>& vec) : fVec(vec) {}
|
|
|
|
|
|
|
|
using const_iterator = typename std::vector<T>::const_iterator;
|
|
|
|
|
|
|
|
const_iterator begin() const { return fVec.begin(); }
|
|
|
|
const_iterator end() const { return fVec.end(); }
|
|
|
|
size_t count() const { return fVec.size(); }
|
|
|
|
|
|
|
|
private:
|
|
|
|
const std::vector<T>& fVec;
|
|
|
|
};
|
|
|
|
|
Remove 'in' variables from SkRuntimeEffect
Runtime effects previously allowed two kinds of global input variables:
'in' variables could be bool, int, or float. 'uniform' could be float,
vector, or matrix. Uniform variables worked like you'd expect, but 'in'
variables were baked into the program statically. There was a large
amount of machinery to make this work, and it meant that 'in' variables
needed to have values before we could make decisions about program
caching, and before we could catch some errors. It was also essentially
syntactic sugar over the client just inserting the value into their SkSL
as a string. Finally: No one was using the feature.
To simplify the mental model, and make the API much more predictable,
this CL removes 'in' variables entirely. We no longer need to
"specialize" runtime effect programs, which means we can catch more
errors up front (those not detected until optimization). All of the API
that referred to "inputs" (the previous term that unified 'in' and
'uniform') now just refers to "uniforms".
Bug: skia:10593
Change-Id: I971f620d868b259e652b3114f0b497c2620f4b0c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/309050
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
2020-08-10 18:26:16 +00:00
|
|
|
// Combined size of all 'uniform' variables. When calling makeColorFilter or makeShader,
|
|
|
|
// provide an SkData of this size, containing values for all of those variables.
|
|
|
|
size_t uniformSize() const;
|
2020-01-10 15:05:24 +00:00
|
|
|
|
Remove 'in' variables from SkRuntimeEffect
Runtime effects previously allowed two kinds of global input variables:
'in' variables could be bool, int, or float. 'uniform' could be float,
vector, or matrix. Uniform variables worked like you'd expect, but 'in'
variables were baked into the program statically. There was a large
amount of machinery to make this work, and it meant that 'in' variables
needed to have values before we could make decisions about program
caching, and before we could catch some errors. It was also essentially
syntactic sugar over the client just inserting the value into their SkSL
as a string. Finally: No one was using the feature.
To simplify the mental model, and make the API much more predictable,
this CL removes 'in' variables entirely. We no longer need to
"specialize" runtime effect programs, which means we can catch more
errors up front (those not detected until optimization). All of the API
that referred to "inputs" (the previous term that unified 'in' and
'uniform') now just refers to "uniforms".
Bug: skia:10593
Change-Id: I971f620d868b259e652b3114f0b497c2620f4b0c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/309050
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
2020-08-10 18:26:16 +00:00
|
|
|
ConstIterable<Uniform> uniforms() const { return ConstIterable<Uniform>(fUniforms); }
|
2020-01-08 18:19:58 +00:00
|
|
|
ConstIterable<SkString> children() const { return ConstIterable<SkString>(fChildren); }
|
2020-03-23 14:44:12 +00:00
|
|
|
ConstIterable<Varying> varyings() const { return ConstIterable<Varying>(fVaryings); }
|
2019-12-16 14:17:25 +00:00
|
|
|
|
Remove 'in' variables from SkRuntimeEffect
Runtime effects previously allowed two kinds of global input variables:
'in' variables could be bool, int, or float. 'uniform' could be float,
vector, or matrix. Uniform variables worked like you'd expect, but 'in'
variables were baked into the program statically. There was a large
amount of machinery to make this work, and it meant that 'in' variables
needed to have values before we could make decisions about program
caching, and before we could catch some errors. It was also essentially
syntactic sugar over the client just inserting the value into their SkSL
as a string. Finally: No one was using the feature.
To simplify the mental model, and make the API much more predictable,
this CL removes 'in' variables entirely. We no longer need to
"specialize" runtime effect programs, which means we can catch more
errors up front (those not detected until optimization). All of the API
that referred to "inputs" (the previous term that unified 'in' and
'uniform') now just refers to "uniforms".
Bug: skia:10593
Change-Id: I971f620d868b259e652b3114f0b497c2620f4b0c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/309050
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
2020-08-10 18:26:16 +00:00
|
|
|
// Returns pointer to the named uniform variable's description, or nullptr if not found
|
|
|
|
const Uniform* findUniform(const char* name) const;
|
2020-04-15 18:18:13 +00:00
|
|
|
|
|
|
|
// Returns index of the named child, or -1 if not found
|
|
|
|
int findChild(const char* name) const;
|
|
|
|
|
2020-08-05 20:48:58 +00:00
|
|
|
bool usesSampleCoords() const { return fUsesSampleCoords; }
|
Update how sample(matrix) calls are invoked in SkSL
This removes the kMixed type of SkSL::SampleMatrix. All analysis of FP
sampling due to parent-child relationships is tracked in flags on
GrFragmentProcessor now.
The sample strategy is tracked as follows:
- An FP marks itself as using the local coordinate builtin directly (automatically done for .fp code based on reference to sk_TransformedCoords2D[0]).
- This state propagates up the parent towards the root, marking FPs as using coordinates indirectly. We stop the propagation when we hit a parent FP that explicitly samples the child because it becomes the source of the child's coordinates.
- If that parent references its local coordinates directly, that kicks off its own upwards propagation.
- Being sampled explicitly propagates down to all children, and effectively disables vertex-shader evaluation of transforms.
- A variable matrix automatically marks this flag as well, since it's essentially a shortcut to (matrix expression) * coords.
- The matrix type also propagates down, but right now that's only for whether or not there's perspective.
- This doesn't affect FS coord evaluation since each FP applies its action independently.
- But for VS-promoted transforms, the child's varying may inherit perspective (or other more general matrix types) from the parent and switch from a float2 to a float3.
- A SampleMatrix no longer tracks a base or owner, GrFragmentProcessor exposes its parent FP. An FP's sample matrix is always owned by its immediate parent.
- This means that you can have a hierarchy from root to leaf like: [uniform, none, none, uses local coords], and that leaf will have a SampleMatrix of kNone type. However, because of parent tracking, the coordinate generation can walk up to the root and detect the proper transform expression it needs to produce, and automatically de-duplicate across children.
Currently, all FP's that are explicitly sampled have a signature of (color, float2 coord). FP's that don't use local coords, or whose coords are promoted to a varying have a signature of (color).
- In this case, the shader builder either updates args.fLocalCoords to point to the varying directly, or adds a float2 local to the function body that includes the perspective divide.
GrFragmentProcessor automatically pretends it has an identity coord transform if the FP is marked as referencing the local coord builtin. This allows these FPs to still be processed as part of GrGLSLGeometryProcessor::collectTransforms, but removes the need for FP implementations to declare an identity GrCoordTransform.
- To test this theory, GrTextureEffect and GrSkSLFP no longer have coord transforms explicitly.
- Later CLs can trivially remove them from a lot of the other effects.
- The coord generation should not change because it detects in both cases that the coord transform matrices were identity.
GrGLSLGeometryProcessor's collectTransforms and emitTransformCode has been completely overhauled to recurse up an FP's parent pointers and collect the expressions that affect the result. It de-duplicates expressions between siblings, and is able to produce a single varying for the base local coord (either when there are no intervening transforms, or the root FP needs an explicit coordinate to start off with).
This also adds the fp_sample_chaining GM from Brian, with a few more configurations to fill out the cells.
Bug: skia:10396
Change-Id: I86acc0c34c9f29d6371b34370bee9a18c2acf1c1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/297868
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2020-06-24 13:04:56 +00:00
|
|
|
|
2020-04-15 18:18:13 +00:00
|
|
|
static void RegisterFlattenables();
|
2020-07-21 21:03:56 +00:00
|
|
|
~SkRuntimeEffect() override;
|
2020-04-15 18:18:13 +00:00
|
|
|
|
|
|
|
private:
|
2020-06-18 17:40:26 +00:00
|
|
|
SkRuntimeEffect(SkString sksl,
|
|
|
|
std::unique_ptr<SkSL::Program> baseProgram,
|
Remove 'in' variables from SkRuntimeEffect
Runtime effects previously allowed two kinds of global input variables:
'in' variables could be bool, int, or float. 'uniform' could be float,
vector, or matrix. Uniform variables worked like you'd expect, but 'in'
variables were baked into the program statically. There was a large
amount of machinery to make this work, and it meant that 'in' variables
needed to have values before we could make decisions about program
caching, and before we could catch some errors. It was also essentially
syntactic sugar over the client just inserting the value into their SkSL
as a string. Finally: No one was using the feature.
To simplify the mental model, and make the API much more predictable,
this CL removes 'in' variables entirely. We no longer need to
"specialize" runtime effect programs, which means we can catch more
errors up front (those not detected until optimization). All of the API
that referred to "inputs" (the previous term that unified 'in' and
'uniform') now just refers to "uniforms".
Bug: skia:10593
Change-Id: I971f620d868b259e652b3114f0b497c2620f4b0c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/309050
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
2020-08-10 18:26:16 +00:00
|
|
|
std::vector<Uniform>&& uniforms,
|
2020-06-18 17:40:26 +00:00
|
|
|
std::vector<SkString>&& children,
|
2020-06-30 17:39:35 +00:00
|
|
|
std::vector<SkSL::SampleUsage>&& sampleUsages,
|
2020-06-18 17:40:26 +00:00
|
|
|
std::vector<Varying>&& varyings,
|
2020-08-05 20:48:58 +00:00
|
|
|
bool usesSampleCoords,
|
|
|
|
bool allowColorFilter);
|
2020-04-15 18:18:13 +00:00
|
|
|
|
2019-12-16 14:17:25 +00:00
|
|
|
#if SK_SUPPORT_GPU
|
2020-06-18 17:40:26 +00:00
|
|
|
friend class GrSkSLFP; // toPipelineStage
|
2020-06-30 17:39:35 +00:00
|
|
|
friend class GrGLSLSkSLFP; // fSampleUsages
|
2020-04-15 18:18:13 +00:00
|
|
|
|
2019-12-16 14:17:25 +00:00
|
|
|
// This re-compiles the program from scratch, using the supplied shader caps.
|
|
|
|
// This is necessary to get the correct values of settings.
|
Remove 'in' variables from SkRuntimeEffect
Runtime effects previously allowed two kinds of global input variables:
'in' variables could be bool, int, or float. 'uniform' could be float,
vector, or matrix. Uniform variables worked like you'd expect, but 'in'
variables were baked into the program statically. There was a large
amount of machinery to make this work, and it meant that 'in' variables
needed to have values before we could make decisions about program
caching, and before we could catch some errors. It was also essentially
syntactic sugar over the client just inserting the value into their SkSL
as a string. Finally: No one was using the feature.
To simplify the mental model, and make the API much more predictable,
this CL removes 'in' variables entirely. We no longer need to
"specialize" runtime effect programs, which means we can catch more
errors up front (those not detected until optimization). All of the API
that referred to "inputs" (the previous term that unified 'in' and
'uniform') now just refers to "uniforms".
Bug: skia:10593
Change-Id: I971f620d868b259e652b3114f0b497c2620f4b0c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/309050
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
2020-08-10 18:26:16 +00:00
|
|
|
bool toPipelineStage(const GrShaderCaps* shaderCaps,
|
2020-03-06 20:23:54 +00:00
|
|
|
GrContextOptions::ShaderErrorHandler* errorHandler,
|
2019-12-30 20:02:30 +00:00
|
|
|
SkSL::PipelineStageArgs* outArgs);
|
2019-12-16 14:17:25 +00:00
|
|
|
#endif
|
|
|
|
|
Remove 'in' variables from SkRuntimeEffect
Runtime effects previously allowed two kinds of global input variables:
'in' variables could be bool, int, or float. 'uniform' could be float,
vector, or matrix. Uniform variables worked like you'd expect, but 'in'
variables were baked into the program statically. There was a large
amount of machinery to make this work, and it meant that 'in' variables
needed to have values before we could make decisions about program
caching, and before we could catch some errors. It was also essentially
syntactic sugar over the client just inserting the value into their SkSL
as a string. Finally: No one was using the feature.
To simplify the mental model, and make the API much more predictable,
this CL removes 'in' variables entirely. We no longer need to
"specialize" runtime effect programs, which means we can catch more
errors up front (those not detected until optimization). All of the API
that referred to "inputs" (the previous term that unified 'in' and
'uniform') now just refers to "uniforms".
Bug: skia:10593
Change-Id: I971f620d868b259e652b3114f0b497c2620f4b0c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/309050
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
2020-08-10 18:26:16 +00:00
|
|
|
friend class SkRTShader; // toByteCode
|
2020-04-15 18:18:13 +00:00
|
|
|
friend class SkRuntimeColorFilter; //
|
|
|
|
|
2019-12-19 20:44:56 +00:00
|
|
|
// [ByteCode, ErrorText]
|
|
|
|
// If successful, ByteCode != nullptr, otherwise, ErrorText contains the reason for failure.
|
|
|
|
using ByteCodeResult = std::tuple<std::unique_ptr<SkSL::ByteCode>, SkString>;
|
Remove 'in' variables from SkRuntimeEffect
Runtime effects previously allowed two kinds of global input variables:
'in' variables could be bool, int, or float. 'uniform' could be float,
vector, or matrix. Uniform variables worked like you'd expect, but 'in'
variables were baked into the program statically. There was a large
amount of machinery to make this work, and it meant that 'in' variables
needed to have values before we could make decisions about program
caching, and before we could catch some errors. It was also essentially
syntactic sugar over the client just inserting the value into their SkSL
as a string. Finally: No one was using the feature.
To simplify the mental model, and make the API much more predictable,
this CL removes 'in' variables entirely. We no longer need to
"specialize" runtime effect programs, which means we can catch more
errors up front (those not detected until optimization). All of the API
that referred to "inputs" (the previous term that unified 'in' and
'uniform') now just refers to "uniforms".
Bug: skia:10593
Change-Id: I971f620d868b259e652b3114f0b497c2620f4b0c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/309050
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
2020-08-10 18:26:16 +00:00
|
|
|
ByteCodeResult toByteCode() const;
|
2020-01-10 15:05:24 +00:00
|
|
|
|
2019-12-16 14:17:25 +00:00
|
|
|
|
2020-02-05 16:37:08 +00:00
|
|
|
uint32_t fHash;
|
2019-12-16 14:17:25 +00:00
|
|
|
SkString fSkSL;
|
|
|
|
|
|
|
|
std::unique_ptr<SkSL::Program> fBaseProgram;
|
Remove 'in' variables from SkRuntimeEffect
Runtime effects previously allowed two kinds of global input variables:
'in' variables could be bool, int, or float. 'uniform' could be float,
vector, or matrix. Uniform variables worked like you'd expect, but 'in'
variables were baked into the program statically. There was a large
amount of machinery to make this work, and it meant that 'in' variables
needed to have values before we could make decisions about program
caching, and before we could catch some errors. It was also essentially
syntactic sugar over the client just inserting the value into their SkSL
as a string. Finally: No one was using the feature.
To simplify the mental model, and make the API much more predictable,
this CL removes 'in' variables entirely. We no longer need to
"specialize" runtime effect programs, which means we can catch more
errors up front (those not detected until optimization). All of the API
that referred to "inputs" (the previous term that unified 'in' and
'uniform') now just refers to "uniforms".
Bug: skia:10593
Change-Id: I971f620d868b259e652b3114f0b497c2620f4b0c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/309050
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
2020-08-10 18:26:16 +00:00
|
|
|
std::vector<Uniform> fUniforms;
|
2019-12-18 20:44:27 +00:00
|
|
|
std::vector<SkString> fChildren;
|
2020-06-30 17:39:35 +00:00
|
|
|
std::vector<SkSL::SampleUsage> fSampleUsages;
|
2020-03-23 14:44:12 +00:00
|
|
|
std::vector<Varying> fVaryings;
|
2020-01-10 15:05:24 +00:00
|
|
|
|
2020-08-05 20:48:58 +00:00
|
|
|
bool fUsesSampleCoords;
|
|
|
|
bool fAllowColorFilter;
|
2019-12-16 14:17:25 +00:00
|
|
|
};
|
|
|
|
|
2020-04-15 18:18:13 +00:00
|
|
|
/**
|
|
|
|
* SkRuntimeShaderBuilder is a utility to simplify creating SkShader objects from SkRuntimeEffects.
|
|
|
|
*
|
|
|
|
* NOTE: Like SkRuntimeEffect, this API is experimental and subject to change!
|
|
|
|
*
|
|
|
|
* Given an SkRuntimeEffect, the SkRuntimeShaderBuilder manages creating an input data block and
|
Remove 'in' variables from SkRuntimeEffect
Runtime effects previously allowed two kinds of global input variables:
'in' variables could be bool, int, or float. 'uniform' could be float,
vector, or matrix. Uniform variables worked like you'd expect, but 'in'
variables were baked into the program statically. There was a large
amount of machinery to make this work, and it meant that 'in' variables
needed to have values before we could make decisions about program
caching, and before we could catch some errors. It was also essentially
syntactic sugar over the client just inserting the value into their SkSL
as a string. Finally: No one was using the feature.
To simplify the mental model, and make the API much more predictable,
this CL removes 'in' variables entirely. We no longer need to
"specialize" runtime effect programs, which means we can catch more
errors up front (those not detected until optimization). All of the API
that referred to "inputs" (the previous term that unified 'in' and
'uniform') now just refers to "uniforms".
Bug: skia:10593
Change-Id: I971f620d868b259e652b3114f0b497c2620f4b0c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/309050
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
2020-08-10 18:26:16 +00:00
|
|
|
* provides named access to the 'uniform' variables in that block, as well as named access
|
2020-04-15 18:18:13 +00:00
|
|
|
* to a list of child shader slots. Usage:
|
|
|
|
*
|
|
|
|
* sk_sp<SkRuntimeEffect> effect = ...;
|
|
|
|
* SkRuntimeShaderBuilder builder(effect);
|
Remove 'in' variables from SkRuntimeEffect
Runtime effects previously allowed two kinds of global input variables:
'in' variables could be bool, int, or float. 'uniform' could be float,
vector, or matrix. Uniform variables worked like you'd expect, but 'in'
variables were baked into the program statically. There was a large
amount of machinery to make this work, and it meant that 'in' variables
needed to have values before we could make decisions about program
caching, and before we could catch some errors. It was also essentially
syntactic sugar over the client just inserting the value into their SkSL
as a string. Finally: No one was using the feature.
To simplify the mental model, and make the API much more predictable,
this CL removes 'in' variables entirely. We no longer need to
"specialize" runtime effect programs, which means we can catch more
errors up front (those not detected until optimization). All of the API
that referred to "inputs" (the previous term that unified 'in' and
'uniform') now just refers to "uniforms".
Bug: skia:10593
Change-Id: I971f620d868b259e652b3114f0b497c2620f4b0c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/309050
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
2020-08-10 18:26:16 +00:00
|
|
|
* builder.uniform("some_uniform_float") = 3.14f;
|
|
|
|
* builder.uniform("some_uniform_matrix") = SkM44::Rotate(...);
|
2020-04-15 18:18:13 +00:00
|
|
|
* builder.child("some_child_effect") = mySkImage->makeShader(...);
|
|
|
|
* ...
|
|
|
|
* sk_sp<SkShader> shader = builder.makeShader(nullptr, false);
|
|
|
|
*
|
|
|
|
* Note that SkRuntimeShaderBuilder is built entirely on the public API of SkRuntimeEffect,
|
|
|
|
* so can be used as-is or serve as inspiration for other interfaces or binding techniques.
|
|
|
|
*/
|
|
|
|
struct SkRuntimeShaderBuilder {
|
|
|
|
SkRuntimeShaderBuilder(sk_sp<SkRuntimeEffect>);
|
|
|
|
~SkRuntimeShaderBuilder();
|
|
|
|
|
Remove 'in' variables from SkRuntimeEffect
Runtime effects previously allowed two kinds of global input variables:
'in' variables could be bool, int, or float. 'uniform' could be float,
vector, or matrix. Uniform variables worked like you'd expect, but 'in'
variables were baked into the program statically. There was a large
amount of machinery to make this work, and it meant that 'in' variables
needed to have values before we could make decisions about program
caching, and before we could catch some errors. It was also essentially
syntactic sugar over the client just inserting the value into their SkSL
as a string. Finally: No one was using the feature.
To simplify the mental model, and make the API much more predictable,
this CL removes 'in' variables entirely. We no longer need to
"specialize" runtime effect programs, which means we can catch more
errors up front (those not detected until optimization). All of the API
that referred to "inputs" (the previous term that unified 'in' and
'uniform') now just refers to "uniforms".
Bug: skia:10593
Change-Id: I971f620d868b259e652b3114f0b497c2620f4b0c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/309050
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
2020-08-10 18:26:16 +00:00
|
|
|
struct BuilderUniform {
|
2020-04-15 18:18:13 +00:00
|
|
|
// Copy 'val' to this variable. No type conversion is performed - 'val' must be same
|
|
|
|
// size as expected by the effect. Information about the variable can be queried by
|
|
|
|
// looking at fVar. If the size is incorrect, no copy will be performed, and debug
|
|
|
|
// builds will abort. If this is the result of querying a missing variable, fVar will
|
|
|
|
// be nullptr, and assigning will also do nothing (and abort in debug builds).
|
|
|
|
template <typename T>
|
Remove 'in' variables from SkRuntimeEffect
Runtime effects previously allowed two kinds of global input variables:
'in' variables could be bool, int, or float. 'uniform' could be float,
vector, or matrix. Uniform variables worked like you'd expect, but 'in'
variables were baked into the program statically. There was a large
amount of machinery to make this work, and it meant that 'in' variables
needed to have values before we could make decisions about program
caching, and before we could catch some errors. It was also essentially
syntactic sugar over the client just inserting the value into their SkSL
as a string. Finally: No one was using the feature.
To simplify the mental model, and make the API much more predictable,
this CL removes 'in' variables entirely. We no longer need to
"specialize" runtime effect programs, which means we can catch more
errors up front (those not detected until optimization). All of the API
that referred to "inputs" (the previous term that unified 'in' and
'uniform') now just refers to "uniforms".
Bug: skia:10593
Change-Id: I971f620d868b259e652b3114f0b497c2620f4b0c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/309050
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
2020-08-10 18:26:16 +00:00
|
|
|
std::enable_if_t<std::is_trivially_copyable<T>::value, BuilderUniform&> operator=(
|
2020-04-15 18:18:13 +00:00
|
|
|
const T& val) {
|
|
|
|
if (!fVar) {
|
|
|
|
SkDEBUGFAIL("Assigning to missing variable");
|
|
|
|
} else if (sizeof(val) != fVar->sizeInBytes()) {
|
|
|
|
SkDEBUGFAIL("Incorrect value size");
|
|
|
|
} else {
|
Remove 'in' variables from SkRuntimeEffect
Runtime effects previously allowed two kinds of global input variables:
'in' variables could be bool, int, or float. 'uniform' could be float,
vector, or matrix. Uniform variables worked like you'd expect, but 'in'
variables were baked into the program statically. There was a large
amount of machinery to make this work, and it meant that 'in' variables
needed to have values before we could make decisions about program
caching, and before we could catch some errors. It was also essentially
syntactic sugar over the client just inserting the value into their SkSL
as a string. Finally: No one was using the feature.
To simplify the mental model, and make the API much more predictable,
this CL removes 'in' variables entirely. We no longer need to
"specialize" runtime effect programs, which means we can catch more
errors up front (those not detected until optimization). All of the API
that referred to "inputs" (the previous term that unified 'in' and
'uniform') now just refers to "uniforms".
Bug: skia:10593
Change-Id: I971f620d868b259e652b3114f0b497c2620f4b0c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/309050
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
2020-08-10 18:26:16 +00:00
|
|
|
memcpy(SkTAddOffset<void>(fOwner->fUniforms->writable_data(), fVar->fOffset),
|
2020-04-15 18:18:13 +00:00
|
|
|
&val, sizeof(val));
|
|
|
|
}
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
Remove 'in' variables from SkRuntimeEffect
Runtime effects previously allowed two kinds of global input variables:
'in' variables could be bool, int, or float. 'uniform' could be float,
vector, or matrix. Uniform variables worked like you'd expect, but 'in'
variables were baked into the program statically. There was a large
amount of machinery to make this work, and it meant that 'in' variables
needed to have values before we could make decisions about program
caching, and before we could catch some errors. It was also essentially
syntactic sugar over the client just inserting the value into their SkSL
as a string. Finally: No one was using the feature.
To simplify the mental model, and make the API much more predictable,
this CL removes 'in' variables entirely. We no longer need to
"specialize" runtime effect programs, which means we can catch more
errors up front (those not detected until optimization). All of the API
that referred to "inputs" (the previous term that unified 'in' and
'uniform') now just refers to "uniforms".
Bug: skia:10593
Change-Id: I971f620d868b259e652b3114f0b497c2620f4b0c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/309050
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
2020-08-10 18:26:16 +00:00
|
|
|
BuilderUniform& operator=(const SkMatrix& val) {
|
2020-06-18 17:40:26 +00:00
|
|
|
if (!fVar) {
|
|
|
|
SkDEBUGFAIL("Assigning to missing variable");
|
|
|
|
} else if (fVar->sizeInBytes() != 9 * sizeof(float)) {
|
|
|
|
SkDEBUGFAIL("Incorrect value size");
|
|
|
|
} else {
|
Remove 'in' variables from SkRuntimeEffect
Runtime effects previously allowed two kinds of global input variables:
'in' variables could be bool, int, or float. 'uniform' could be float,
vector, or matrix. Uniform variables worked like you'd expect, but 'in'
variables were baked into the program statically. There was a large
amount of machinery to make this work, and it meant that 'in' variables
needed to have values before we could make decisions about program
caching, and before we could catch some errors. It was also essentially
syntactic sugar over the client just inserting the value into their SkSL
as a string. Finally: No one was using the feature.
To simplify the mental model, and make the API much more predictable,
this CL removes 'in' variables entirely. We no longer need to
"specialize" runtime effect programs, which means we can catch more
errors up front (those not detected until optimization). All of the API
that referred to "inputs" (the previous term that unified 'in' and
'uniform') now just refers to "uniforms".
Bug: skia:10593
Change-Id: I971f620d868b259e652b3114f0b497c2620f4b0c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/309050
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
2020-08-10 18:26:16 +00:00
|
|
|
float* data = SkTAddOffset<float>(fOwner->fUniforms->writable_data(),
|
|
|
|
fVar->fOffset);
|
2020-06-18 17:40:26 +00:00
|
|
|
data[0] = val.get(0); data[1] = val.get(3); data[2] = val.get(6);
|
|
|
|
data[3] = val.get(1); data[4] = val.get(4); data[5] = val.get(7);
|
|
|
|
data[6] = val.get(2); data[7] = val.get(5); data[8] = val.get(8);
|
|
|
|
}
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
Remove 'in' variables from SkRuntimeEffect
Runtime effects previously allowed two kinds of global input variables:
'in' variables could be bool, int, or float. 'uniform' could be float,
vector, or matrix. Uniform variables worked like you'd expect, but 'in'
variables were baked into the program statically. There was a large
amount of machinery to make this work, and it meant that 'in' variables
needed to have values before we could make decisions about program
caching, and before we could catch some errors. It was also essentially
syntactic sugar over the client just inserting the value into their SkSL
as a string. Finally: No one was using the feature.
To simplify the mental model, and make the API much more predictable,
this CL removes 'in' variables entirely. We no longer need to
"specialize" runtime effect programs, which means we can catch more
errors up front (those not detected until optimization). All of the API
that referred to "inputs" (the previous term that unified 'in' and
'uniform') now just refers to "uniforms".
Bug: skia:10593
Change-Id: I971f620d868b259e652b3114f0b497c2620f4b0c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/309050
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
2020-08-10 18:26:16 +00:00
|
|
|
SkRuntimeShaderBuilder* fOwner;
|
|
|
|
const SkRuntimeEffect::Uniform* fVar; // nullptr if the variable was not found
|
2020-04-15 18:18:13 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct BuilderChild {
|
|
|
|
BuilderChild& operator=(const sk_sp<SkShader>& val);
|
|
|
|
|
|
|
|
SkRuntimeShaderBuilder* fOwner;
|
|
|
|
int fIndex; // -1 if the child was not found
|
|
|
|
};
|
|
|
|
|
Remove 'in' variables from SkRuntimeEffect
Runtime effects previously allowed two kinds of global input variables:
'in' variables could be bool, int, or float. 'uniform' could be float,
vector, or matrix. Uniform variables worked like you'd expect, but 'in'
variables were baked into the program statically. There was a large
amount of machinery to make this work, and it meant that 'in' variables
needed to have values before we could make decisions about program
caching, and before we could catch some errors. It was also essentially
syntactic sugar over the client just inserting the value into their SkSL
as a string. Finally: No one was using the feature.
To simplify the mental model, and make the API much more predictable,
this CL removes 'in' variables entirely. We no longer need to
"specialize" runtime effect programs, which means we can catch more
errors up front (those not detected until optimization). All of the API
that referred to "inputs" (the previous term that unified 'in' and
'uniform') now just refers to "uniforms".
Bug: skia:10593
Change-Id: I971f620d868b259e652b3114f0b497c2620f4b0c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/309050
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
2020-08-10 18:26:16 +00:00
|
|
|
BuilderUniform uniform(const char* name) { return { this, fEffect->findUniform(name) }; }
|
2020-04-15 18:18:13 +00:00
|
|
|
BuilderChild child(const char* name) { return { this, fEffect->findChild(name) }; }
|
|
|
|
|
|
|
|
sk_sp<SkShader> makeShader(const SkMatrix* localMatrix, bool isOpaque);
|
|
|
|
|
|
|
|
sk_sp<SkRuntimeEffect> fEffect;
|
Remove 'in' variables from SkRuntimeEffect
Runtime effects previously allowed two kinds of global input variables:
'in' variables could be bool, int, or float. 'uniform' could be float,
vector, or matrix. Uniform variables worked like you'd expect, but 'in'
variables were baked into the program statically. There was a large
amount of machinery to make this work, and it meant that 'in' variables
needed to have values before we could make decisions about program
caching, and before we could catch some errors. It was also essentially
syntactic sugar over the client just inserting the value into their SkSL
as a string. Finally: No one was using the feature.
To simplify the mental model, and make the API much more predictable,
this CL removes 'in' variables entirely. We no longer need to
"specialize" runtime effect programs, which means we can catch more
errors up front (those not detected until optimization). All of the API
that referred to "inputs" (the previous term that unified 'in' and
'uniform') now just refers to "uniforms".
Bug: skia:10593
Change-Id: I971f620d868b259e652b3114f0b497c2620f4b0c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/309050
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
2020-08-10 18:26:16 +00:00
|
|
|
sk_sp<SkData> fUniforms;
|
2020-04-15 18:18:13 +00:00
|
|
|
std::vector<sk_sp<SkShader>> fChildren;
|
|
|
|
};
|
|
|
|
|
2019-12-16 14:17:25 +00:00
|
|
|
#endif
|