For now, just bolt this onto the existing runtime effects. The next step
is to add dedicated modes to the compiler for shader vs. color filter.
Once we get there, we will be much more strict about main signature in
each mode (and start adding other per-mode error checking).
Bug: skia:11813
Change-Id: I27e27600209e9844ae107364baea2fb949b47c3f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/395838
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
We are up to having seven distinct types of codegen, and will soon have
an 8th (DSL C++).
Change-Id: I6758328390c234ba1d5c30c118199dbc820af52a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/395817
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Bug: skia:11295
Change-Id: Iec11f3f4d26eb5b1c07707b3cedd09096bad80d0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/371478
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This change will allow these types to be forward-declared; C++ doesn't
allow forward declaration of types declared inside a struct. Moving
these types out of Programs resulted in a large diff.
The Settings::Value helper class has been moved inside of the
IRGenerator. In practice, it was actually just an implementation detail
of how IRGenerator looks up caps-values by name. It seems very unlikely
that this will be necessary elsewhere going forward.
Change-Id: I6119417fae608f1c492a27de746d2b550ef8ca20
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/370836
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Uses the pipeline-stage callback mechanism. It mangles the type name
(with a test to verify that this works), and then calls defineStruct
with the entire SkSL struct definition string.
Bug: skia:10939
Change-Id: If14cf1b11faaa80ad8d4086cdacf68532bac43fc
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/368809
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Structs, enums, and global variables are all going to require name
mangling. Move that to a separate virtual on the callback. More
importantly, the generator is going to need to do type-name substitution
inside the function declaration string, so the contract has shifted:
The generator constructs the entire function declaration line (using the
mangled name it gets from the new callback), then it calls
defineFunction with two strings, and a flag indicating if this is main
or not.
Bug: skia:10939, skia:11295, skia:11296
Change-Id: I535eee9bfbb2337013b539908fe3d658ec3b2dbd
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/368397
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
There is now PipelineStage::ConvertProgram, which takes a collection of
callbacks, and processes an entire program. For program objects that may
need name mangling, the callbacks return the new name, which is recorded
and used for future references to that object (eg uniforms & functions).
The callbacks let the FP inject new elements programmatically:
- Declare uniforms and get handles
- Emit child functions
- Invoke child processors for calls to sample()
In a follow-up CL, we can add an skslc `.rte -> .sksl` mode, where the
callbacks just emit the description() of the relevant element. We can
also follow the same pattern to emit declarations of types (structs,
enums), and global variables.
Change-Id: I81df68a2f41bcb48f866d37af3b77ad43e880236
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/367058
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
This is now structured like the VM generator: Just a function that does
the conversion. Moved all relevant types and constants out of the
compiler, too. The key thing is that we don't need/want an error
handler, because it's too late to fail. We *must* catch all errors
during IR generation.
This is also another step along the path of directly emitting to the
fragment shader builder, rather than generating strings with
placeholders.
Bug: skia:11127
Change-Id: I18591270aa6e56dae1f040275a4b7d4a245007db
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/366956
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
This maps to usage better, and makes some code simpler to understand.
Note that there is still a PipelineStage *back-end*, which is specific
to the runtime-effect FP. A kRuntimeEffect_Kind program can be used to
generate a PipelineStage (for the GPU backend), or an skvm program (for
the CPU backend).
Change-Id: Id3f535db93a239726c595225aafe9467f0d19817
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/344969
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This ties the caps to the compiler instance, paving the way for
pre-optimizing the shared code. Most of the time, the compiler is
created and owned the GPU instance, so this is fine. For runtime
effects, we now use the shared (device-agnostic) compiler instance
for the first compile, even on GPU. It's configured with caps that
apply no workarounds. We pass the user's SkSL to the backend as
cleanly as possible, and then apply any workarounds once it's part
of the full program.
Bug: skia:10905
Bug: skia:10868
Change-Id: Ifcf8d7ebda5d43ad8e180f06700a261811da83de
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/331493
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
We had several defines around the code base that were not
very descriptive. Additionally, we had a patch of extra
runtime restrictions living in oss-fuzz that were applied
when fuzzing over there for some fuzzers.
This has all be consolidated and controlled via the defines
documented in site/dev/testing/fuzz.md
As such, we can remove one of the patches that is in oss-fuzz,
taking us closer to being able to fuzz in the CI/CQ.
PS 1 renames existing fuzz defines to the new schema.
PS 2-3 backports skia.diff from oss-fuzz and changes those
definitions to have the _GREATLY modifier.
PS 5+ further condenses the defines so that there is one
define for gating the runtime checks.
Change-Id: Ia4ad96f30c1e9620a2123b510e97c6f501a2e257
Docs-Preview: https://skia.org/?cl=316443
Bug: skia:10713
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/316443
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Bundling the pipeline stage arguments also simplifies the code in
several spots.
Change-Id: I85e81b436a39378f753cc9404b6eeb27fe055525
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261778
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Bug: skia:
Change-Id: I1483cdf7229b7234be41d21407e2b4abf99fff76
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/239925
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Current strategy: everything from the top
Things to look at first are the manual changes:
- added tools/rewrite_includes.py
- removed -Idirectives from BUILD.gn
- various compile.sh simplifications
- tweak tools/embed_resources.py
- update gn/find_headers.py to write paths from the top
- update gn/gn_to_bp.py SkUserConfig.h layout
so that #include "include/config/SkUserConfig.h" always
gets the header we want.
No-Presubmit: true
Change-Id: I73a4b181654e0e38d229bc456c0d0854bae3363e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/209706
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Hal Canary <halcanary@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>