AuroraMiddleware/skia2
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
c6260f9742
skia2/tests/sksl/fp/GrNestedCall.cpp

70 lines
2.9 KiB
C++
Raw Normal View History

Add unit test for nested function calls in FP files. `func1` and `func2` emit bad code, `return %s()`, and because they don't consume their `%s` format argument. This leaves the format argument list unbalanced and all future args are wrong. Another serious problem is that we don't actually know the names of the functions that they need to call, because we haven't emitted them yet. `func3` is not emitted at all. Sampling from a fragment processor apparently fails in this context. This is a more general case repro for skia:10684--it turns out that recursion in particular wasn't the issue, but nested function calls just don't work properly at all in FP files. This wasn't an issue in practice because we don't have any existing FP files which nest function calls, and the inliner also tends to aggressively flatten everything out if we don't explicitly disable it. Change-Id: Iff029c459c7d90be566f9b4c9be0e3150e459866 Bug: skia:10684 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/329367 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com> Auto-Submit: John Stiles <johnstiles@google.com>
2020-10-23 17:45:57 +00:00
/*#pragma settings NoInline*/
/**************************************************************************************************
*** This file was autogenerated from GrNestedCall.fp; do not modify.
**************************************************************************************************/
#include "GrNestedCall.h"
#include "src/core/SkUtils.h"
#include "src/gpu/GrTexture.h"
#include "src/gpu/glsl/GrGLSLFragmentProcessor.h"
#include "src/gpu/glsl/GrGLSLFragmentShaderBuilder.h"
#include "src/gpu/glsl/GrGLSLProgramBuilder.h"
#include "src/sksl/SkSLCPP.h"
#include "src/sksl/SkSLUtil.h"
class GrGLSLNestedCall : public GrGLSLFragmentProcessor {
public:
GrGLSLNestedCall() {}
void emitCode(EmitArgs& args) override {
GrGLSLFPFragmentBuilder* fragBuilder = args.fFragBuilder;
const GrNestedCall& _outer = args.fFp.cast<GrNestedCall>();
(void) _outer;
Mangle function names as a separate step before emitting func-bodies. This is necessary to support function calls in FP files properly; in some cases, functions can be referenced before they have been emitted, and we need to be able to name them. This CL resolves the remaining errors in GrRecursion.cpp. There are still additional errors in GrNestedCall.cpp that will be fixed in followup CLs. Change-Id: Iec98ef02ea6a98a9945a4e0e3cfa3537dff01305 Bug: skia:10684, skia:10872 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/329676 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com> Auto-Submit: John Stiles <johnstiles@google.com>
2020-10-26 21:53:06 +00:00
SkString func1_name = fragBuilder->getMangledFunctionName("func1");
Prototype helper functions from FP files before use. GLSL requires that functions are declared before first use. In most cases, we avoid the requirement for explicit prototypes by this by strategically ordering our functions within the emitted code, but an FP file might reference its helper functions in any order or have helper functions that cross-invoke each other, so prototypes should be emitted. Change-Id: I3b9e9c9ec4bd5be90b4f71f8165af45364facf30 Bug: skia:10872 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/329781 Commit-Queue: John Stiles <johnstiles@google.com> Auto-Submit: John Stiles <johnstiles@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2020-10-27 13:42:03 +00:00
const GrShaderVar func1_args[] = { };
SkString func2_name = fragBuilder->getMangledFunctionName("func2");
const GrShaderVar func2_args[] = { };
SkString func3_name = fragBuilder->getMangledFunctionName("func3");
const GrShaderVar func3_args[] = { };
Improve support for function prototypes in SkSL. Previously, when a prototype was parsed, this added a function declaration to the symbol table, but the prototype itself was not re-emitted during code generation. This meant that the final code might not be valid, since the absence of prototypes meant that the code might attempt to invoke a function before its declaration. Now, prototypes are stored in the ProgramElement list and re-emitted during code generation for GLSL/Metal/CPP. (SPIR-V doesn't name its functions at all.) Change-Id: I76446c796000eb0b56f964d82457122182c28b87 Bug: skia:10872 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/331136 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com> Auto-Submit: John Stiles <johnstiles@google.com>
2020-11-03 17:18:22 +00:00
fragBuilder->emitFunctionPrototype(kHalf4_GrSLType, func1_name.c_str(), {func1_args, 0});
fragBuilder->emitFunctionPrototype(kHalf4_GrSLType, func2_name.c_str(), {func2_args, 0});
Pass function arguments using SkSpan instead of count + ptr. There's no functional change here; it's just using a slightly higher- level abstraction to pass the same payload. Change-Id: Ife7efa038db5d6dbde5decae2be79ad9db877aba Reviewed-on: https://skia-review.googlesource.com/c/skia/+/329782 Commit-Queue: John Stiles <johnstiles@google.com> Auto-Submit: John Stiles <johnstiles@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2020-10-27 13:45:40 +00:00
fragBuilder->emitFunctionPrototype(kHalf4_GrSLType, func3_name.c_str(), {func3_args, 0});
Add support for fFormatArgs in .fp-file inner functions. Previously, we'd just emit functions with `%s` in their function bodies. Also, the fFormatArgs wouldn't get cleaned up, so subsequent code would fill in the wrong format arguments in each place. There are still problems with function calls (`sample` is broken; function names are accessed before they've been declared or initialized) but this is a step in the right direction. Bug: skia:10684 Change-Id: I7399a71d44ebba5049703484ec9933dffbe8e2b9 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/329417 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: John Stiles <johnstiles@google.com> Auto-Submit: John Stiles <johnstiles@google.com>
2020-10-26 15:25:37 +00:00
const String func1_impl = String::printf(R"SkSL(return %s();
)SkSL"
, func2_name.c_str());
Pass function arguments using SkSpan instead of count + ptr. There's no functional change here; it's just using a slightly higher- level abstraction to pass the same payload. Change-Id: Ife7efa038db5d6dbde5decae2be79ad9db877aba Reviewed-on: https://skia-review.googlesource.com/c/skia/+/329782 Commit-Queue: John Stiles <johnstiles@google.com> Auto-Submit: John Stiles <johnstiles@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2020-10-27 13:45:40 +00:00
fragBuilder->emitFunction(kHalf4_GrSLType, func1_name.c_str(), {func1_args, 0}, func1_impl.c_str());
Add support for fFormatArgs in .fp-file inner functions. Previously, we'd just emit functions with `%s` in their function bodies. Also, the fFormatArgs wouldn't get cleaned up, so subsequent code would fill in the wrong format arguments in each place. There are still problems with function calls (`sample` is broken; function names are accessed before they've been declared or initialized) but this is a step in the right direction. Bug: skia:10684 Change-Id: I7399a71d44ebba5049703484ec9933dffbe8e2b9 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/329417 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: John Stiles <johnstiles@google.com> Auto-Submit: John Stiles <johnstiles@google.com>
2020-10-26 15:25:37 +00:00
const String func2_impl = String::printf(R"SkSL(return %s();
)SkSL"
, func3_name.c_str());
Pass function arguments using SkSpan instead of count + ptr. There's no functional change here; it's just using a slightly higher- level abstraction to pass the same payload. Change-Id: Ife7efa038db5d6dbde5decae2be79ad9db877aba Reviewed-on: https://skia-review.googlesource.com/c/skia/+/329782 Commit-Queue: John Stiles <johnstiles@google.com> Auto-Submit: John Stiles <johnstiles@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2020-10-27 13:45:40 +00:00
fragBuilder->emitFunction(kHalf4_GrSLType, func2_name.c_str(), {func2_args, 0}, func2_impl.c_str());
Add unit test for nested function calls in FP files. `func1` and `func2` emit bad code, `return %s()`, and because they don't consume their `%s` format argument. This leaves the format argument list unbalanced and all future args are wrong. Another serious problem is that we don't actually know the names of the functions that they need to call, because we haven't emitted them yet. `func3` is not emitted at all. Sampling from a fragment processor apparently fails in this context. This is a more general case repro for skia:10684--it turns out that recursion in particular wasn't the issue, but nested function calls just don't work properly at all in FP files. This wasn't an issue in practice because we don't have any existing FP files which nest function calls, and the inliner also tends to aggressively flatten everything out if we don't explicitly disable it. Change-Id: Iff029c459c7d90be566f9b4c9be0e3150e459866 Bug: skia:10684 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/329367 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com> Auto-Submit: John Stiles <johnstiles@google.com>
2020-10-23 17:45:57 +00:00
fragBuilder->codeAppendf(
Remove sk_OutColor usage from .fp unit tests. Change-Id: Ief2a60fccdffcb8a0cf785a5adcca5d3e1172b49 Bug: skia:10549 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/344298 Reviewed-by: Ethan Nicholas <ethannicholas@google.com> Commit-Queue: John Stiles <johnstiles@google.com> Auto-Submit: John Stiles <johnstiles@google.com>
2020-12-15 14:44:51 +00:00
R"SkSL(return %s();
Add unit test for nested function calls in FP files. `func1` and `func2` emit bad code, `return %s()`, and because they don't consume their `%s` format argument. This leaves the format argument list unbalanced and all future args are wrong. Another serious problem is that we don't actually know the names of the functions that they need to call, because we haven't emitted them yet. `func3` is not emitted at all. Sampling from a fragment processor apparently fails in this context. This is a more general case repro for skia:10684--it turns out that recursion in particular wasn't the issue, but nested function calls just don't work properly at all in FP files. This wasn't an issue in practice because we don't have any existing FP files which nest function calls, and the inliner also tends to aggressively flatten everything out if we don't explicitly disable it. Change-Id: Iff029c459c7d90be566f9b4c9be0e3150e459866 Bug: skia:10684 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/329367 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com> Auto-Submit: John Stiles <johnstiles@google.com>
2020-10-23 17:45:57 +00:00
)SkSL"
Remove sk_OutColor usage from .fp unit tests. Change-Id: Ief2a60fccdffcb8a0cf785a5adcca5d3e1172b49 Bug: skia:10549 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/344298 Reviewed-by: Ethan Nicholas <ethannicholas@google.com> Commit-Queue: John Stiles <johnstiles@google.com> Auto-Submit: John Stiles <johnstiles@google.com>
2020-12-15 14:44:51 +00:00
, func1_name.c_str());
Add unit test for nested function calls in FP files. `func1` and `func2` emit bad code, `return %s()`, and because they don't consume their `%s` format argument. This leaves the format argument list unbalanced and all future args are wrong. Another serious problem is that we don't actually know the names of the functions that they need to call, because we haven't emitted them yet. `func3` is not emitted at all. Sampling from a fragment processor apparently fails in this context. This is a more general case repro for skia:10684--it turns out that recursion in particular wasn't the issue, but nested function calls just don't work properly at all in FP files. This wasn't an issue in practice because we don't have any existing FP files which nest function calls, and the inliner also tends to aggressively flatten everything out if we don't explicitly disable it. Change-Id: Iff029c459c7d90be566f9b4c9be0e3150e459866 Bug: skia:10684 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/329367 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com> Auto-Submit: John Stiles <johnstiles@google.com>
2020-10-23 17:45:57 +00:00
}
private:
void onSetData(const GrGLSLProgramDataManager& pdman, const GrFragmentProcessor& _proc) override {
}
};
Make GrGLSLFragmentProcessors be created as std::unique_ptr. Rename factory function from createGLSLInstance() to makeProgramImpl() Bug: b/180759848 Bug: skia:11358 Change-Id: I095bdf1f26db5a8192fa8ab59000db4a1d561d96 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/373738 Reviewed-by: John Stiles <johnstiles@google.com> Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Salomon <bsalomon@google.com>
2021-02-23 15:07:05 +00:00
std::unique_ptr<GrGLSLFragmentProcessor> GrNestedCall::onMakeProgramImpl() const {
return std::make_unique<GrGLSLNestedCall>();
Add unit test for nested function calls in FP files. `func1` and `func2` emit bad code, `return %s()`, and because they don't consume their `%s` format argument. This leaves the format argument list unbalanced and all future args are wrong. Another serious problem is that we don't actually know the names of the functions that they need to call, because we haven't emitted them yet. `func3` is not emitted at all. Sampling from a fragment processor apparently fails in this context. This is a more general case repro for skia:10684--it turns out that recursion in particular wasn't the issue, but nested function calls just don't work properly at all in FP files. This wasn't an issue in practice because we don't have any existing FP files which nest function calls, and the inliner also tends to aggressively flatten everything out if we don't explicitly disable it. Change-Id: Iff029c459c7d90be566f9b4c9be0e3150e459866 Bug: skia:10684 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/329367 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com> Auto-Submit: John Stiles <johnstiles@google.com>
2020-10-23 17:45:57 +00:00
}
void GrNestedCall::onGetGLSLProcessorKey(const GrShaderCaps& caps, GrProcessorKeyBuilder* b) const {
}
bool GrNestedCall::onIsEqual(const GrFragmentProcessor& other) const {
const GrNestedCall& that = other.cast<GrNestedCall>();
(void) that;
return true;
}
GrNestedCall::GrNestedCall(const GrNestedCall& src)
: INHERITED(kGrNestedCall_ClassID, src.optimizationFlags()) {
this->cloneAndRegisterAllChildProcessors(src);
}
std::unique_ptr<GrFragmentProcessor> GrNestedCall::clone() const {
return std::make_unique<GrNestedCall>(*this);
}
#if GR_TEST_UTILS
SkString GrNestedCall::onDumpInfo() const {
return SkString();
}
#endif
Reference in New Issue Copy Permalink