diff options
| author | Tim Foley <tfoleyNV@users.noreply.github.com> | 2018-07-26 13:36:28 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2018-07-26 13:36:28 -0700 |
| commit | 66f5f18037602751ebce3c5e12d0466a9ee97462 (patch) | |
| tree | d8e72302af985801662d4d9e698cf63e5bd94151 /examples | |
| parent | dff216cc5ddb073e5bffdd4550eda208b7527676 (diff) | |
Fix implicit flat interpolation for GLSL output (#619)
There was some logic called `maybeEmitGLSLFlatModifier()` that was supposed to emit an implicit `flat` modifier for any varying shader parameter with an integer type that wasn't qualified as `nointerpolation` in the input HLSL/Slang (where `nointerpolation` is the equivalent of `flat`).
This wasn't being triggered because I apparently added code to only emit the implicit modifier if there was no explicit one, but then I had this code:
```c++
bool anyModifiers = false;
anyModifiers = true;
...
if(!anyModifiers && ...) { maybeEmitGLSLFlatModifier(); }
```
Unsurprisingly, the `anyModifiers = true` line meant that things never actually triggered. Once I fixed that issue the next problem that arose was that the `maybeEmitGLSLFlatModifier()` logic was being applied to *any* varying integer parameter, which includes fragment outputs, but GLSL forbids the `flat` modifier on fragment outputs and so gave an error on a shader that wrote to an integer target.
I fixed up the logic to take computed layout for a shader parameter into account, and only emit the `flat` modifier for fragment *inputs*. As the `TODO` commend at that location notes, there may be some arcane rules about how a vertex shader also needs to use `flat` when declaring the matching output, so we may need to make that test more careful down the road. For now the shader that originally surfaced this problem now works under Vulkan.
Diffstat (limited to 'examples')
0 files changed, 0 insertions, 0 deletions
