Revision 5298ccf7da486d0010c6157974d5dd9a5556f265 authored by Tim Foley on 05 April 2018, 23:15:45 UTC, committed by GitHub on 05 April 2018, 23:15:45 UTC
* Don't emit interpolation modifiers on GLSL fields The previous change that started passing through interpolation modifiers didn't account for the fact that the GLSL grammar doesn't allow interpolation modifiers on `struct` fields, so we shouldn't emit them in that case (and our legalization strategy for GLSL guarantees that varying input will never use a `struct` type anyway). * Try to handle SV_Position semantic on GS input HLSL allows `SV` semantics to be used for ordinary inter-stage dataflow in some cases (e.g., a VS can output `SV_Position` and it can then be read from a GS). GLSL allows similar things with `gl_Position`, but there are some wrinkles. One fix here is to correctly identify that `gl_FragCoord` should only be used as the translation of `SV_Position` for a fragment shader input (and not in the general case of *any* input). The other "fix" here is a kludge to handle the fact that the right translation for a GS input is not to an array called `gl_Position`, but to the syntax `gl_in[index].gl_Position` (array-of-structs style). I am doing this by attaching a custom decoration to the global variable we create for `gl_Position` and then intercepting it during code emit. I'm not proud of this, and would like to do something better given time. * Fix GLSL output for matrix-scalar multiplication The output logic was assuming that any use of `operator*` in the input code that yields a value of matrix type must be translated to a `matrixCompMult()` call in GLSL, but this should really only apply if both of the *operands* are matrices (not just based on the result type). As a result matrix-times-scalar operations were emitting a call to `matrixCompMult()` and GLSL was complaining because it won't implicitly promote scalars to matrices.
1 parent 071566c
.travis.yml
# .travis.yml
#
# This is the configuration file to drive Travis CI for Slang.
language: cpp
env:
- SLANG_TEST_FLAGS=-travis
# Build and test (clang, gcc) x (debug, release)
#
# We customize the set of tests run per-target to
# avoid having the build take too long.
matrix:
include:
- os: linux
compiler: gcc
env:
- CONFIGURATION=debug
- SLANG_TEST_CATEGORY=smoke
- os: linux
compiler: clang
env:
- CONFIGURATION=debug
- SLANG_TEST_CATEGORY=smoke
- os: linux
compiler: clang
env:
- CONFIGURATION=release
- SLANG_TEST_CATEGORY=smoke
- os: linux
compiler: gcc
env:
- CONFIGURATION=release
- SLANG_TEST_CATEGORY=full
- SLANG_DEPLOY=true
# Travis wants to default to a build script that invokes
# `./configure && make && make test` which is appropriate
# for autoconf, but I don't want to get into that mess..
#
script: make && make test
before_deploy: |
export SLANG_OS_NAME=${TRAVIS_OS_NAME}
export SLANG_ARCH_NAME=`uname -p`
export SLANG_TAG=${TRAVIS_TAG#v}
export SLANG_BINARY_ARCHIVE=slang-${SLANG_TAG}-${SLANG_OS_NAME}-${SLANG_ARCH_NAME}.zip
zip -r ${SLANG_BINARY_ARCHIVE} bin/*/*/slangc bin/*/*/libslang.so bin/*/*/libslang-glslang.so docs/*.md README.md LICENSE slang.h
# We are going to deploy to GitHub Releases
# on a successful build from a tag, but only
# on the one target in the build matrix that set
# `SLANG_DEPLOY`
deploy:
provider: releases
api_key: "$GITHUB_RELEASE_TOKEN"
file: "$SLANG_BINARY_ARCHIVE"
skip_cleanup: true
on:
condition: "$SLANG_DEPLOY = true"
tags: true
![swh spinner](/static/img/swh-spinner.gif)
Computing file changes ...