All fragment processors now use explicit returns; sk_OutColor no longer
exists at all.
Change-Id: Ic5cf566a916c1d616edcc56ba84b6780776f8515
Bug: skia:10549
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/344300
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
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>
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>
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>
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>
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>
`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>
