Frontend shader cache?

[Chris Dalton]

Hello again, I'm hoping to add support for EXT_shader_pixel_local_storage to ANGLE's PLS extension, but this will require some behind-the-scenes shaders for loading and clearing.

Does ANGLE have a frontend shader cache I can use to store these shaders? How to other behind-the-scenes shaders work?

Thanks again for your help!

-Chris

[Shahbaz Youssefi]

Hi!

There are various "built-in" shaders in ANGLE, with different degrees of efficiency / simplicity.

- For GLES1 emulation, the front-end builds the shader as GLSL source code, and goes through compiling it and using it through the front-end itself, i.e. as if all that was done by the application (minus GL validation)

- The Vulkan, metal and d3d backends have pre-compiled shaders (for Vulkan for example, that's under src/libANGLE/renderer/vulkan/shaders/src)

  * The GL backend doesn't have this option, so it also creates GLSL source code on the fly as necessary

The first method is the easiest for PLS, as it's also implemented entirely in the front-end. Take a look at GLES1Renderer.cpp (and associated files) to get an idea of how it's done (but it's not hard to imagine either). The second is more complex as support for each backend would have to be hooked in separately (and support in the GL backend is essentially as much work as doing it entirely in the frontend), but comes with the benefit of not needing a compilation. I don't imagine PLS needs that many shaders, so this benefit is probably negligible.

My suggestion would be to start with front-end shader generation (and caching the resulting programs), and if ever necessary, specialize with select backend implementations.

And to answer this question that I left out:

> Does ANGLE have a frontend shader cache I can use to store these shaders?

No, the emulation that lives in the front-end (i.e. GLES1) owns its own shaders and programs, and PLS could easily do the same.

---

For completeness:

- GLES1: Shaders generated by front-end

- Overlay: Managed by the front-end, but calls into backend to use prebuilt shaders (currently only Vulkan, I should one day move it all to front-end though)

- Blit implementations, vertex attribute emulation, etc: Entirely done in the backend using prebuilt shaders

[Chris Dalton]

Thanks for the detailed explanation Shabi!

>> The first method is the easiest for PLS, as it's also implemented entirely in the front-end.

I hope this is all we need, but there's one gotcha: In order to implement the spec as currently written, we will need "#version 310 es" shaders**, but since PLS is supported on a 3.0 context, that isn't always supported in the frontend. Looking at Compiler::Compiler, it looks like it selects the shader spec based on the State's version? Would it be hard to compile a 310 shader from a frontend 3.0 context?

>> Blit implementations, vertex attribute emulation, etc: Entirely done in the backend using prebuilt shaders

The PLS support shaders are effectively blits themselves, and only a feature in GLES. This probably wouldn't be so bad if we can't do #1.

** We need 310 shaders because EXT_shader_pixel_local_storage only allows writing out to one color attachment, but ANGLE_shader_pixel_local_storage allows writing out to multiple PLS planes. So if we want to support multiple, we need an internal shader at the end that imageStores PLS into images.

--
You received this message because you are subscribed to the Google Groups "angleproject" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angleproject...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/angleproject/3325e796-b891-4206-bc21-147afb9975d1n%40googlegroups.com.

[Shahbaz Youssefi]

That _does_ complicate things a bit, I thought you said the implementation on top of EXT_pls would set the limit such that ANGLE_pls would also support one output?

There are a number of options on how we could approach ES3.1 shaders on ES3.0 context. But first, in case you are not aware, the driver is allowed to return a later version even if an earlier version is requested by the app. So presumably if you are generating ES3.1 shaders, it's because the backend supports ES3.1 already. Also, you should know that ANGLE has an extension that overrides what I just said, which we use for our test suites; so if a test creates an ES2 context and tests that cubemaps are seamful, we don't return an ES3 context where cubemaps are seamless. So TBH, this situation is only really troublesome for tests because the backend supports ES3.1 but we give back an ES3.0 context based on the tests' request.

So the possibilities are, again _knowing_ that the backend really supports ES3.1 (inferred from the choice of PLS implementation e.g.) are:

1. Make the compiler believe ES3.1 is the real context version. That should get the shaders to compile, and most likely the backend just works

2. Make an ANGLE extension that provides whatever ES3.1 functionality you need on ES3.0, then write the shaders in ES3.0. This is the least hacky, but a lot of headache

3. Implement the functionality in the GL backend (as it's only needed for EXT_pls), and have the other backends no-op it. So you'd call something like backend->someMagic() and it would add the draw call.

I'd probably go with 3.

[Chris Dalton]

> That _does_ complicate things a bit, I thought you said the implementation on top of EXT_pls would set the limit such that ANGLE_pls would also support one output?

Ah, the implementation on top of EXT_pls sets the _application's_ color attachment limit to zero (meaning the app can only render to PLS).

The issue here though is that we need a way to dump all PLS planes to memory, which can only be done with shader images.

If we only need to preserve one PLS plane, we can dump it via a single, internal color attachment. (EXT_pls only allows one.) But with virtual context switching in Chrome, I think we will just have to support preserving all of them.

> I'd probably go with 3.

Glad we agree. I have something working now that passes all the tests (woohoo!). I'll try and clean it up and put it up for review. This will probably be easier to talk about once there's some code to look at!

To view this discussion on the web visit https://groups.google.com/d/msgid/angleproject/771f0bd3-c388-43ab-abc1-f7f99294f3fan%40googlegroups.com.