Gpuweb: Asynchronous shader reflection information

Created on 18 Mar 2020  路  6Comments  路  Source: gpuweb/gpuweb

During the last F2F, the idea of exposing reflection information came up. There are a few different use cases:

  1. Something like Shadertoy, where the JS might not know the content of the shaders it's ingesting. (Shadertoy specifically solves this by requiring a particular interface to every shader, but it's not unrealistic to imagine there are places which wouldn't have this requirement.)
  2. During the last F2F, the D3D team indicates that many AAA games create giant shaders with tons of unused inputs/outputs, and then ask the shader compiler which inputs/outputs are actually used, so they can hook up only those resources.
  3. Could be used to solve the concerns in https://github.com/gpuweb/gpuweb/issues/561

As far as I know, all the native APIs provide some sort of shader reflection information.

(There's no "API" GitHub tag, so I don't know how to tag this issue as both "relevant to WGSL" but also "relevant to the API")

feature request

All 6 comments

Thank you for filing this!

It's not in the spirit of low-level APIs to expose any information that the user is already supposed to know. However, it is established in the graphics community that there are applications that work best with this approach. This includes AAA games with large variety of shaders, as well as things like Granite. So I think it's important for us to allow these use cases to exist.

As far as I know, all the native APIs provide some sort of shader reflection information.

It's not clear to me if this matters. We could extract all the relevant info from the WGSL module ourselves.

Observation: Any engine that is generating WGSL should already have enough reflection data in userspace. So adding this would only help engines which are WGSL-first.

(Notably, I think this makes it reasonable to mark post-MVP.)

As far as I know, all the native APIs provide some sort of shader reflection information.

It's not clear to me if this matters. We could extract all the relevant info from the WGSL module ourselves.

I included this not as an an implementation concern, but instead as more of a motivation for the issue. The fact that all the native APIs include this functionality is an indication that authors want it.

As far as I know, all the native APIs provide some sort of shader reflection information.

DX12 and Vulkan provide no reflection information, as far as I know. DirectXShaderCompiler provides some, but that's offline. In Vulkan, community tooling like SPIRV-Reflect is often used.

Perhaps this reflection information could be integrated with https://github.com/gpuweb/gpuweb/pull/646

Was this page helpful?
0 / 5 - 0 ratings

Related issues

yukunxie picture yukunxie  路  6Comments

enkicoma picture enkicoma  路  6Comments

kvark picture kvark  路  5Comments

kainino0x picture kainino0x  路  6Comments

kainino0x picture kainino0x  路  3Comments