| Age | Commit message (Collapse) | Author |
|---|
|
- This fixes the render tests, which aren't tested by the continuous integration setup
- This was broken in the commit that decided to use C-style directives all the time.
- This works for stuff that eventually passes through glslang (or at least our build of it)
- It *doensn't* work if we take the GLSL and pass it off to an OpenGL driver (which is what I do for testing)
- A longer-term fix is still required to deal with line directives properly
|
|
|
|
Fixes for shader cross-compilation
|
|
When cross-compiling, we need to detect when an intrinsic is used that required non-default GLSL capabilities and emit an appropriate `#extension ... : require` line.
I'm handling this by attaching a custom modifier to declarations that require an extension in order to be callable.
|
|
An expression with error type may still fail the l-value check, but we don't want to emit an error in that case.
|
|
HLSL (and thus Slang) commonly puts interpolation modifiers like `sample` on the fields of `struct` types used as stage input/output, while GLSL only allows them on global-scope `in` and `out` variables (or ones in blocks).
This change emits a really hacky filtering step to skip over certain modifiers when emitting a declaration. This lets us skip interpolation-mode modifiers when outputting a struct field to GLSL.
Note: this probably gets the `in` or `out` block case wrong...
|
|
- As long as we are always going to pass GLSL through glslang, there should be no harm in this
- Eventually we may need to re-enable the old style
|
|
- The old code was just doing `exit(1)` if glslang or `D3DCompile` failed, which is obviously unacceptable
- The new approach adds the output to the diagnostic buffer (or invokes the callback), and tracks the error count just like any other errors
|
|
- When assigning tuples `(a0, ...) = (b0, ...)` generate a tuple of assignments `(a0 = b0, ...)`
- Given an expression statement on a tuple `(a0, ...);` generate a sequence of statements `a0; ...`
|
|
Sample rate reflection
|
|
- This really just checks two basic things:
1. Was there any global variable declared with `in` and `sample`?
2. Did any code encountered during lowering referenece `gl_SampleIndex`?
- This doesn't cover what HLSL could need, nor what we would need for cross-compilation. Consider it GLSL-specific for now.
- In order to generate the information with even a reasonable chance of being accurate (not giving a ton of false positives) I tried to integrate the checks into the lowering process (so they only see code that is referenced, one hopes).
- For this to work with my testing setup, I needed to make sure that lowering is always performed, prior to emitting reflection info
- This change broke several reflection tests, because they had been using code that wouldn't actually pass the downstream compiler. I checked in fixes for those.
|
|
- This also adds reflection API for querying:
- Entry point name
- Entry point parameter list
|
|
Make parser recovering more robust to avoid infinite loops
|
|
Fixes #75
In order to avoid cascaded errors, I went ahead and made the parser refuse to skip past a `}` in recovery mode. The problem with this is that we fail to make forward progress if we are stuck on a `}` (this happens if you have an extra `}` at the global scope.
|
|
Resources in structs
|
|
|
|
|
|
- Don't try to extract the body layout for a field without a layout
|
|
Improve reporting of GLSL `image*` types
|
|
Resources in structs
|
|
- Update stdlib so taht `image*` types have read-write access encoded in their type
- TODO: this isn't 100% right, since there are GLSL qualifiers that might override this
- Add a test case to verify that the reflection API reports `image*` parameters
|
|
- The basic idea is that during the "lowering" pass, some types (notably: aggregate types that contain resource variables) will get turned into "tuple" types, which are pseduo-types that aren't meant to survive lowering.
- An attempt to declare a variable with a tuple type expands into a tuple of declarations
- An attempt to reference such a tuple-ified variable leads to a tuple of expressions
- An attempt to extract a member from such a tuple expression will pick the appropriate sub-element
- Dereference a tuple by dereferencing the primary expression
- Expand a tuple in the argument list to a call into N arguments (by recursively flattening the tuple)
- Don't create tuple types when not generating GLSL
- Make sure to preserve the specialized type of a call expression through lowering, since emission of unchecked calls relies on that info.
- TODO: maybe the infix/prefix/postifx/select information should come in as a side-band? Should we have modifiers on expressions?
- Make sure to offset the layout for a nested field based on teh base offset of its parent variable, when generating declarations for nested fields
|
|
Actually output SPIR-V/DXBC assembly as text, instead of binary.
This fixes a bunch of tests that were passing on accident, because nothing was producing output.
|
|
Support more sv semantics
|
|
I haven't tried to be 100% exhaustie, but this should cover the main cases we are likely to encounter in library code.
|
|
This helps avoid the problem where we emit a function that does a `discard` and thus get a GLSL compilation failure in a vertex shader (that doesn't even call the function).
|
|
The rule of thumb so far is that expected output for `.slang` files should be checked in, but not for `.hlsl` or `.glsl`. The render test breaks that rule, because we never want to check in the expected output.
|
|
SPIR-V Support
|
|
EntryPointResult/TranslationUnitResult, added helper functionality; Ensure null termination when printing raw data
|
|
|
|
|
|
|
|
Handle function name properly for unchecked call
|
|
The emit logic was checking for a missing decl, and then asking that same (missing) declaration for its name.
|
|
Fix emission of `static` for HLSL
|
|
I forgot to include a trailing space.
|
|
Falcor work
|
|
This was mostly just a missing `typedef` in the Slang standard library code.
This should also cover `textureBuffer` and `samplerBuffer`.
|
|
- Try to handle `ErrorType` gracefully when computing type layouts
- When outputting a `TypeExp`, if the type part is errorneous (or missing), try to use the expression part
- Make sure to lower the expressions side of a `TypeExp` during lowering
|
|
Falcor work
|
|
I hadn't been lowering `SV_Position` outputs to `gl_Position`, and had somehow been relying on hidden driver behavior that I guess made things Just Work.
This change adds some infrastructure to handle `SV_` semantics during lowering of an entry point (currently only covering `SV_Position` and `SV_Target`, FWIW).
As a byproduct, this also means that a `VarLayout` stores semantic info, which could conceivably be exposed through reflection data now.
|
|
- Allow a code-generation target of `NONE` in order to suppress ordinary output in test cases where we don't care about the actual output (just pass/fail result)
- Add explicit `location` layout qualifiers to intermediate vertex-to-fragment variables in GLSL test cases for rendering, to work around apparent Intel driver bugs.
|
|
- Add GLSL mappings for more `Texture*` methods
- The annoying one here is `Texture*.Load()` because it doesn't take a sampler, but the GLSL equivalent needs one (while the SPIR-V does *not*). I've hacked this pretty seriously for now.
- Try to ensure that we add `uniform` to global declarations that need it in GLSL
- When outputting an `in` or `out` variable that might have been created from an `inout` shader parameter, filter the layout qualifiers that we output to only cover the appropriate resource kind.
|
|
If the user had a shader entry point with an `inout` parameter, we would end up lowering it to two GLSL global variables with the same name.
This change adds a `SLANG_in_` or `SLANG_out_` prefix to the two declarations.
Note: I haven't dealt with the issue that we end up printing two different `layout` qualifiers on such a variable...
|
|
The earier changes to add sequence statements and change how the `isBuildingStmt` logic in lowering works doesn't work for this logic, which assumes it can just set `isBuildingStmt` and be sure that decls will go into the right place.
|
|
The tricky bit here was that the `reflection-json` output format isn't really a code generation target like the others, and we need to be able to have multiple "targets" active to make sense of it. This needs cleaning-up.
|
|
- Expand most queries that handle `TextureType` to handle `TextureTypeBase`, in hopes that this covers most uses of `image*` types in Vulkan GLSL
- Adopt the quick fix from Falcor to return read-write access for shader-storage-block types. Something more comprehensive is probably needed if people want to do queries on these, since constant buffers should really be included, then.
|
|
Revise rewriter
|
|
Adding an explicit AST node for `(expr)` was a good change, but it broke constant folding because I forgot to handle it.
|
|
Code in Slang that is cross-compiled *might* introduce declarations that collide with language keywords that are reserved in the target.
This was previously being dealth with during final code emission, but the challenge there is that we want to allow user code that is being "rewritten" to use whatever identifiers it wants (they know better than us what is an error), and only apply renaming to our own code.
The approach here is to apply renaming during lowering - we validate each declaration to make sure its name is valid. Any expressions/types that refer to those declarations will automatically get emitted with the new name (while unchecked expressions will continue to be emitted with their existing name).
This isn't quite perfect, since we could in theory still rename a declaration in user code.
A more robust version down the line would try to determine if a declaration was nested inside code for the "rewriter."
Also note that this does *not* deal with any issues of name conflicts that might arise between modules. That would require a more complete and robust renaming pass, which seems tricky for me to pull off.
|
