Status: New
Owner: ----
CC:
michae...@google.com,
johns...@google.com,
ethann...@google.com Area: SkSL
Priority: Medium
Type: Defect
New issue 10680 by
brian...@google.com: Runtime effects: Limit functionality for CPU and low-end GPU
https://bugs.chromium.org/p/skia/issues/detail?id=10680There are two big categories of functionality that can be used, but should be guarded (or only enabled by opting in, perhaps).
First is types: We'd like to prevent users from using any 'int' variables, to ensure that things work on low end GPUs without integer support. Nothing prevents users from using int today, and if you happen to be on a device that doesn't support them, the shader just won't compile (but will fail far too late).
Second, intrinsics: Pipeline stage compiles use the sksl_gpu.sksl pre-include, so nearly all GLSL builtin functions are declared. If you target the GPU backend, most of them will work, too. (eg Flutter recently posted a demo where they're using dFdx/dFdy). You could end up on a device that doesn't have one, though. These end up passed through by GrSkSLFP, and inserted into the combined-FP program, where they're handled by the backend generator.
In addition, many of these won't work on the CPU backend. We've implemented the most common intrinsics in the byte code generator + skvm, but there are a huge number of things here that just don't exist. Many of the missing bits are also functions related to integers, or to other types that should be disallowed (sampler, image, etc...)
Strategies:
* We could use the CPU backend as the arbiter of what's allowed, by compiling all the way to ByteCode in the SkRuntimeEffect factory. This easily handles the case of missing intrinsics (those are reported as an error by the byte code generator). It doesn't address types like 'int' - those are supported by the ByteCode (though not yet by SkVM). This is also extra work if we're not planning to use the CPU backend. Still - it might be a good way to guard unsupported intrinsics.
* For types, I think we're going to need something in the IR generator. Adding lots of checks against specific types feels really cumbersome, but we may be able to add a flag to the Type itself, indicating if it's allowed in runtime effects. That would make any specific checks much simpler against the type object itself. We'd still need to validate the types of variables, expressions, parameters, return types from functions, etc... But having the bit on the type will hopefully make it easier to read (and to expand support over time)?
--
You received this message because:
1. The project was configured to send all issue notifications to this address
You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings