SkSL status

[Peter Verswyvelen]

I have a couple of questions regarding the SkSL shading language.

It seems CanvasKit exposes it as a public APi?

Is SkSL part of the public C++ API too?

Can SkSL shaders run on the CPU too (e.g. server side headless systems)?

If the CPU is not supported, is it possible to compile SkSL to SPIRV and then pass it to this project?

https://software.intel.com/en-us/articles/spir-v-to-ispc-convert-gpu-compute-to-the-cpu

Thanks for the feedback

[Mike Reed]

It is public in both CanvasKit and C++.

It is also in its early stages, and is definitely under (very) active development, and so is likely to change (in modest ways) for a while still.

It has a CPU backend (interpreter and JIT) as well as GPU backends.

--
You received this message because you are subscribed to the Google Groups "skia-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/c0da2d99-291e-4d1e-a0f1-48ce941af4db%40googlegroups.com.

[Peter Verswyvelen]

That is amazing! 

I can't find a lot of documentation for this, especially the C++ API, do you have recommendations, examples?

Looking at the source code on cs.skia.org, I can't find any details on how the CPU interpreter and JIT work, I only see code to statically compile to C++ code, or GPU shader code.

Is it possible to just pass a SkSL code string to SkRuntimeEffect, and have this shader running using the CPU backend, at runtime, JIT compiled?

On Wednesday, April 8, 2020 at 2:06:57 AM UTC+2, Mike Reed wrote:

It is public in both CanvasKit and C++.

It is also in its early stages, and is definitely under (very) active development, and so is likely to change (in modest ways) for a while still.

It has a CPU backend (interpreter and JIT) as well as GPU backends.

On Tue, Apr 7, 2020 at 7:31 PM Peter Verswyvelen <bug...@gmail.com> wrote:

I have a couple of questions regarding the SkSL shading language.

It seems CanvasKit exposes it as a public APi?

Is SkSL part of the public C++ API too?

Can SkSL shaders run on the CPU too (e.g. server side headless systems)?

If the CPU is not supported, is it possible to compile SkSL to SPIRV and then pass it to this project?

https://software.intel.com/en-us/articles/spir-v-to-ispc-convert-gpu-compute-to-the-cpu

Thanks for the feedback

--
You received this message because you are subscribed to the Google Groups "skia-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to skia-d...@googlegroups.com.

[Mike Reed]

SkRuntimeEffect *is* the API -- you create an effect/program, and then with that you can 'snap-off' shaders or colorfilters (each instance with its own set of uniform data).

The language and compiler work is mostly done in src/sksl.

The (new) interpreter and JIT is done in skvm namespace.

To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/8555e9c1-3af6-488c-98b6-a6a477b2e3c1%40googlegroups.com.

[Peter Verswyvelen]

Thanks for the info.

Skimming over the SkRuntimeEffect class, I have some additional questions, I hope you don't mind.

I guess to pass the uniform input data, one passes an SkData object, with correct alignment for each uniform?

And to pass "texture samplers" (in traditional GPU parlance), you have to pass in SkShader objects? For example, calling makeShader on SkBitmap?

To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/8555e9c1-3af6-488c-98b6-a6a477b2e3c1%40googlegroups.com.

[Brian Osman]

For samplers - yes. They're abstracted to the level of Skia's SkShader objects. This means that you can sample from things like textures (via makeShader on SkImage or SkBitmap), but you can also sample things like gradients (SkGradientShader::MakeLinear, etc...). It's worth noting that in that case, the gradient *isn't* converted to a texture, it's analytically sampled just like Skia would do normally. And of course, you can combine multiple SkShader objects created from SkRuntimeEffects, as well. Again, this uses the same mechanism that Skia already uses to combine complex SkPaint pipelines, so all of the shaders are effectively stitched together, and run as a single unit, with no intermediate buffers.

For uniforms - yes, you pass an SkData with all of the data. You can query the effect to get the expected total size of that blob (inputSize()), as well as the offset of each uniform (or 'in') variable, by iterating over inputs(). For simple effects that just have uniforms, the packing rules are straightforward, but it's going to be a good habit to use the reflection API to at least validate your assumptions. We already reorder 'in' vs 'uniform', and future changes could cause additional unexpected changes from the naive layout.

To clarify a couple things that came up earlier - the CPU backend does have an interpreter and JIT in progress, but there are several functionality gaps. There are many things that only work on the GPU backend, and not with the interpreter (so they don't work on the CPU backend at all). This includes many intrinsic functions (today most GLSL intrinsics can be used in SkSL, but we're likely to restrict that list to a subset that we know we can support on all backends and GPU configs). In addition, sampling other effects only works on the GPU backend today. Past that, the connection from SkSL to the JIT is just beginning, so it only handles an even smaller subset of effects. Work is ongoing to close both gaps, though.

To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/0e8a6986-e549-46c4-b557-074e2af5785a%40googlegroups.com.

[Shawn Riordan]

Is SkSL just a fragment shader?

Or can it also handle a vertex shader?

To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/0e8a6986-e549-46c4-b557-074e2af5785a%40googlegroups.com.

[Mike Klein]

Today you can use SkRuntimeEffect to create SkShaders or SkColorFilters using the SkSL language.

To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/5db340ae-b4b2-4bc7-a089-cd51633fbd46%40googlegroups.com.

[Ethan Nicholas]

Internally we also use SkSL for other shader types, but currently Skia clients can only provide fragment shading code.

To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/5db340ae-b4b2-4bc7-a089-cd51633fbd46%40googlegroups.com.

[Brian Osman]

To expand on this a bit: It's important to remember that most Skia drawing operations don't have vertices  as a user-visible concept. The geometry is almost always higher-order primitives, so any vertices that are being emitted are dependent on which particular algorithm we've chosen, and there are typically very few, relative to the complexity of the primitive. The model (today) is that Skia still handles determining coverage at each pixel (through a combination of the geometry that's being drawn as well as the clipping), while the shader determines how to fill that geometry. This is restricting in the sense that you can't transform a path in the "vertex" shader (but most path rendering algorithms wouldn't accommodate that anyway), but it's also incredibly powerful: You can write an SkSL SkShader and use it to fill simple shapes, arbitrary clipped paths, text, etc., including analytic antialiasing.

To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/CAFqx8w%2BZduxDteu0k4QQDv3jaOPUB5RkWrP01Xr4kBLOV0n-pQ%40mail.gmail.com.