https://github.com/shader-slang/slang
Revision b487516880f56fd69ff76bf7cb3f0f1711bc356d authored by Tim Foley on 29 November 2017, 19:45:15 UTC, committed by GitHub on 29 November 2017, 19:45:15 UTC
Fixes #301 The problem here is that if you have input GLSL code like: ```glsl // example.vs in vec3 pos; ``` and: ```glsl // example.fs in vec3 worldPos; ``` Then both `pos` and `worldPos` are reflected as global variables (parameters of the *program*), which both get bound to "varying input" resources, but there is no way to tell through the API that `pos` is a vertex parameter while `worldPos` is a fragment one. The original request in issue #301 was to expose parameters like this not as a global variables, but rather as parameters of the entry point in their specific file. That is, treat it as if the user had written, e.g.: ```glsl // example.vs void vsMain(in vec3 pos) { ... } ``` Doing that would unify the GLSL and HLSL/Slang cases a bit, but would require the Slang reflection API to lie about the structure of code the user wrote. At a more basic level, that would have been hard to implement because the current reflection API just exposes the underlying AST, and the AST *needs* to leave `pos` at the global scope so that when we go and spit GLSL back out we retain the original structure. This PR implements a more simplistic solution, where the user is allowed to query the stage that a varying parameter "belongs" to. For right now I'm only enabling this to work for varying parameters (but it doesn't care if they are entry-point or global-scope varyings). Despite what I said on #301, this should work for both the top-level parameter's variable layout, *and* any variable layouts for fields within its type reflection. In terms of implementation, I took the simple but wasteful route: every `VarLayout` now has a `stage` field that is by default initialized to `SLANG_STAGE_NONE`. When collecting varying parameters, I take advantage of the fact that everything bottlenecks through `processEntryPointParameter()` which takes an `EntryPointParameterState` so that I can set the `VarLayout::stage` field for any varying parameter in one place. While I was making this change, I also did a bit of cleanup so that the "official" names for the varying parameter categories are `VARYING_INPUT` and `VARYING_OUTPUT`, with `VERTEX_INPUT` and `FRAGMENT_OUTPUT` being "deprecated" in principle. I didn't do the bulk rename inside the codebase yet.
1 parent 7139380
Tip revision: b487516880f56fd69ff76bf7cb3f0f1711bc356d authored by Tim Foley on 29 November 2017, 19:45:15 UTC
Add API to query stage of varying parameter (#302)
Add API to query stage of varying parameter (#302)
Tip revision: b487516
File | Mode | Size |
---|---|---|
build | ||
docs | ||
examples | ||
external | ||
source | ||
tests | ||
tools | ||
.gitattributes | -rw-r--r-- | 95 bytes |
.gitignore | -rw-r--r-- | 398 bytes |
.gitmodules | -rw-r--r-- | 107 bytes |
.travis.yml | -rw-r--r-- | 1.6 KB |
CODE_OF_CONDUCT.md | -rw-r--r-- | 3.1 KB |
LICENSE | -rw-r--r-- | 1.1 KB |
Makefile | -rw-r--r-- | 6.3 KB |
README.md | -rw-r--r-- | 6.2 KB |
appveyor.yml | -rw-r--r-- | 3.5 KB |
slang.h | -rw-r--r-- | 38.6 KB |
slang.sln | -rw-r--r-- | 9.1 KB |
test.bat | -rw-r--r-- | 1.4 KB |
Computing file changes ...