1. 07 Apr, 2017 4 commits
  2. 06 Apr, 2017 2 commits
  3. 05 Apr, 2017 2 commits
  4. 04 Apr, 2017 10 commits
  5. 03 Apr, 2017 6 commits
  6. 02 Apr, 2017 1 commit
    • Refactor TType::contains* methods (nonfunctional) · 27309f68
      steve-lunarg authored
      There were many (~8) different places in TType which all knew how to traverse
      the struct/type hierarchy.  There's a need to add another, but I didn't
      want to duplicate the traversal code again.  This is a small refactoring
      which passes a predicate to a single traverse-and-test method.  That also
      shortens all the containsSomething() methods from 9 lines of body to 1.
      
      There are no test differences: it's nonfunctional.
  7. 01 Apr, 2017 1 commit
  8. 31 Mar, 2017 9 commits
  9. 30 Mar, 2017 5 commits
    • HLSL: Add namespace grammar and some basic semantics. · 8f9fdc98
      John Kessenich authored
      Unknown how extensive the semantics need to be yet. Need real
      feedback from workloads. This is just done as part of unifying it
      with the class/struct namespaces and grammar productions.
    • HLSL: HS return is arrayed to match SPIR-V semantics · e752f463
      steve-lunarg authored
      HLSL HS outputs a per ctrl point value, and the DS reads an array
      of that type.  (It also has a per patch frequency).  The per-ctrl-pt
      frequency is arrayed on just one side, as opposed to SPIR-V which
      is arrayed on both.  To match semantics, the compiler creates an
      array behind the scenes and indexes it by invocation ID, assigning
      the HS return value to it.
    • HLSL: require tessellation factors to be fixed size arrays · 194f0f39
      steve-lunarg authored
      SPIR-V requires that tessellation factor arrays be size 4 (outer) or 2 (inner).
      HLSL allows other sizes such as 3, or even scalars.  This commit converts
      between them by forcing the IO types to be the SPIR-V size, and allowing
      copies between the internal and IO types to handle these cases.
    • HLSL: support per control point patch const fn invocation · 9cee73e0
      steve-lunarg authored
      This PR emulates per control point inputs to patch constant functions.
      Without either an extension to look across SIMD lanes or a dedicated
      stage, the emulation must use separate invocations of the wrapped
      entry point to obtain the per control point values.  This is provided
      since shaders are wanting this functionality now, but such an extension
      is not yet available.
      
      Entry point arguments qualified as an invocation ID are replaced by the
      current control point number when calling the wrapped entry point.  There
      is no particular optimization for the case of the entry point not having
      such an input but the PCF still accepting ctrl pt frequency data.  It'll
      work, but anyway makes no so much sense.
      
      The wrapped entry point must return the per control point data by value.
      At this time it is not supported as an output parameter.