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
|
|
|
|
|
2021-06-17 02:37:15 +00:00
|
|
|
#include "include/core/SkBlender.h"
|
2021-05-05 12:24:03 +00:00
|
|
|
#include "include/core/SkColorFilter.h"
|
2020-04-15 18:18:13 +00:00
|
|
|
#include "include/core/SkData.h"
|
2021-02-18 20:51:20 +00:00
|
|
|
#include "include/core/SkImageInfo.h"
|
2020-06-18 17:40:26 +00:00
|
|
|
#include "include/core/SkMatrix.h"
|
2021-03-23 21:04:41 +00:00
|
|
|
#include "include/core/SkShader.h"
|
2021-05-05 12:24:03 +00:00
|
|
|
#include "include/core/SkSpan.h"
|
2019-12-16 14:17:25 +00:00
|
|
|
#include "include/core/SkString.h"
|
2021-03-11 17:33:38 +00:00
|
|
|
#include "include/private/SkOnce.h"
|
2020-06-30 17:39:35 +00:00
|
|
|
#include "include/private/SkSLSampleUsage.h"
|
2021-07-30 18:17:24 +00:00
|
|
|
#include "include/private/SkTOptional.h"
|
2019-12-16 14:17:25 +00:00
|
|
|
|
2021-06-28 19:54:59 +00:00
|
|
|
#include <string>
|
2019-12-16 14:17:25 +00:00
|
|
|
#include <vector>
|
|
|
|
|
2021-07-12 21:02:21 +00:00
|
|
|
#ifdef SK_ENABLE_SKSL
|
|
|
|
|
2021-02-18 20:51:20 +00:00
|
|
|
class GrRecordingContext;
|
2021-05-12 20:53:19 +00:00
|
|
|
class SkFilterColorProgram;
|
2021-02-18 20:51:20 +00:00
|
|
|
class SkImage;
|
2021-11-29 21:41:31 +00:00
|
|
|
class SkRuntimeImageFilter;
|
2019-12-16 14:17:25 +00:00
|
|
|
|
|
|
|
namespace SkSL {
|
2021-12-07 21:51:41 +00:00
|
|
|
class DebugTrace;
|
2020-12-02 16:12:51 +00:00
|
|
|
class FunctionDefinition;
|
2019-12-16 14:17:25 +00:00
|
|
|
struct Program;
|
2021-04-12 13:49:20 +00:00
|
|
|
enum class ProgramKind : int8_t;
|
2020-08-06 18:11:56 +00:00
|
|
|
} // namespace SkSL
|
2019-12-16 14:17:25 +00:00
|
|
|
|
2021-03-11 17:33:38 +00:00
|
|
|
namespace skvm {
|
|
|
|
class Program;
|
|
|
|
} // namespace skvm
|
|
|
|
|
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:
|
2021-05-05 12:24:03 +00:00
|
|
|
// Reflected description of a uniform variable in the effect's SkSL
|
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,
|
2021-04-01 13:56:07 +00:00
|
|
|
kInt,
|
|
|
|
kInt2,
|
|
|
|
kInt3,
|
|
|
|
kInt4,
|
2019-12-18 16:23:12 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
enum Flags {
|
2021-12-06 15:30:51 +00:00
|
|
|
// Uniform is an declared as an array. 'count' contains array length.
|
|
|
|
kArray_Flag = 0x1,
|
|
|
|
|
|
|
|
// Uniform is declared with layout(color). Colors should be supplied as unpremultiplied,
|
|
|
|
// extended-range (unclamped) sRGB (ie SkColor4f). The uniform will be automatically
|
|
|
|
// transformed to unpremultiplied extended-range working-space colors.
|
|
|
|
kColor_Flag = 0x2,
|
2019-12-18 16:23:12 +00:00
|
|
|
};
|
|
|
|
|
2021-02-03 19:48:41 +00:00
|
|
|
SkString name;
|
|
|
|
size_t offset;
|
|
|
|
Type type;
|
|
|
|
int count;
|
|
|
|
uint32_t flags;
|
|
|
|
|
|
|
|
bool isArray() const { return SkToBool(this->flags & kArray_Flag); }
|
2021-12-06 15:30:51 +00:00
|
|
|
bool isColor() const { return SkToBool(this->flags & kColor_Flag); }
|
2019-12-18 16:23:12 +00:00
|
|
|
size_t sizeInBytes() const;
|
|
|
|
};
|
|
|
|
|
2021-05-05 12:24:03 +00:00
|
|
|
// Reflected description of a uniform child (shader or colorFilter) in the effect's SkSL
|
2021-07-30 18:17:24 +00:00
|
|
|
enum class ChildType {
|
|
|
|
kShader,
|
|
|
|
kColorFilter,
|
|
|
|
kBlender,
|
|
|
|
};
|
Reland "Better first-class shader & color filter support in runtime effects"
This is a reland of adadb95a9f1ef21ccc5264c7d0bdc83b56cf91e9
... adds a temporary workaround for some Android framework code.
Original change's description:
> Better first-class shader & color filter support in runtime effects
>
> This does a few things, because they're all intertwined:
>
> 1) SkRuntimeEffect's API now includes details about children (which Skia
> stage was declared, not just the name). The factories verify that the
> declared types in the SkSL match up with the C++ types being passed.
> Today, we still only support adding children of the same type, so the
> checks are simple. Once we allow mixing types, we'll be testing the
> declared type against the actual C++ type supplied for each slot.
> 2) Adds sample variants that supply the input color to the child. This
> is now the only way to invoke a colorFilter child. Internally, we
> support passing a color when invoking a child shader, but I'm not
> exposing that. It's not clearly part of the semantics of the Skia
> pipeline, and is almost never useful. It also exposes users to
> several inconsistencies (skbug.com/11942).
> 3) Because of #2, it's possible that we can't compute a reusable program
> to filter individual colors. In that case, we don't set the constant
> output for constant input optimization, and filterColor4f falls back
> to the slower base-class implementation.
>
> Bug: skia:11813 skia:11942
> Change-Id: I06c41e1b35056e486f3163a72acf6b9535d7fed4
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/401917
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Mike Klein <mtklein@google.com>
Bug: skia:11813 skia:11942
Change-Id: I2c31b147ed86fa8c4dddefb7066bc1d07fe0d285
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404637
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
2021-04-21 13:57:19 +00:00
|
|
|
|
2021-07-30 18:17:24 +00:00
|
|
|
struct Child {
|
|
|
|
SkString name;
|
|
|
|
ChildType type;
|
|
|
|
int index;
|
Reland "Better first-class shader & color filter support in runtime effects"
This is a reland of adadb95a9f1ef21ccc5264c7d0bdc83b56cf91e9
... adds a temporary workaround for some Android framework code.
Original change's description:
> Better first-class shader & color filter support in runtime effects
>
> This does a few things, because they're all intertwined:
>
> 1) SkRuntimeEffect's API now includes details about children (which Skia
> stage was declared, not just the name). The factories verify that the
> declared types in the SkSL match up with the C++ types being passed.
> Today, we still only support adding children of the same type, so the
> checks are simple. Once we allow mixing types, we'll be testing the
> declared type against the actual C++ type supplied for each slot.
> 2) Adds sample variants that supply the input color to the child. This
> is now the only way to invoke a colorFilter child. Internally, we
> support passing a color when invoking a child shader, but I'm not
> exposing that. It's not clearly part of the semantics of the Skia
> pipeline, and is almost never useful. It also exposes users to
> several inconsistencies (skbug.com/11942).
> 3) Because of #2, it's possible that we can't compute a reusable program
> to filter individual colors. In that case, we don't set the constant
> output for constant input optimization, and filterColor4f falls back
> to the slower base-class implementation.
>
> Bug: skia:11813 skia:11942
> Change-Id: I06c41e1b35056e486f3163a72acf6b9535d7fed4
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/401917
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Mike Klein <mtklein@google.com>
Bug: skia:11813 skia:11942
Change-Id: I2c31b147ed86fa8c4dddefb7066bc1d07fe0d285
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404637
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
2021-04-21 13:57:19 +00:00
|
|
|
};
|
|
|
|
|
2021-07-02 14:17:45 +00:00
|
|
|
class Options {
|
|
|
|
public:
|
2021-03-23 13:25:33 +00:00
|
|
|
// For testing purposes, completely disable the inliner. (Normally, Runtime Effects don't
|
|
|
|
// run the inliner directly, but they still get an inlining pass once they are painted.)
|
|
|
|
bool forceNoInline = false;
|
2021-07-02 14:17:45 +00:00
|
|
|
|
|
|
|
private:
|
|
|
|
friend class SkRuntimeEffect;
|
|
|
|
friend class SkRuntimeEffectPriv;
|
|
|
|
|
|
|
|
// This flag lifts the ES2 restrictions on Runtime Effects that are gated by the
|
|
|
|
// `strictES2Mode` check. Be aware that the software renderer and pipeline-stage effect are
|
|
|
|
// still largely ES3-unaware and can still fail or crash if post-ES2 features are used.
|
|
|
|
// This is only intended for use by tests and certain internally created effects.
|
2021-04-28 19:14:09 +00:00
|
|
|
bool enforceES2Restrictions = true;
|
2021-07-20 17:16:57 +00:00
|
|
|
|
|
|
|
// Similarly: Public SkSL does not allow access to sk_FragCoord. The semantics of that
|
|
|
|
// variable are confusing, and expose clients to implementation details of saveLayer and
|
|
|
|
// image filters.
|
|
|
|
bool allowFragCoord = false;
|
2021-02-03 16:15:20 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
// If the effect is compiled successfully, `effect` will be non-null.
|
|
|
|
// Otherwise, `errorText` will contain the reason for failure.
|
|
|
|
struct Result {
|
|
|
|
sk_sp<SkRuntimeEffect> effect;
|
|
|
|
SkString errorText;
|
|
|
|
};
|
|
|
|
|
2021-04-12 13:49:20 +00:00
|
|
|
// MakeForColorFilter and MakeForShader verify that the SkSL code is valid for those stages of
|
|
|
|
// the Skia pipeline. In all of the signatures described below, color parameters and return
|
|
|
|
// values are flexible. They are listed as being 'vec4', but they can also be 'half4' or
|
|
|
|
// 'float4'. ('vec4' is an alias for 'float4').
|
|
|
|
|
2021-07-20 17:16:57 +00:00
|
|
|
// We can't use a default argument for `options` due to a bug in Clang.
|
|
|
|
// https://bugs.llvm.org/show_bug.cgi?id=36684
|
|
|
|
|
2021-04-12 13:49:20 +00:00
|
|
|
// Color filter SkSL requires an entry point that looks like:
|
|
|
|
// vec4 main(vec4 inColor) { ... }
|
|
|
|
static Result MakeForColorFilter(SkString sksl, const Options&);
|
2021-07-20 17:16:57 +00:00
|
|
|
static Result MakeForColorFilter(SkString sksl) {
|
|
|
|
return MakeForColorFilter(std::move(sksl), Options{});
|
|
|
|
}
|
2021-04-12 13:49:20 +00:00
|
|
|
|
|
|
|
// Shader SkSL requires an entry point that looks like:
|
|
|
|
// vec4 main(vec2 inCoords) { ... }
|
|
|
|
// -or-
|
|
|
|
// vec4 main(vec2 inCoords, vec4 inColor) { ... }
|
|
|
|
//
|
|
|
|
// Most shaders don't use the input color, so that parameter is optional.
|
|
|
|
static Result MakeForShader(SkString sksl, const Options&);
|
2021-07-20 17:16:57 +00:00
|
|
|
static Result MakeForShader(SkString sksl) {
|
|
|
|
return MakeForShader(std::move(sksl), Options{});
|
|
|
|
}
|
2021-04-12 13:49:20 +00:00
|
|
|
|
2021-06-16 15:34:37 +00:00
|
|
|
// Blend SkSL requires an entry point that looks like:
|
|
|
|
// vec4 main(vec4 srcColor, vec4 dstColor) { ... }
|
|
|
|
static Result MakeForBlender(SkString sksl, const Options&);
|
|
|
|
static Result MakeForBlender(SkString sksl) {
|
|
|
|
return MakeForBlender(std::move(sksl), Options{});
|
|
|
|
}
|
2019-12-16 14:17:25 +00:00
|
|
|
|
2021-07-20 17:16:57 +00:00
|
|
|
// DSL entry points
|
|
|
|
static Result MakeForColorFilter(std::unique_ptr<SkSL::Program> program, const Options&);
|
2021-04-16 18:54:43 +00:00
|
|
|
static Result MakeForColorFilter(std::unique_ptr<SkSL::Program> program);
|
|
|
|
|
2021-07-20 17:16:57 +00:00
|
|
|
static Result MakeForShader(std::unique_ptr<SkSL::Program> program, const Options&);
|
2021-04-16 18:54:43 +00:00
|
|
|
static Result MakeForShader(std::unique_ptr<SkSL::Program> program);
|
|
|
|
|
2021-07-20 17:16:57 +00:00
|
|
|
static Result MakeForBlender(std::unique_ptr<SkSL::Program> program, const Options&);
|
2021-06-16 15:34:37 +00:00
|
|
|
static Result MakeForBlender(std::unique_ptr<SkSL::Program> program);
|
|
|
|
|
2021-07-30 15:20:19 +00:00
|
|
|
// Object that allows passing a SkShader, SkColorFilter or SkBlender as a child
|
2021-07-30 18:17:24 +00:00
|
|
|
class ChildPtr {
|
|
|
|
public:
|
2021-07-21 20:58:38 +00:00
|
|
|
ChildPtr() = default;
|
2021-07-30 18:17:24 +00:00
|
|
|
ChildPtr(sk_sp<SkShader> s) : fChild(std::move(s)) {}
|
|
|
|
ChildPtr(sk_sp<SkColorFilter> cf) : fChild(std::move(cf)) {}
|
|
|
|
ChildPtr(sk_sp<SkBlender> b) : fChild(std::move(b)) {}
|
|
|
|
|
|
|
|
skstd::optional<ChildType> type() const;
|
|
|
|
|
|
|
|
SkShader* shader() const;
|
|
|
|
SkColorFilter* colorFilter() const;
|
|
|
|
SkBlender* blender() const;
|
|
|
|
SkFlattenable* flattenable() const { return fChild.get(); }
|
|
|
|
|
|
|
|
private:
|
|
|
|
sk_sp<SkFlattenable> fChild;
|
2021-05-05 12:24:03 +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,
|
2021-03-23 21:04:41 +00:00
|
|
|
bool isOpaque) const;
|
2021-05-05 12:24:03 +00:00
|
|
|
sk_sp<SkShader> makeShader(sk_sp<SkData> uniforms,
|
|
|
|
SkSpan<ChildPtr> children,
|
|
|
|
const SkMatrix* localMatrix,
|
|
|
|
bool isOpaque) const;
|
2019-12-26 13:43:05 +00:00
|
|
|
|
2021-09-28 13:18:49 +00:00
|
|
|
sk_sp<SkImage> makeImage(GrRecordingContext*,
|
|
|
|
sk_sp<SkData> uniforms,
|
|
|
|
SkSpan<ChildPtr> children,
|
|
|
|
const SkMatrix* localMatrix,
|
|
|
|
SkImageInfo resultInfo,
|
|
|
|
bool mipmapped) const;
|
|
|
|
|
2021-03-23 21:04:41 +00:00
|
|
|
sk_sp<SkColorFilter> makeColorFilter(sk_sp<SkData> uniforms) const;
|
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,
|
2020-08-06 14:53:12 +00:00
|
|
|
sk_sp<SkColorFilter> children[],
|
2021-03-23 21:04:41 +00:00
|
|
|
size_t childCount) const;
|
2021-05-05 12:24:03 +00:00
|
|
|
sk_sp<SkColorFilter> makeColorFilter(sk_sp<SkData> uniforms,
|
|
|
|
SkSpan<ChildPtr> children) const;
|
2020-01-02 13:03:40 +00:00
|
|
|
|
2021-07-22 14:13:30 +00:00
|
|
|
sk_sp<SkBlender> makeBlender(sk_sp<SkData> uniforms, SkSpan<ChildPtr> children = {}) const;
|
2021-06-16 15:34:37 +00:00
|
|
|
|
2021-12-07 21:51:41 +00:00
|
|
|
/**
|
|
|
|
* Creates a new Runtime Effect patterned after an already-existing one. The new shader behaves
|
|
|
|
* like the original, but also creates a debug trace of its execution at the requested
|
|
|
|
* coordinate. After painting with this shader, the associated DebugTrace object will contain a
|
|
|
|
* shader execution trace. Call `writeTrace` on the debug trace object to generate a full trace
|
|
|
|
* suitable for a debugger, or call `dump` to emit a human-readable trace.
|
|
|
|
*
|
|
|
|
* Debug traces are only supported on a raster (non-GPU) canvas.
|
|
|
|
|
|
|
|
* Debug traces are currently only supported on shaders. Color filter and blender tracing is a
|
|
|
|
* work-in-progress.
|
|
|
|
*/
|
|
|
|
struct TracedShader {
|
|
|
|
sk_sp<SkShader> shader;
|
|
|
|
sk_sp<SkSL::DebugTrace> debugTrace;
|
|
|
|
};
|
|
|
|
static TracedShader MakeTraced(sk_sp<SkShader> shader, const SkIPoint& traceCoord);
|
|
|
|
|
|
|
|
// Returns the SkSL source of the runtime effect shader.
|
2021-06-28 19:54:59 +00:00
|
|
|
const std::string& source() const;
|
2020-01-08 18:19:58 +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
|
|
|
// 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
|
|
|
|
2021-11-10 19:29:10 +00:00
|
|
|
SkSpan<const Uniform> uniforms() const { return SkMakeSpan(fUniforms); }
|
|
|
|
SkSpan<const Child> children() const { return SkMakeSpan(fChildren); }
|
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
|
|
|
|
Reland "Better first-class shader & color filter support in runtime effects"
This is a reland of adadb95a9f1ef21ccc5264c7d0bdc83b56cf91e9
... adds a temporary workaround for some Android framework code.
Original change's description:
> Better first-class shader & color filter support in runtime effects
>
> This does a few things, because they're all intertwined:
>
> 1) SkRuntimeEffect's API now includes details about children (which Skia
> stage was declared, not just the name). The factories verify that the
> declared types in the SkSL match up with the C++ types being passed.
> Today, we still only support adding children of the same type, so the
> checks are simple. Once we allow mixing types, we'll be testing the
> declared type against the actual C++ type supplied for each slot.
> 2) Adds sample variants that supply the input color to the child. This
> is now the only way to invoke a colorFilter child. Internally, we
> support passing a color when invoking a child shader, but I'm not
> exposing that. It's not clearly part of the semantics of the Skia
> pipeline, and is almost never useful. It also exposes users to
> several inconsistencies (skbug.com/11942).
> 3) Because of #2, it's possible that we can't compute a reusable program
> to filter individual colors. In that case, we don't set the constant
> output for constant input optimization, and filterColor4f falls back
> to the slower base-class implementation.
>
> Bug: skia:11813 skia:11942
> Change-Id: I06c41e1b35056e486f3163a72acf6b9535d7fed4
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/401917
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Mike Klein <mtklein@google.com>
Bug: skia:11813 skia:11942
Change-Id: I2c31b147ed86fa8c4dddefb7066bc1d07fe0d285
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404637
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
2021-04-21 13:57:19 +00:00
|
|
|
// Returns pointer to the named child's description, or nullptr if not found
|
|
|
|
const Child* findChild(const char* name) const;
|
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:
|
2021-04-12 13:49:20 +00:00
|
|
|
enum Flags {
|
2021-07-02 17:25:35 +00:00
|
|
|
kUsesSampleCoords_Flag = 0x1,
|
|
|
|
kAllowColorFilter_Flag = 0x2,
|
|
|
|
kAllowShader_Flag = 0x4,
|
|
|
|
kAllowBlender_Flag = 0x8,
|
|
|
|
kSamplesOutsideMain_Flag = 0x10,
|
2021-04-12 13:49:20 +00:00
|
|
|
};
|
|
|
|
|
2021-06-28 19:54:59 +00:00
|
|
|
SkRuntimeEffect(std::unique_ptr<SkSL::Program> baseProgram,
|
2021-03-23 13:14:58 +00:00
|
|
|
const Options& options,
|
2020-12-02 16:12:51 +00:00
|
|
|
const SkSL::FunctionDefinition& main,
|
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,
|
Reland "Better first-class shader & color filter support in runtime effects"
This is a reland of adadb95a9f1ef21ccc5264c7d0bdc83b56cf91e9
... adds a temporary workaround for some Android framework code.
Original change's description:
> Better first-class shader & color filter support in runtime effects
>
> This does a few things, because they're all intertwined:
>
> 1) SkRuntimeEffect's API now includes details about children (which Skia
> stage was declared, not just the name). The factories verify that the
> declared types in the SkSL match up with the C++ types being passed.
> Today, we still only support adding children of the same type, so the
> checks are simple. Once we allow mixing types, we'll be testing the
> declared type against the actual C++ type supplied for each slot.
> 2) Adds sample variants that supply the input color to the child. This
> is now the only way to invoke a colorFilter child. Internally, we
> support passing a color when invoking a child shader, but I'm not
> exposing that. It's not clearly part of the semantics of the Skia
> pipeline, and is almost never useful. It also exposes users to
> several inconsistencies (skbug.com/11942).
> 3) Because of #2, it's possible that we can't compute a reusable program
> to filter individual colors. In that case, we don't set the constant
> output for constant input optimization, and filterColor4f falls back
> to the slower base-class implementation.
>
> Bug: skia:11813 skia:11942
> Change-Id: I06c41e1b35056e486f3163a72acf6b9535d7fed4
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/401917
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Mike Klein <mtklein@google.com>
Bug: skia:11813 skia:11942
Change-Id: I2c31b147ed86fa8c4dddefb7066bc1d07fe0d285
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404637
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
2021-04-21 13:57:19 +00:00
|
|
|
std::vector<Child>&& children,
|
2020-06-30 17:39:35 +00:00
|
|
|
std::vector<SkSL::SampleUsage>&& sampleUsages,
|
2021-04-12 13:49:20 +00:00
|
|
|
uint32_t flags);
|
|
|
|
|
2021-07-20 17:16:57 +00:00
|
|
|
static Result MakeFromSource(SkString sksl, const Options& options, SkSL::ProgramKind kind);
|
2021-04-16 18:54:43 +00:00
|
|
|
|
2021-07-20 17:16:57 +00:00
|
|
|
static Result MakeFromDSL(std::unique_ptr<SkSL::Program> program,
|
|
|
|
const Options& options,
|
|
|
|
SkSL::ProgramKind kind);
|
2020-04-15 18:18:13 +00:00
|
|
|
|
2021-07-20 17:16:57 +00:00
|
|
|
static Result MakeInternal(std::unique_ptr<SkSL::Program> program,
|
|
|
|
const Options& options,
|
|
|
|
SkSL::ProgramKind kind);
|
2021-04-16 18:54:43 +00:00
|
|
|
|
2020-08-31 18:57:58 +00:00
|
|
|
uint32_t hash() const { return fHash; }
|
2021-07-02 17:25:35 +00:00
|
|
|
bool usesSampleCoords() const { return (fFlags & kUsesSampleCoords_Flag); }
|
|
|
|
bool allowShader() const { return (fFlags & kAllowShader_Flag); }
|
|
|
|
bool allowColorFilter() const { return (fFlags & kAllowColorFilter_Flag); }
|
|
|
|
bool allowBlender() const { return (fFlags & kAllowBlender_Flag); }
|
|
|
|
bool samplesOutsideMain() const { return (fFlags & kSamplesOutsideMain_Flag); }
|
2020-08-31 18:57:58 +00:00
|
|
|
|
2021-05-12 20:53:19 +00:00
|
|
|
const SkFilterColorProgram* getFilterColorProgram();
|
2021-03-22 15:44:03 +00:00
|
|
|
|
2019-12-16 14:17:25 +00:00
|
|
|
#if SK_SUPPORT_GPU
|
2021-04-28 13:41:06 +00:00
|
|
|
friend class GrSkSLFP; // fBaseProgram, fSampleUsages
|
|
|
|
friend class GrGLSLSkSLFP; //
|
2019-12-16 14:17:25 +00:00
|
|
|
#endif
|
|
|
|
|
2020-12-02 16:12:51 +00:00
|
|
|
friend class SkRTShader; // fBaseProgram, fMain
|
2021-06-17 02:37:15 +00:00
|
|
|
friend class SkRuntimeBlender; //
|
2020-04-15 18:18:13 +00:00
|
|
|
friend class SkRuntimeColorFilter; //
|
|
|
|
|
2021-05-12 20:53:19 +00:00
|
|
|
friend class SkFilterColorProgram;
|
2021-06-18 13:41:15 +00:00
|
|
|
friend class SkRuntimeEffectPriv;
|
2021-05-12 20:53:19 +00:00
|
|
|
|
2020-02-05 16:37:08 +00:00
|
|
|
uint32_t fHash;
|
2019-12-16 14:17:25 +00:00
|
|
|
|
|
|
|
std::unique_ptr<SkSL::Program> fBaseProgram;
|
2020-12-02 16:12:51 +00:00
|
|
|
const SkSL::FunctionDefinition& fMain;
|
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;
|
Reland "Better first-class shader & color filter support in runtime effects"
This is a reland of adadb95a9f1ef21ccc5264c7d0bdc83b56cf91e9
... adds a temporary workaround for some Android framework code.
Original change's description:
> Better first-class shader & color filter support in runtime effects
>
> This does a few things, because they're all intertwined:
>
> 1) SkRuntimeEffect's API now includes details about children (which Skia
> stage was declared, not just the name). The factories verify that the
> declared types in the SkSL match up with the C++ types being passed.
> Today, we still only support adding children of the same type, so the
> checks are simple. Once we allow mixing types, we'll be testing the
> declared type against the actual C++ type supplied for each slot.
> 2) Adds sample variants that supply the input color to the child. This
> is now the only way to invoke a colorFilter child. Internally, we
> support passing a color when invoking a child shader, but I'm not
> exposing that. It's not clearly part of the semantics of the Skia
> pipeline, and is almost never useful. It also exposes users to
> several inconsistencies (skbug.com/11942).
> 3) Because of #2, it's possible that we can't compute a reusable program
> to filter individual colors. In that case, we don't set the constant
> output for constant input optimization, and filterColor4f falls back
> to the slower base-class implementation.
>
> Bug: skia:11813 skia:11942
> Change-Id: I06c41e1b35056e486f3163a72acf6b9535d7fed4
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/401917
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Mike Klein <mtklein@google.com>
Bug: skia:11813 skia:11942
Change-Id: I2c31b147ed86fa8c4dddefb7066bc1d07fe0d285
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404637
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
2021-04-21 13:57:19 +00:00
|
|
|
std::vector<Child> fChildren;
|
2020-06-30 17:39:35 +00:00
|
|
|
std::vector<SkSL::SampleUsage> fSampleUsages;
|
2020-01-10 15:05:24 +00:00
|
|
|
|
2021-05-12 20:53:19 +00:00
|
|
|
std::unique_ptr<SkFilterColorProgram> fFilterColorProgram;
|
2021-03-11 17:33:38 +00:00
|
|
|
|
2021-04-12 13:49:20 +00:00
|
|
|
uint32_t fFlags; // Flags
|
2019-12-16 14:17:25 +00:00
|
|
|
};
|
|
|
|
|
2021-03-23 21:04:41 +00:00
|
|
|
/** Base class for SkRuntimeShaderBuilder, defined below. */
|
2021-07-21 20:58:38 +00:00
|
|
|
class SkRuntimeEffectBuilder {
|
2020-08-27 14:51:22 +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 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 {
|
2021-02-03 19:48:41 +00:00
|
|
|
memcpy(SkTAddOffset<void>(fOwner->writableUniformData(), fVar->offset),
|
2020-08-27 14:51:22 +00:00
|
|
|
&val, sizeof(val));
|
2020-04-15 18:18:13 +00:00
|
|
|
}
|
|
|
|
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 {
|
2021-07-21 20:58:38 +00:00
|
|
|
float* data = SkTAddOffset<float>(fOwner->writableUniformData(),
|
|
|
|
(ptrdiff_t)fVar->offset);
|
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;
|
|
|
|
}
|
|
|
|
|
2021-01-14 13:30:52 +00:00
|
|
|
template <typename T>
|
|
|
|
bool set(const T val[], const int count) {
|
|
|
|
static_assert(std::is_trivially_copyable<T>::value, "Value must be trivial copyable");
|
|
|
|
if (!fVar) {
|
|
|
|
SkDEBUGFAIL("Assigning to missing variable");
|
|
|
|
return false;
|
|
|
|
} else if (sizeof(T) * count != fVar->sizeInBytes()) {
|
|
|
|
SkDEBUGFAIL("Incorrect value size");
|
|
|
|
return false;
|
|
|
|
} else {
|
2021-02-03 19:48:41 +00:00
|
|
|
memcpy(SkTAddOffset<void>(fOwner->writableUniformData(), fVar->offset),
|
2021-01-14 13:30:52 +00:00
|
|
|
val, sizeof(T) * count);
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2021-03-23 21:04:41 +00:00
|
|
|
SkRuntimeEffectBuilder* fOwner;
|
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
|
|
|
const SkRuntimeEffect::Uniform* fVar; // nullptr if the variable was not found
|
2020-04-15 18:18:13 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct BuilderChild {
|
2021-07-21 20:58:38 +00:00
|
|
|
template <typename T> BuilderChild& operator=(sk_sp<T> val) {
|
Reland "Better first-class shader & color filter support in runtime effects"
This is a reland of adadb95a9f1ef21ccc5264c7d0bdc83b56cf91e9
... adds a temporary workaround for some Android framework code.
Original change's description:
> Better first-class shader & color filter support in runtime effects
>
> This does a few things, because they're all intertwined:
>
> 1) SkRuntimeEffect's API now includes details about children (which Skia
> stage was declared, not just the name). The factories verify that the
> declared types in the SkSL match up with the C++ types being passed.
> Today, we still only support adding children of the same type, so the
> checks are simple. Once we allow mixing types, we'll be testing the
> declared type against the actual C++ type supplied for each slot.
> 2) Adds sample variants that supply the input color to the child. This
> is now the only way to invoke a colorFilter child. Internally, we
> support passing a color when invoking a child shader, but I'm not
> exposing that. It's not clearly part of the semantics of the Skia
> pipeline, and is almost never useful. It also exposes users to
> several inconsistencies (skbug.com/11942).
> 3) Because of #2, it's possible that we can't compute a reusable program
> to filter individual colors. In that case, we don't set the constant
> output for constant input optimization, and filterColor4f falls back
> to the slower base-class implementation.
>
> Bug: skia:11813 skia:11942
> Change-Id: I06c41e1b35056e486f3163a72acf6b9535d7fed4
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/401917
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Mike Klein <mtklein@google.com>
Bug: skia:11813 skia:11942
Change-Id: I2c31b147ed86fa8c4dddefb7066bc1d07fe0d285
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404637
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
2021-04-21 13:57:19 +00:00
|
|
|
if (!fChild) {
|
2021-03-23 21:04:41 +00:00
|
|
|
SkDEBUGFAIL("Assigning to missing child");
|
|
|
|
} else {
|
2021-07-21 20:58:38 +00:00
|
|
|
fOwner->fChildren[(size_t)fChild->index] = std::move(val);
|
|
|
|
}
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
BuilderChild& operator=(std::nullptr_t) {
|
|
|
|
if (!fChild) {
|
|
|
|
SkDEBUGFAIL("Assigning to missing child");
|
|
|
|
} else {
|
|
|
|
fOwner->fChildren[(size_t)fChild->index] = SkRuntimeEffect::ChildPtr{};
|
2021-03-23 21:04:41 +00:00
|
|
|
}
|
|
|
|
return *this;
|
|
|
|
}
|
2020-04-15 18:18:13 +00:00
|
|
|
|
Reland "Better first-class shader & color filter support in runtime effects"
This is a reland of adadb95a9f1ef21ccc5264c7d0bdc83b56cf91e9
... adds a temporary workaround for some Android framework code.
Original change's description:
> Better first-class shader & color filter support in runtime effects
>
> This does a few things, because they're all intertwined:
>
> 1) SkRuntimeEffect's API now includes details about children (which Skia
> stage was declared, not just the name). The factories verify that the
> declared types in the SkSL match up with the C++ types being passed.
> Today, we still only support adding children of the same type, so the
> checks are simple. Once we allow mixing types, we'll be testing the
> declared type against the actual C++ type supplied for each slot.
> 2) Adds sample variants that supply the input color to the child. This
> is now the only way to invoke a colorFilter child. Internally, we
> support passing a color when invoking a child shader, but I'm not
> exposing that. It's not clearly part of the semantics of the Skia
> pipeline, and is almost never useful. It also exposes users to
> several inconsistencies (skbug.com/11942).
> 3) Because of #2, it's possible that we can't compute a reusable program
> to filter individual colors. In that case, we don't set the constant
> output for constant input optimization, and filterColor4f falls back
> to the slower base-class implementation.
>
> Bug: skia:11813 skia:11942
> Change-Id: I06c41e1b35056e486f3163a72acf6b9535d7fed4
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/401917
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Mike Klein <mtklein@google.com>
Bug: skia:11813 skia:11942
Change-Id: I2c31b147ed86fa8c4dddefb7066bc1d07fe0d285
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404637
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
2021-04-21 13:57:19 +00:00
|
|
|
SkRuntimeEffectBuilder* fOwner;
|
|
|
|
const SkRuntimeEffect::Child* fChild; // nullptr if the child was not found
|
2020-04-15 18:18:13 +00:00
|
|
|
};
|
|
|
|
|
2020-08-27 14:51:22 +00:00
|
|
|
const SkRuntimeEffect* effect() const { return fEffect.get(); }
|
|
|
|
|
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) }; }
|
Reland "Better first-class shader & color filter support in runtime effects"
This is a reland of adadb95a9f1ef21ccc5264c7d0bdc83b56cf91e9
... adds a temporary workaround for some Android framework code.
Original change's description:
> Better first-class shader & color filter support in runtime effects
>
> This does a few things, because they're all intertwined:
>
> 1) SkRuntimeEffect's API now includes details about children (which Skia
> stage was declared, not just the name). The factories verify that the
> declared types in the SkSL match up with the C++ types being passed.
> Today, we still only support adding children of the same type, so the
> checks are simple. Once we allow mixing types, we'll be testing the
> declared type against the actual C++ type supplied for each slot.
> 2) Adds sample variants that supply the input color to the child. This
> is now the only way to invoke a colorFilter child. Internally, we
> support passing a color when invoking a child shader, but I'm not
> exposing that. It's not clearly part of the semantics of the Skia
> pipeline, and is almost never useful. It also exposes users to
> several inconsistencies (skbug.com/11942).
> 3) Because of #2, it's possible that we can't compute a reusable program
> to filter individual colors. In that case, we don't set the constant
> output for constant input optimization, and filterColor4f falls back
> to the slower base-class implementation.
>
> Bug: skia:11813 skia:11942
> Change-Id: I06c41e1b35056e486f3163a72acf6b9535d7fed4
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/401917
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Mike Klein <mtklein@google.com>
Bug: skia:11813 skia:11942
Change-Id: I2c31b147ed86fa8c4dddefb7066bc1d07fe0d285
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404637
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
2021-04-21 13:57:19 +00:00
|
|
|
BuilderChild child(const char* name) {
|
|
|
|
const SkRuntimeEffect::Child* child = fEffect->findChild(name);
|
2021-09-09 14:54:57 +00:00
|
|
|
return { this, child };
|
Reland "Better first-class shader & color filter support in runtime effects"
This is a reland of adadb95a9f1ef21ccc5264c7d0bdc83b56cf91e9
... adds a temporary workaround for some Android framework code.
Original change's description:
> Better first-class shader & color filter support in runtime effects
>
> This does a few things, because they're all intertwined:
>
> 1) SkRuntimeEffect's API now includes details about children (which Skia
> stage was declared, not just the name). The factories verify that the
> declared types in the SkSL match up with the C++ types being passed.
> Today, we still only support adding children of the same type, so the
> checks are simple. Once we allow mixing types, we'll be testing the
> declared type against the actual C++ type supplied for each slot.
> 2) Adds sample variants that supply the input color to the child. This
> is now the only way to invoke a colorFilter child. Internally, we
> support passing a color when invoking a child shader, but I'm not
> exposing that. It's not clearly part of the semantics of the Skia
> pipeline, and is almost never useful. It also exposes users to
> several inconsistencies (skbug.com/11942).
> 3) Because of #2, it's possible that we can't compute a reusable program
> to filter individual colors. In that case, we don't set the constant
> output for constant input optimization, and filterColor4f falls back
> to the slower base-class implementation.
>
> Bug: skia:11813 skia:11942
> Change-Id: I06c41e1b35056e486f3163a72acf6b9535d7fed4
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/401917
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Mike Klein <mtklein@google.com>
Bug: skia:11813 skia:11942
Change-Id: I2c31b147ed86fa8c4dddefb7066bc1d07fe0d285
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404637
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
2021-04-21 13:57:19 +00:00
|
|
|
}
|
2020-04-15 18:18:13 +00:00
|
|
|
|
2021-03-23 21:04:41 +00:00
|
|
|
protected:
|
|
|
|
SkRuntimeEffectBuilder() = delete;
|
|
|
|
explicit SkRuntimeEffectBuilder(sk_sp<SkRuntimeEffect> effect)
|
|
|
|
: fEffect(std::move(effect))
|
2021-11-18 15:13:29 +00:00
|
|
|
, fUniforms(SkData::MakeZeroInitialized(fEffect->uniformSize()))
|
2021-11-10 19:29:10 +00:00
|
|
|
, fChildren(fEffect->children().size()) {}
|
2021-11-29 21:41:31 +00:00
|
|
|
explicit SkRuntimeEffectBuilder(sk_sp<SkRuntimeEffect> effect, sk_sp<SkData> uniforms)
|
|
|
|
: fEffect(std::move(effect))
|
|
|
|
, fUniforms(std::move(uniforms))
|
|
|
|
, fChildren(fEffect->children().size()) {}
|
2021-03-23 21:04:41 +00:00
|
|
|
|
|
|
|
SkRuntimeEffectBuilder(SkRuntimeEffectBuilder&&) = default;
|
|
|
|
SkRuntimeEffectBuilder(const SkRuntimeEffectBuilder&) = default;
|
|
|
|
|
|
|
|
SkRuntimeEffectBuilder& operator=(SkRuntimeEffectBuilder&&) = delete;
|
|
|
|
SkRuntimeEffectBuilder& operator=(const SkRuntimeEffectBuilder&) = delete;
|
|
|
|
|
|
|
|
sk_sp<SkData> uniforms() { return fUniforms; }
|
2021-07-21 20:58:38 +00:00
|
|
|
SkRuntimeEffect::ChildPtr* children() { return fChildren.data(); }
|
2021-03-23 21:04:41 +00:00
|
|
|
size_t numChildren() { return fChildren.size(); }
|
|
|
|
|
|
|
|
private:
|
|
|
|
void* writableUniformData() {
|
|
|
|
if (!fUniforms->unique()) {
|
|
|
|
fUniforms = SkData::MakeWithCopy(fUniforms->data(), fUniforms->size());
|
|
|
|
}
|
|
|
|
return fUniforms->writable_data();
|
|
|
|
}
|
|
|
|
|
2021-07-21 20:58:38 +00:00
|
|
|
sk_sp<SkRuntimeEffect> fEffect;
|
|
|
|
sk_sp<SkData> fUniforms;
|
|
|
|
std::vector<SkRuntimeEffect::ChildPtr> fChildren;
|
2021-03-23 21:04:41 +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
|
|
|
|
* provides named access to the 'uniform' variables in that block, as well as named access
|
|
|
|
* to a list of child shader slots. Usage:
|
|
|
|
*
|
|
|
|
* sk_sp<SkRuntimeEffect> effect = ...;
|
|
|
|
* SkRuntimeShaderBuilder builder(effect);
|
|
|
|
* builder.uniform("some_uniform_float") = 3.14f;
|
|
|
|
* builder.uniform("some_uniform_matrix") = SkM44::Rotate(...);
|
|
|
|
* 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.
|
|
|
|
*/
|
2021-07-21 20:58:38 +00:00
|
|
|
class SK_API SkRuntimeShaderBuilder : public SkRuntimeEffectBuilder {
|
2021-03-23 21:04:41 +00:00
|
|
|
public:
|
|
|
|
explicit SkRuntimeShaderBuilder(sk_sp<SkRuntimeEffect>);
|
|
|
|
// This is currently required by Android Framework but may go away if that dependency
|
|
|
|
// can be removed.
|
|
|
|
SkRuntimeShaderBuilder(const SkRuntimeShaderBuilder&) = default;
|
|
|
|
~SkRuntimeShaderBuilder();
|
|
|
|
|
2020-04-15 18:18:13 +00:00
|
|
|
sk_sp<SkShader> makeShader(const SkMatrix* localMatrix, bool isOpaque);
|
2021-09-28 13:18:49 +00:00
|
|
|
sk_sp<SkImage> makeImage(GrRecordingContext*,
|
|
|
|
const SkMatrix* localMatrix,
|
|
|
|
SkImageInfo resultInfo,
|
|
|
|
bool mipmapped);
|
2020-04-15 18:18:13 +00:00
|
|
|
|
2020-08-27 14:51:22 +00:00
|
|
|
private:
|
2021-07-21 20:58:38 +00:00
|
|
|
using INHERITED = SkRuntimeEffectBuilder;
|
2021-11-29 21:41:31 +00:00
|
|
|
|
|
|
|
explicit SkRuntimeShaderBuilder(sk_sp<SkRuntimeEffect> effect, sk_sp<SkData> uniforms)
|
|
|
|
: INHERITED(std::move(effect), std::move(uniforms)) {}
|
|
|
|
|
|
|
|
friend class SkRuntimeImageFilter;
|
2020-04-15 18:18:13 +00:00
|
|
|
};
|
|
|
|
|
2021-06-17 02:37:15 +00:00
|
|
|
/**
|
|
|
|
* SkRuntimeBlendBuilder is a utility to simplify creation and uniform setup of runtime blenders.
|
|
|
|
*/
|
2021-07-21 20:58:38 +00:00
|
|
|
class SK_API SkRuntimeBlendBuilder : public SkRuntimeEffectBuilder {
|
2021-06-17 02:37:15 +00:00
|
|
|
public:
|
|
|
|
explicit SkRuntimeBlendBuilder(sk_sp<SkRuntimeEffect>);
|
|
|
|
~SkRuntimeBlendBuilder();
|
|
|
|
|
|
|
|
SkRuntimeBlendBuilder(const SkRuntimeBlendBuilder&) = delete;
|
|
|
|
SkRuntimeBlendBuilder& operator=(const SkRuntimeBlendBuilder&) = delete;
|
|
|
|
|
|
|
|
sk_sp<SkBlender> makeBlender();
|
|
|
|
|
|
|
|
private:
|
2021-07-21 20:58:38 +00:00
|
|
|
using INHERITED = SkRuntimeEffectBuilder;
|
2021-06-17 02:37:15 +00:00
|
|
|
};
|
|
|
|
|
2021-07-12 21:02:21 +00:00
|
|
|
#endif // SK_ENABLE_SKSL
|
|
|
|
|
|
|
|
#endif // SkRuntimeEffect_DEFINED
|