1. 26 Oct, 2020 1 commit
  2. 24 Oct, 2020 1 commit
    • HLSL: Add support for printf(). · f6e0fe86
      Rex Xu authored
      Translate printf() to what GL_EXT_debug_printf has done. HLSL could
      define non-constant string variable and we don't have such features
      in SPIR-V, so just support constant string variable.
  3. 22 Oct, 2020 1 commit
  4. 21 Oct, 2020 1 commit
    • Fix GN build and presubmits · 0f52e7ef
      Ben Clayton authored
      Add missing `.cfg` files for GN presubmit.
      Add missing `recursedeps` in the `DEPS` file.
      Call `./update_glslang_sources.py` before attempting to build.
      Add more GN spew to the `.gitignore` file.
  5. 20 Oct, 2020 5 commits
  6. 19 Oct, 2020 2 commits
    • Merge pull request #2422 from ben-clayton/gn · 3ead0119
      John Kessenich authored
      Add basic GN configurations
    • Fix uninitialized use of TIntermediate::resource (#2424) · 5b99b448
      Ben Clayton authored
      TIntermediate was constructed without initializing any of the `resources` fields,
      and `TProgram::linkStage()` was not calling `TIntermediate::setLimits()`
      after constructing new `TIntermediate`s for non-first stages.
      
      Fields of `resources` were then read in `TIntermediate::finalCheck()`
      triggering undefined behavior.
      
      This CL makes three changes:
      (1) `TIntermediate::setLimits()` is now called for non-first stages by
          copying the `firstIntermediate`'s limits. This ensures that the
          `resources` fields is initialized, fixing the bug.
      (2) `TIntermediate::resources` is now wrapped in a `MustBeAssigned<>`
          helper struct, asserting in non-release builds that this field is
          always initialized before reading.
      (3) `TIntermediate::resources` is now zero-initialized, so that if
          the `TIntermediate::resources` field is not set in a release build
          (and so the `assert()` will be disabled) behavior is still
          deterministic.
      
      Fixes #2423
  7. 16 Oct, 2020 2 commits
  8. 12 Oct, 2020 2 commits
  9. 07 Oct, 2020 2 commits
  10. 05 Oct, 2020 2 commits
  11. 28 Sep, 2020 1 commit
  12. 27 Sep, 2020 2 commits
  13. 26 Sep, 2020 1 commit
  14. 25 Sep, 2020 1 commit
  15. 18 Sep, 2020 1 commit
    • SPIRV: Add more utility functions to build some opcodes (#2398) · 4dcc12d1
      Rex Xu authored
      Add more builder functions to OpExecutionMode, OpExecutionModeId,
      OpDecorateString, OpMemberDecorateString.
      
      According to SPIR-V, OpExecutionMode and OpExecutionModeId could
      take variable extra operands. Current implementation doesn't support
      this and assumes at most 3 operands are extra operands. It is not
      true. Similarly, OpDecorateString and OpMemberDecorateString could
      support multiple strings either as literal strings or as string
      operands. Further, OpDecorate and OpDecorateId have the same problem,
      taking variable extra operands.
  16. 15 Sep, 2020 1 commit
    • Preprocessor related issue fix (#2378) · 9eaa69c2
      Chow authored
      * Preprocessor related fix
      
      1). Accoding to ESSL spec : All macro names containing two consecutive underscores ( __ ) are reserved for future use as predefined macro names, so just report a warning instead of error when the shader defines the macro names begining with  '__';
      
      2. According to spec:  If an implementation does not recognize the tokens following #pragma, then it will ignore that pragma, so report a compile-time warning intead of error for the following statement:
      #pragma debug(1.23)
      
      3. The 'defined' macro should be allowed to expand and '__LINE__' should be allowed to be replaced with its original line number (otherwise, other expanding macros may change this value).
      
      4. Add a flag 'indentifierSeen' in PPContext to indicate whether the any non-preprocessor tokens is existed before the extension directives, because the built-in symbols and functions are parsed before paring the user shader, so add a 'shaderSource' flag to check this error only for the user shader source;
      
      5. Add missing type int16 and uint16.
      
      * Add test results, remove restriction of #extension.
      
      1. Remove extension restriction in first line , as this is contraversy now.
      
      2. The following shader is compiled failed as glslang consider the keyword 'defined' can not be undefined(in the 9th line: "#define defined BBB")
      The shader is as following:
      According to ES3.0 spec: It is an error to undefine or to redefine a built-in (pre-defined) macro name.
      This rule is aimed to the  __LINE__,  __FILE__, __VERSION__ and  GL_ES,
      the keyword "defined" should not be restricted by this rule,
      so change the compile error to warning and make the following shader compile successfully.
      
      * 1. Using relaxedError to control error/warning report level. 2. remove #extension restriction. 3. Fix version related issue.
      
      1. Using relaxedError to control error/warning report level. 2. remove #extension restriction. 3. Fix version related issue.
      
      * Add test results
      
      * Turn conditional warnings about pragma to unconditional ones.
  17. 14 Sep, 2020 3 commits
  18. 13 Sep, 2020 2 commits
  19. 12 Sep, 2020 2 commits
  20. 08 Sep, 2020 2 commits
  21. 07 Sep, 2020 3 commits
  22. 03 Sep, 2020 1 commit
  23. 02 Sep, 2020 1 commit