Khronos-reference front end for GLSL/ESSL, partial front end for HLSL, and a SPIR-V generator.

Related tags

Miscellaneous compiler validator glsl shader spir-v hlsl glslang glslangvalidator essl
Overview

News

  1. Visual Studio 2013 is no longer supported

    As scheduled, Microsoft Visual Studio 2013 is no longer officially supported.
    Please upgrade to at least Visual Studio 2015.

  2. The versioning scheme is being improved, and you might notice some differences. This is currently WIP, but will be coming soon. See, for example, PR #2277.

  3. If you get a new compilation error due to a missing header, it might be caused by this planned removal:

SPIRV Folder, 1-May, 2020. Glslang, when installed through CMake, will install a SPIRV folder into ${CMAKE_INSTALL_INCLUDEDIR}. This SPIRV folder is being moved to glslang/SPIRV. During the transition the SPIRV folder will be installed into both locations. The old install of SPIRV/ will be removed as a CMake install target no sooner than May 1, 2020. See issue #1964.

If people are only using this location to get spirv.hpp, I recommend they get that from SPIRV-Headers instead.

appveyor status Continuous Deployment

Glslang Components and Status

There are several components:

Reference Validator and GLSL/ESSL -> AST Front End

An OpenGL GLSL and OpenGL|ES GLSL (ESSL) front-end for reference validation and translation of GLSL/ESSL into an internal abstract syntax tree (AST).

Status: Virtually complete, with results carrying similar weight as the specifications.

HLSL -> AST Front End

An HLSL front-end for translation of an approximation of HLSL to glslang's AST form.

Status: Partially complete. Semantics are not reference quality and input is not validated. This is in contrast to the DXC project, which receives a much larger investment and attempts to have definitive/reference-level semantics.

See issue 362 and issue 701 for current status.

AST -> SPIR-V Back End

Translates glslang's AST to the Khronos-specified SPIR-V intermediate language.

Status: Virtually complete.

Reflector

An API for getting reflection information from the AST, reflection types/variables/etc. from the HLL source (not the SPIR-V).

Status: There is a large amount of functionality present, but no specification/goal to measure completeness against. It is accurate for the input HLL and AST, but only approximate for what would later be emitted for SPIR-V.

Standalone Wrapper

glslangValidator is command-line tool for accessing the functionality above.

Status: Complete.

Tasks waiting to be done are documented as GitHub issues.

Other References

Also see the Khronos landing page for glslang as a reference front end:

https://www.khronos.org/opengles/sdk/tools/Reference-Compiler/

The above page, while not kept up to date, includes additional information regarding glslang as a reference validator.

How to Use Glslang

Execution of Standalone Wrapper

To use the standalone binary form, execute glslangValidator, and it will print a usage statement. Basic operation is to give it a file containing a shader, and it will print out warnings/errors and optionally an AST.

The applied stage-specific rules are based on the file extension:

  • .vert for a vertex shader
  • .tesc for a tessellation control shader
  • .tese for a tessellation evaluation shader
  • .geom for a geometry shader
  • .frag for a fragment shader
  • .comp for a compute shader

There is also a non-shader extension

  • .conf for a configuration file of limits, see usage statement for example

Building (CMake)

Instead of building manually, you can also download the binaries for your platform directly from the master-tot release on GitHub. Those binaries are automatically uploaded by the buildbots after successful testing and they always reflect the current top of the tree of the master branch.

Dependencies

  • A C++11 compiler. (For MSVS: use 2015 or later.)
  • CMake: for generating compilation targets.
  • make: Linux, ninja is an alternative, if configured.
  • Python 3.x: for executing SPIRV-Tools scripts. (Optional if not using SPIRV-Tools and the 'External' subdirectory does not exist.)
  • bison: optional, but needed when changing the grammar (glslang.y).
  • googletest: optional, but should use if making any changes to glslang.

Build steps

The following steps assume a Bash shell. On Windows, that could be the Git Bash shell or some other shell of your choosing.

1) Check-Out this project

cd <parent of where you want glslang to be>
git clone https://github.com/KhronosGroup/glslang.git

2) Check-Out External Projects

cd <the directory glslang was cloned to, "External" will be a subdirectory>
git clone https://github.com/google/googletest.git External/googletest

TEMPORARY NOTICE: additionally perform the following to avoid a current breakage in googletest:

cd External/googletest
git checkout 0c400f67fcf305869c5fb113dd296eca266c9725
cd ../..

If you wish to assure that SPIR-V generated from HLSL is legal for Vulkan, wish to invoke -Os to reduce SPIR-V size from HLSL or GLSL, or wish to run the integrated test suite, install spirv-tools with this:

./update_glslang_sources.py

3) Configure

Assume the source directory is $SOURCE_DIR and the build directory is $BUILD_DIR. First ensure the build directory exists, then navigate to it:

mkdir -p $BUILD_DIR
cd $BUILD_DIR

For building on Linux:

cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX="$(pwd)/install" $SOURCE_DIR
# "Release" (for CMAKE_BUILD_TYPE) could also be "Debug" or "RelWithDebInfo"

For building on Android:

cmake $SOURCE_DIR -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX="$(pwd)/install" -DANDROID_ABI=arm64-v8a -DCMAKE_BUILD_TYPE=Release -DANDROID_STL=c++_static -DANDROID_PLATFORM=android-24 -DCMAKE_SYSTEM_NAME=Android -DANDROID_TOOLCHAIN=clang -DANDROID_ARM_MODE=arm -DCMAKE_MAKE_PROGRAM=$ANDROID_NDK_ROOT/prebuilt/linux-x86_64/bin/make -DCMAKE_TOOLCHAIN_FILE=$ANDROID_NDK_ROOT/build/cmake/android.toolchain.cmake
# If on Windows will be -DCMAKE_MAKE_PROGRAM=%ANDROID_NDK_ROOT%\prebuilt\windows-x86_64\bin\make.exe
# -G is needed for building on Windows
# -DANDROID_ABI can also be armeabi-v7a for 32 bit

For building on Windows:

cmake $SOURCE_DIR -DCMAKE_INSTALL_PREFIX="$(pwd)/install"
# The CMAKE_INSTALL_PREFIX part is for testing (explained later).

The CMake GUI also works for Windows (version 3.4.1 tested).

Also, consider using git config --global core.fileMode false (or with --local) on Windows to prevent the addition of execution permission on files.

4) Build and Install

# for Linux:
make -j4 install

# for Windows:
cmake --build . --config Release --target install
# "Release" (for --config) could also be "Debug", "MinSizeRel", or "RelWithDebInfo"

If using MSVC, after running CMake to configure, use the Configuration Manager to check the INSTALL project.

Building (GN)

glslang can also be built with the GN build system.

1) Install depot_tools

Download depot_tools.zip, extract to a directory, and add this directory to your PATH.

2) Synchronize dependencies and generate build files

This only needs to be done once after updating glslang.

With the current directory set to your glslang checkout, type:

./update_glslang_sources.py
gclient sync --gclientfile=standalone.gclient
gn gen out/Default

3) Build

With the current directory set to your glslang checkout, type:

cd out/Default
ninja

If you need to change the GLSL grammar

The grammar in glslang/MachineIndependent/glslang.y has to be recompiled with bison if it changes, the output files are committed to the repo to avoid every developer needing to have bison configured to compile the project when grammar changes are quite infrequent. For windows you can get binaries from GnuWin32.

The command to rebuild is:

m4 -P MachineIndependent/glslang.m4 > MachineIndependent/glslang.y
bison --defines=MachineIndependent/glslang_tab.cpp.h
      -t MachineIndependent/glslang.y
      -o MachineIndependent/glslang_tab.cpp

The above commands are also available in the bash script in updateGrammar, when executed from the glslang subdirectory of the glslang repository. With no arguments it builds the full grammar, and with a "web" argument, the web grammar subset (see more about the web subset in the next section).

Building to WASM for the Web and Node

Building a standalone JS/WASM library for the Web and Node

Use the steps in Build Steps, with the following notes/exceptions:

  • emsdk needs to be present in your executable search path, PATH for Bash-like environments:
  • Wrap cmake call: emcmake cmake
  • Set -DBUILD_TESTING=OFF -DENABLE_OPT=OFF -DINSTALL_GTEST=OFF.
  • Set -DENABLE_HLSL=OFF if HLSL is not needed.
  • For a standalone JS/WASM library, turn on -DENABLE_GLSLANG_JS=ON.
  • For building a minimum-size web subset of core glslang:
    • turn on -DENABLE_GLSLANG_WEBMIN=ON (disables HLSL)
    • execute updateGrammar web from the glslang subdirectory (or if using your own scripts, m4 needs a -DGLSLANG_WEB argument)
    • optionally, for GLSL compilation error messages, turn on -DENABLE_GLSLANG_WEBMIN_DEVEL=ON
  • To get a fully minimized build, make sure to use brotli to compress the .js and .wasm files

Example:

emcmake cmake -DCMAKE_BUILD_TYPE=Release -DENABLE_GLSLANG_JS=ON \
    -DENABLE_HLSL=OFF -DBUILD_TESTING=OFF -DENABLE_OPT=OFF -DINSTALL_GTEST=OFF ..

Building glslang - Using vcpkg

You can download and install glslang using the vcpkg dependency manager:

git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
./bootstrap-vcpkg.sh
./vcpkg integrate install
./vcpkg install glslang

The glslang port in vcpkg is kept up to date by Microsoft team members and community contributors. If the version is out of date, please create an issue or pull request on the vcpkg repository.

Testing

Right now, there are two test harnesses existing in glslang: one is Google Test, one is the runtests script. The former runs unit tests and single-shader single-threaded integration tests, while the latter runs multiple-shader linking tests and multi-threaded tests.

Running tests

The runtests script requires compiled binaries to be installed into $BUILD_DIR/install. Please make sure you have supplied the correct configuration to CMake (using -DCMAKE_INSTALL_PREFIX) when building; otherwise, you may want to modify the path in the runtests script.

Running Google Test-backed tests:

cd $BUILD_DIR

# for Linux:
ctest

# for Windows:
ctest -C {Debug|Release|RelWithDebInfo|MinSizeRel}

# or, run the test binary directly
# (which gives more fine-grained control like filtering):
<dir-to-glslangtests-in-build-dir>/glslangtests

Running runtests script-backed tests:

cd $SOURCE_DIR/Test && ./runtests

If some tests fail with validation errors, there may be a mismatch between the version of spirv-val on the system and the version of glslang. In this case, it is necessary to run update_glslang_sources.py. See "Check-Out External Projects" above for more details.

Contributing tests

Test results should always be included with a pull request that modifies functionality.

If you are writing unit tests, please use the Google Test framework and place the tests under the gtests/ directory.

Integration tests are placed in the Test/ directory. It contains test input and a subdirectory baseResults/ that contains the expected results of the tests. Both the tests and baseResults/ are under source-code control.

Google Test runs those integration tests by reading the test input, compiling them, and then compare against the expected results in baseResults/. The integration tests to run via Google Test is registered in various gtests/*.FromFile.cpp source files. glslangtests provides a command-line option --update-mode, which, if supplied, will overwrite the golden files under the baseResults/ directory with real output from that invocation. For more information, please check gtests/ directory's README.

For the runtests script, it will generate current results in the localResults/ directory and diff them against the baseResults/. When you want to update the tracked test results, they need to be copied from localResults/ to baseResults/. This can be done by the bump shell script.

You can add your own private list of tests, not tracked publicly, by using localtestlist to list non-tracked tests. This is automatically read by runtests and included in the diff and bump process.

Programmatic Interfaces

Another piece of software can programmatically translate shaders to an AST using one of two different interfaces:

  • A new C++ class-oriented interface, or
  • The original C functional interface

The main() in StandAlone/StandAlone.cpp shows examples using both styles.

C++ Class Interface (new, preferred)

This interface is in roughly the last 1/3 of ShaderLang.h. It is in the glslang namespace and contains the following, here with suggested calls for generating SPIR-V:

const char* GetEsslVersionString();
const char* GetGlslVersionString();
bool InitializeProcess();
void FinalizeProcess();

class TShader
    setStrings(...);
    setEnvInput(EShSourceHlsl or EShSourceGlsl, stage,  EShClientVulkan or EShClientOpenGL, 100);
    setEnvClient(EShClientVulkan or EShClientOpenGL, EShTargetVulkan_1_0 or EShTargetVulkan_1_1 or EShTargetOpenGL_450);
    setEnvTarget(EShTargetSpv, EShTargetSpv_1_0 or EShTargetSpv_1_3);
    bool parse(...);
    const char* getInfoLog();

class TProgram
    void addShader(...);
    bool link(...);
    const char* getInfoLog();
    Reflection queries

For just validating (not generating code), substitute these calls:

    setEnvInput(EShSourceHlsl or EShSourceGlsl, stage,  EShClientNone, 0);
    setEnvClient(EShClientNone, 0);
    setEnvTarget(EShTargetNone, 0);

See ShaderLang.h and the usage of it in StandAlone/StandAlone.cpp for more details. There is a block comment giving more detail above the calls for setEnvInput, setEnvClient, and setEnvTarget.

C Functional Interface (original)

This interface is in roughly the first 2/3 of ShaderLang.h, and referred to as the Sh*() interface, as all the entry points start Sh.

The Sh*() interface takes a "compiler" call-back object, which it calls after building call back that is passed the AST and can then execute a back end on it.

The following is a simplified resulting run-time call stack:

ShCompile(shader, compiler) -> compiler(AST) -> <back end>

In practice, ShCompile() takes shader strings, default version, and warning/error and other options for controlling compilation.

Basic Internal Operation

  • Initial lexical analysis is done by the preprocessor in MachineIndependent/Preprocessor, and then refined by a GLSL scanner in MachineIndependent/Scan.cpp. There is currently no use of flex.

  • Code is parsed using bison on MachineIndependent/glslang.y with the aid of a symbol table and an AST. The symbol table is not passed on to the back-end; the intermediate representation stands on its own. The tree is built by the grammar productions, many of which are offloaded into ParseHelper.cpp, and by Intermediate.cpp.

  • The intermediate representation is very high-level, and represented as an in-memory tree. This serves to lose no information from the original program, and to have efficient transfer of the result from parsing to the back-end. In the AST, constants are propagated and folded, and a very small amount of dead code is eliminated.

    To aid linking and reflection, the last top-level branch in the AST lists all global symbols.

  • The primary algorithm of the back-end compiler is to traverse the tree (high-level intermediate representation), and create an internal object code representation. There is an example of how to do this in MachineIndependent/intermOut.cpp.

  • Reduction of the tree to a linear byte-code style low-level intermediate representation is likely a good way to generate fully optimized code.

  • There is currently some dead old-style linker-type code still lying around.

  • Memory pool: parsing uses types derived from C++ std types, using a custom allocator that puts them in a memory pool. This makes allocation of individual container/contents just few cycles and deallocation free. This pool is popped after the AST is made and processed.

    The use is simple: if you are going to call new, there are three cases:

    • the object comes from the pool (its base class has the macro POOL_ALLOCATOR_NEW_DELETE in it) and you do not have to call delete

    • it is a TString, in which case call NewPoolTString(), which gets it from the pool, and there is no corresponding delete

    • the object does not come from the pool, and you have to do normal C++ memory management of what you new

  • Features can be protected by version/extension/stage/profile: See the comment in glslang/MachineIndependent/Versions.cpp.

Comments
  • Call for input on HLSL -> SPIR-V translation

    Call for input on HLSL -> SPIR-V translation

    There have been multiple requests for HLSL -> SPIR-V translation. Given the likelihood of multiple ways of doing this and multiple parties interested in it, this is a place to discuss.

    One possible way of doing it is introduced in the hlsl-frontend branch. If this method looks good, it needs to be finished by completing all the HLSL grammar details, translating it into the same AST that GLSL is translated into. The grammar -> AST does not have much functionality yet, but is otherwise set up with relatively complete infrastructure throughout glslang -> SPIR-V.

    See the commits at https://github.com/KhronosGroup/glslang/commits/hlsl-frontend, summarized below. The initial commits are less HLSL-specific and might be good steps to take regardless.

    1. Generalize GLSL's "main" to a settable entry point name.
    2. Support multiple source languages, adding HLSL as an option.
    3. Refactor TParseContext into 3 level inheritance. [ This is needed anyway. ]
    4. HLSL: Plumb in HLSL parse context and keywords, and most basic HLSL parser and test.
    5. ... N. < series of incremental functionality to the HLSL parser >
    enhancement help wanted SPIR-V HLSL 
    opened by johnkslang 52
  • GL_ext_vulkan_glsl_relaxed extension support, and cross stage aware IO mapper

    GL_ext_vulkan_glsl_relaxed extension support, and cross stage aware IO mapper

    This merge implements https://github.com/KhronosGroup/GLSL/blob/master/extensions/ext/GL_EXT_vulkan_glsl_relaxed.txt. Additionally, it implements fixes to IO remapping that solve issues from #2151. Specifically, auto-binding is aware of binding usage across stages so different stages don't use the same bindings for different resources.

    opened by mbechard 44
  • HLSL: Buffer<> should probably map to a uniform texel buffer

    HLSL: Buffer<> should probably map to a uniform texel buffer

    Currently when using the HLSL frontend a declaration like: Buffer<uint> ... will generate SPIRV that expects a storage texel buffer to be bound. That's somewhat inconsistent with DX where Buffer objects are read-only and support nearly all formats, while the more general RWBuffer's have a much smaller set of format support.

    I believe in this case it should be mapping this to a "uniform texel buffer" in SPIRV/Vulkan instead, as this should be the analogous concept (read-only buffer lookups that can go through texture hardware and thus support the broadest set of formats).

    question HLSL 
    opened by punkUser 40
  • Platform dependence on parsing floating-point numbers.

    Platform dependence on parsing floating-point numbers.

    Hi,

    I just upgraded to the latest Vulkan SDK for macOS (v1.1.77.0) available on LunarG. I am using HLSL as shading language and noticed that one of my shaders is now broken after switching to the new version of glslangValidator. After some investigation, it turns out that global const variable values are incorrect.

    Here is a simple repro case:

    HLSL:

    // test.frag.hlsl

static const float kValue = 0.5f;

float4 main() : SV_TARGET0
{
	return float4( kValue );
}

    Compiled via "glslangValidator -Os -V -e main -o test.frag.spv test.frag.hlsl".

    Output of "spirv-dis test.frag.spv":

    ; SPIR-V
; Version: 1.0
; Generator: Khronos Glslang Reference Front End; 7
; Bound: 17
; Schema: 0
			   OpCapability Shader
		  %1 = OpExtInstImport "GLSL.std.450"
			   OpMemoryModel Logical GLSL450
			   OpEntryPoint Fragment %main "main" %_entryPointOutput
			   OpExecutionMode %main OriginUpperLeft
			   OpSource HLSL 500
			   OpName %main "main"
			   OpName %_entryPointOutput "@entryPointOutput"
			   OpDecorate %_entryPointOutput Location 0
	   %void = OpTypeVoid
		  %3 = OpTypeFunction %void
	  %float = OpTypeFloat 32
	%v4float = OpTypeVector %float 4
	%float_0 = OpConstant %float 0
		 %12 = OpConstantComposite %v4float %float_0 %float_0 %float_0 %float_0
%_ptr_Output_v4float = OpTypePointer Output %v4float
%_entryPointOutput = OpVariable %_ptr_Output_v4float Output
	   %main = OpFunction %void None %3
		  %5 = OpLabel
			   OpStore %_entryPointOutput %12
			   OpReturn
			   OpFunctionEnd

    Output of "spirv-cross test.frag.spv":

    #version 450

layout(location = 0) out vec4 _entryPointOutput;

void main()
{
	_entryPointOutput = vec4(0.0);
}

    I have seen other places in larger shaders where it would replace the constant values incorrectly with uintBitsToFloat(0x7f800000u) (equivalent of INF). Is this already fixed in mainline?

    Thank you, Axel

    bug question PP 
    opened by awefers 37
  • Support precise qualifier

    Support precise qualifier

    Based on @yavn 's prior work: ad62991

    Goal: Arithmetic instructions that contribute to calculating 'precise' variables, should be decorated with 'NoContraction' decorator.

    Approach: Add a AST traversing pass at the end of shader parsing, called in DoFullParse(), to propagate 'noContraction' qualifier to AST nodes. Then in GlslangToSpvTraverser, add decoration for the nodes with 'noContraction' qualifier.

    To propagate 'noContraction' qualifier along lvalues, we need to use symbol node IDs to record the involved lvalues.

    The pass to propagate 'noContraction' qualifier is consist of three parts:

    1. Populate the 'precise' qualifiers to bottom symbol nodes as preprocessing

    Some 'precise' qualifiers are not attached to symbol nodes, but their parent nodes, which might be binary nodes, unary nodes or aggregate nodes (not very sure here). Populate the 'precise' of these nodes to their bottom symbol nodes so that we can use symbol IDs to propagate 'NoContraction' through lvalues.

    Example shader:

    
layout(triangles, equal_spacing) in;
layout(location = 0) in highp vec2 in_te_position[];
layout(location = 0) out mediump vec4 in_f_color;
precise gl_Position;

void main(void) {
  highp vec2 pos = vec2(3.0, 4.0);
  pos += 0.04;
  gl_Position = vec4(pos, 0.0, 1.0);
}

    In the AST, a binary node representing gl_Position is marked as 'precise', but not its underlying symbol node:

    move second child to first child (temp highp 4-component vector of float)
  gl_Position: direct index for structure (precise gl_Position highp 4-component vector of float Position)
    '[email protected]' (out block{precise gl_Position highp 4-component vector of float Position gl_Position, gl_PointSize highp float PointSize gl_PointSize})
    Constant:
      0 (const uint)
  Construct vec4 (temp highp 4-component vector of float)
    'pos' (temp highp 2-component vector of float)
    Constant:
      0.000000
    Constant:
      1.000000

    This first procedure will populate 'precise' from the binary node: gl_Position, to its underlying symbol node: [email protected].

    1. Collect symbol and their defining nodes (assignment nodes), and collect a set of symbol IDs to be processed as work set with source-specified 'precise' variables.

    2. Start with the initial 'precise' variables collected. Mark arithmetic instructions that contribute to these 'precise' variables in the defining nodes (the assignment node subtrees) as 'noContraction', and add the symbols involved to the work set. Remove the processed symbol IDs from the work set. Repeat until the work set is empty.

    In the back-end (GlslangToSpvTraverser), when visiting binary/unary nodes, check if the current node is a 'noContraction' node. If so, add 'NoContraction' decoration upon the rvalue ID of the binary/unary operation result.

    Expectation:

    1. In the AST, all the arithmetic operations that lead to defining 'precise' symbols are marked with 'noContraction' qualifier.
    2. In the emitted SPIV code, 'NoContraction' decorations are added to arithmetic operations. Note the 'NoContraction' decorations are not referencing 'precise' variables (the pointers), but the arithmetic operations.

    Known issue: The operations marked as 'noContraction' are superset of the 'optimal' set. The problem is that we didn't build dominator tree. Example:

    precise int result;
result = a + b + 2;
a = d + 3;

    Because symbol a is involved in the calculation of result, once before, a will be added to the work set, then the addition d + 3 will be marked with noContraction. But it is actually not necessary.

    opened by Qining 35
  • Enable HLSL legalization

    Enable HLSL legalization

    Also added known-good mechanism to fetch latest validated spirv-tools. Also added -Od and -Os to disable optimizer and optimize for size.

    Fetching spirv-tools is optional for both glsl and hlsl. Legalization of hlsl is done by default if spirv-opt is present at cmake time. Optimization for glsl is currently done through the option -Os.

    Legalization testing is currently only done on four existing shaders. A separate baseLegalResults directory holds those results. All previous testing is done with the optimizer disabled.

    opened by greg-lunarg 31
  • HLSL: intermittent assert/crash in spvtools::opt::analysis::DefUseManager::AnalyzeInstUse

    HLSL: intermittent assert/crash in spvtools::opt::analysis::DefUseManager::AnalyzeInstUse

    I updated to the latest glslang master (to commit 798d005c) and in trying to rebuild all of our HLSL shaders ran into an intermittent crash in Release (and intermittent assert in Debug). It is most likely a spirv-opt bug, but it is hard for me to say for sure because it is hard to reproduce.

    Repro:

       glslangValidator -V --sep MainVs -e main -Os --iy -D crash_hlsl.vert

    Intermittently, I will see the following assert:

     	glslangValidator.exe!issue_debug_notification(const wchar_t * const message) Line 125	C++
 	glslangValidator.exe!__acrt_report_runtime_error(const wchar_t * message) Line 142	C++
 	glslangValidator.exe!abort() Line 61	C++
 	glslangValidator.exe!common_assert_to_stderr_direct(const wchar_t * const expression, const wchar_t * const file_name, const unsigned int line_number) Line 124	C++
 	glslangValidator.exe!common_assert_to_stderr<wchar_t>(const wchar_t * const expression, const wchar_t * const file_name, const unsigned int line_number) Line 142	C++
 	glslangValidator.exe!common_assert<wchar_t>(const wchar_t * const expression, const wchar_t * const file_name, const unsigned int line_number, void * const return_address) Line 383	C++
 	glslangValidator.exe!_wassert(const wchar_t * expression, const wchar_t * file_name, unsigned int line_number) Line 405	C++
>	glslangValidator.exe!spvtools::opt::analysis::DefUseManager::AnalyzeInstUse(spvtools::ir::Instruction * inst) Line 54	C++
 	[External Code]	
 	glslangValidator.exe!spvtools::ir::Instruction::ForEachInst(const std::function<void __cdecl(spvtools::ir::Instruction *)> & f, bool run_on_debug_line_insts) Line 405	C++
 	glslangValidator.exe!spvtools::ir::BasicBlock::ForEachInst(const std::function<void __cdecl(spvtools::ir::Instruction *)> & f, bool run_on_debug_line_insts) Line 182	C++
 	glslangValidator.exe!spvtools::ir::Function::ForEachInst(const std::function<void __cdecl(spvtools::ir::Instruction *)> & f, bool run_on_debug_line_insts) Line 48	C++
 	glslangValidator.exe!spvtools::ir::Module::ForEachInst(const std::function<void __cdecl(spvtools::ir::Instruction *)> & f, bool run_on_debug_line_insts) Line 86	C++
 	glslangValidator.exe!spvtools::opt::analysis::DefUseManager::AnalyzeDefUse(spvtools::ir::Module * module) Line 177	C++
 	glslangValidator.exe!spvtools::opt::analysis::DefUseManager::DefUseManager(spvtools::ir::Module * module) Line 105	C++
 	glslangValidator.exe!spvtools::ir::IRContext::IsConsistent() Line 176	C++
 	glslangValidator.exe!spvtools::opt::Pass::Run(spvtools::ir::IRContext * ctx) Line 110	C++
 	glslangValidator.exe!spvtools::opt::PassManager::Run(spvtools::ir::IRContext * context) Line 24	C++
 	glslangValidator.exe!spvtools::Optimizer::Run(const unsigned int * original_binary, unsigned __int64 original_binary_size, std::vector<unsigned int,std::allocator<unsigned int> > * optimized_binary) Line 131	C++
 	glslangValidator.exe!glslang::GlslangToSpv(const glslang::TIntermediate & intermediate, std::vector<unsigned int,std::allocator<unsigned int> > & spirv, spv::SpvBuildLogger * logger, glslang::SpvOptions * options) Line 6106	C++
 	glslangValidator.exe!CompileAndLinkShaderUnits(std::vector<ShaderCompUnit,std::allocator<ShaderCompUnit> > compUnits) Line 946	C++
 	glslangValidator.exe!CompileAndLinkShaderFiles(glslang::TWorklist & Worklist) Line 1023	C++
 	glslangValidator.exe!singleMain() Line 1089	C++
 	glslangValidator.exe!main(int argc, char * * argv) Line 1142	C++
 	[External Code]

    In our distributed shader compile system that compiles 100k+ shaders, I will intermittently get a crash. I've been unable to isolate this to a 100% reproducer. However, if I run in a debug build with the command-line above enough times I will see the assert from time-to-time. It seems like some kind of memory corruption or non-determinism.

    crash_hlsl.zip

    opened by danginsburg 29
  • ANGLE tests broken by recent glslang change

    ANGLE tests broken by recent glslang change

    A recent commit broke ANGLE testing (which pulls/uses glslang downstream). We believe it's this commit (by Will Brown, with 1st line "Implement GL_EXT_vulkan_glsl_relaxed option"): https://chromium.googlesource.com/external/github.com/KhronosGroup/glslang.git/+/ecc9b9149f8f6367e4dc109e1f9ce3635a851968

    Here is a commit where our auto-roller pulled glslang and first saw the problem: https://chromium-review.googlesource.com/c/chromium/src/+/2744336

    If you click on the red "Tryjobs" you can see a page like this: https://ci.chromium.org/ui/p/chromium/builders/try/linux-swangle-try-x64/2314/overview

    And then click on the first "Shard #0 (failed)" link, you'll see this: https://chromium-swarm.appspot.com/task?id=522efcb65413b410#dEQP.KHR_GLES31%2Fcore_explicit_uniform_location_uniformlocallstages,dEQP.KHR_GLES31%2Fcore_explicit_uniform_location_uniformlocarraysnonspaced,dEQP.KHR_GLES31%2Fcore_explicit_uniform_location_uniformlocarraysofarrays,dEQP.KHR_GLES31%2Fcore_explicit_uniform_location_uniformlocarraysspaced,dEQP.KHR_GLES31%2Fcore_explicit_uniform_location_uniformlocimplicitinsomestages,dEQP.KHR_GLES31%2Fcore_explicit_uniform_location_uniformlocmixwithimplicit,dEQP.KHR_GLES31%2Fcore_explicit_uniform_location_uniformlocmixwithimplicit2,dEQP.KHR_GLES31%2Fcore_explicit_uniform_location_uniformlocmixwithimplicit3,dEQP.KHR_GLES31%2Fcore_explicit_uniform_location_uniformlocmixwithimplicitmax,dEQP.KHR_GLES31%2Fcore_explicit_uniform_location_uniformlocmixwithimplicitmaxarray,dEQP.KHR_GLES31%2Fcore_explicit_uniform_location_uniformlocmultipleuniforms,dEQP.KHR_GLES31%2Fcore_explicit_uniform_location_uniformloctypesmat,dEQP.KHR_GLES31%2Fcore_explicit_uniform_location_uniformloctypesmix,dEQP.KHR_GLES31%2Fcore_explicit_uniform_location_uniformloctypesstructs,dEQP.KHR_GLES31%2Fcore_shader_storage_buffer_object_advancedmatrixvsfs,dEQP.KHR_GLES31%2Fcore_shader_storage_buffer_object_basicatomiccase1vsfs,dEQP.KHR_GLES31%2Fcore_texture_storage_multisample_FunctionalTests_blitting_multisampled_integer_attachment

    Here's the failure of one of the tests:

    [87/3472] dEQP.KHR_GLES31/core_explicit_uniform_location_uniformlocallstages (FAIL)

[ RUN      ] dEQP.KHR_GLES31/core_explicit_uniform_location_uniformlocallstages
KHR-GLES31.core.explicit_uniform_location.uniform-loc-all-stages
../../third_party/angle/src/tests/deqp_support/angle_deqp_gtest.cpp:53: Failure
Failed
glslang_wrapper_utils.cpp:1059 (LinkProgram): Internal error linking Vulkan shaders:
ERROR: Linking unknown stage stage: Anonymous member name used for global variable or other anonymous member: 
layout( column_major std140 offset=0) uniform highp 4-component vector of float


Stack trace:
#0 0x55de2001aa90 angle::(anonymous namespace)::HandlePlatformError()
#1 0x7fd34aae9e28 angle::LoggingAnnotator::logMessage()
#2 0x7fd34af8a185 gl::LogMessage::~LogMessage()
#3 0x7fd34ae1d010 rx::(anonymous namespace)::LinkProgram()
#4 0x7fd34ae1c6d4 rx::GlslangGetShaderSpirvCode()
#5 0x7fd34ad38ed9 rx::GlslangWrapperVk::GetShaderCode()
#6 0x7fd34ad3cbe5 rx::ShaderInfo::initShaders()
#7 0x7fd34ad4f1f2 rx::ProgramVk::link()
#8 0x7fd34aaf48f9 gl::Program::linkImpl()
#9 0x7fd34aaf3fe2 gl::Program::link()
#10 0x7fd34aaa4e73 gl::Context::linkProgram()
#11 0x7fd34a9cde69 GL_LinkProgram
#12 0x7fd34f2a5354 glu::CallLogWrapper::glLinkProgram()
#13 0x7fd34efe0a19 glcts::(anonymous namespace)::ExplicitUniformLocationCaseBase::CreatePrograms()
#14 0x7fd34efd97e9 glcts::(anonymous namespace)::ExplicitUniformLocationCaseBase::doRun()
#15 0x7fd34efd760b glcts::(anonymous namespace)::ExplicitUniformLocationCaseBase::doRun()
#16 0x7fd34efe6dad glcts::(anonymous namespace)::UniformLocMultipleStages::Run()
#17 0x7fd34eedddc6 deqp::TestSubcase::iterate()
#18 0x7fd34f0fa165 es31cts::TestCaseWrapper::iterate()
#19 0x7fd34f27e816 tcu::RandomOrderExecutor::executeInner()
#20 0x7fd34f27e747 tcu::RandomOrderExecutor::execute()
#21 0x7fd34eddaa50 deqp_libtester_run()
#22 0x55de200124bf angle::(anonymous namespace)::dEQP_KHR_GLES31_Test::TestBody()

../../third_party/angle/src/tests/deqp_support/angle_deqp_gtest.cpp:53: Failure
Failed
glslang_wrapper_utils.cpp:1059 (LinkProgram): Internal error linking Vulkan shaders:
ERROR: Linking unknown stage stage: Anonymous member name used for global variable or other anonymous member: 
layout( column_major std140 offset=0) uniform highp 4-component vector of float


Stack trace:
#0 0x55de2001aa90 angle::(anonymous namespace)::HandlePlatformError()
#1 0x7fd34aae9e28 angle::LoggingAnnotator::logMessage()
#2 0x7fd34af8a185 gl::LogMessage::~LogMessage()
#3 0x7fd34ae1d010 rx::(anonymous namespace)::LinkProgram()
#4 0x7fd34ae1c6d4 rx::GlslangGetShaderSpirvCode()
#5 0x7fd34ad38ed9 rx::GlslangWrapperVk::GetShaderCode()
#6 0x7fd34ad3cbe5 rx::ShaderInfo::initShaders()
#7 0x7fd34ad4f1f2 rx::ProgramVk::link()
#8 0x7fd34aaf48f9 gl::Program::linkImpl()
#9 0x7fd34aaf3fe2 gl::Program::link()
#10 0x7fd34aaa4e73 gl::Context::linkProgram()
#11 0x7fd34a9cde69 GL_LinkProgram
#12 0x7fd34f2a5354 glu::CallLogWrapper::glLinkProgram()
#13 0x7fd34efe0ad7 glcts::(anonymous namespace)::ExplicitUniformLocationCaseBase::CreatePrograms()
#14 0x7fd34efd97e9 glcts::(anonymous namespace)::ExplicitUniformLocationCaseBase::doRun()
#15 0x7fd34efd760b glcts::(anonymous namespace)::ExplicitUniformLocationCaseBase::doRun()
#16 0x7fd34efe6dad glcts::(anonymous namespace)::UniformLocMultipleStages::Run()
#17 0x7fd34eedddc6 deqp::TestSubcase::iterate()
#18 0x7fd34f0fa165 es31cts::TestCaseWrapper::iterate()
#19 0x7fd34f27e816 tcu::RandomOrderExecutor::executeInner()
#20 0x7fd34f27e747 tcu::RandomOrderExecutor::execute()
#21 0x7fd34eddaa50 deqp_libtester_run()
#22 0x55de200124bf angle::(anonymous namespace)::dEQP_KHR_GLES31_Test::TestBody()

../../third_party/angle/src/tests/deqp_support/angle_deqp_gtest.cpp:412: Failure
Value of: testSucceeded
  Actual: false
Expected: true
Stack trace:
#0 0x55de2001269e angle::(anonymous namespace)::dEQP_KHR_GLES31_Test::TestBody()

[  FAILED  ] dEQP.KHR_GLES31/core_explicit_uniform_location_uniformlocallstages, where GetParam() = 2130 (66 ms)
[88/3472] dEQP.KHR_GLES31/core_explicit_uniform_location_uniformlocimplicitinsomestages (FAIL)
    bug SPIR-V GLSL/ESSL Linker 
    opened by ianelliottus 28
  • Mapping register/packoffset to what elements in TQualifier do?

    Mapping register/packoffset to what elements in TQualifier do?

    I'm trying to get the explicit bindings in HLSL to work correctly, but I don't understand all the fields in TQualifer. Layout and Set make sense, What happens when conflicting fields are declared? But specifically, these are my guesses, are they right?

    1. layoutAlign - is this the alignment in bytes of the current field? Does this need to be filled out?
    2. layoutlocation - is this a virtual register number assuming there are 4 component registers in the case of globals?
    3. layoutcomponent - the component used in conjunction with layoutlocation? if I have a 2d value starting at y would that be valid?
    4. layoutIndex -How is different then layoutlocation? Or is this used for objects where layoutlocation is used for numeric uniforms?
    5. layoutOffset - is this a master override for all of the others, an offset in bytes to the desired type? Obv only valid for uniform numerics, not objects.
    question Missing Functionality HLSL 
    opened by dankbaker 25
  • fatal error: 'spirv-tools/libspirv.h' file not found

    fatal error: 'spirv-tools/libspirv.h' file not found

    Chromium is failing to build with the latest glslang:

    FAILED: obj/third_party/glslang/src/glslang_validator/StandAlone.o 
../../build/toolchain/clang_code_coverage_wrapper.py --target-os=linux /home/timvp/code/depot_tools/.cipd_bin/gomacc ../../third_party/llvm-build/Release+Asserts/bin/clang++ -MMD -MF obj/third_party/glslang/src/glslang_validator/StandAlone.o.d -DENABLE_OPT=1 -DDCHECK_ALWAYS_ON=1 -DUSE_UDEV -DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DUSE_OZONE=1 -DUSE_X11=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -DCR_CLANG_REVISION=\"llvmorg-12-init-5627-gf086e85e-2\" -D_LIBCPP_ABI_UNSTABLE -D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS -D_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS -D_LIBCPP_ENABLE_NODISCARD -D_LIBCPP_DEBUG=0 -DCR_LIBCXX_REVISION=375504 -DCR_SYSROOT_HASH=5f64b417e1018dcf8fcc81dc2714e0f264b9b911 -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DENABLE_HLSL=1 -Igen/third_party/glslang/src/include -I../.. -Igen -I../../third_party/glslang/src -Woverflow -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -funwind-tables -fPIC -pthread -fcolor-diagnostics -fmerge-all-constants -fcrash-diagnostics-dir=../../tools/clang/crashreports -mllvm -instcombine-lower-dbg-declare=0 -mllvm -enable-dse-memoryssa=false -fcomplete-member-pointers -m64 -march=x86-64 -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -Xclang -fdebug-compilation-dir -Xclang . -no-canonical-prefixes -O2 -fno-ident -fdata-sections -ffunction-sections -fno-omit-frame-pointer -g0 -ftrivial-auto-var-init=pattern -fprofile-instr-generate -fcoverage-mapping -mllvm -limited-coverage-experimental=true -fno-use-cxa-atexit -fvisibility=hidden -Xclang -add-plugin -Xclang find-bad-constructs -Xclang -plugin-arg-find-bad-constructs -Xclang check-ipc -Wheader-hygiene -Wstring-conversion -Wtautological-overlap-compare -Werror -Wall -Wno-unused-variable -Wno-misleading-indentation -Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing -Wno-unneeded-internal-declaration -Wno-undefined-var-template -Wno-psabi -Wno-ignored-pragma-optimize -Wno-implicit-int-float-conversion -Wno-final-dtor-non-final-class -Wno-builtin-assume-aligned-alignment -Wno-deprecated-copy -Wno-non-c-typedef-for-linkage -Wmax-tokens -Wno-conversion -std=c++14 -fno-trigraphs -Wno-trigraphs -fno-exceptions -fno-rtti -nostdinc++ -isystem../../buildtools/third_party/libc++/trunk/include -isystem../../buildtools/third_party/libc++abi/trunk/include --sysroot=../../build/linux/debian_sid_amd64-sysroot -fvisibility-inlines-hidden -c ../../third_party/glslang/src/StandAlone/StandAlone.cpp -o obj/third_party/glslang/src/glslang_validator/StandAlone.o
In file included from ../../third_party/glslang/src/StandAlone/StandAlone.cpp:48:
In file included from ../../third_party/glslang/src/StandAlone/../SPIRV/GlslangToSpv.h:42:
../../third_party/glslang/src/StandAlone/../SPIRV/SpvTools.h:47:10: fatal error: 'spirv-tools/libspirv.h' file not found
#include "spirv-tools/libspirv.h"
         ^~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

    The file appears to be present at External/spirv-tools/include/spirv-tools/libspirv.h, but it just can't be found for whatever reason.

    Any ideas?

    bug Infrastructure 
    opened by timvpGoogle 23
  • spirv: Support initializers on uniforms

    spirv: Support initializers on uniforms

    If a uniform has an initializer it will now be given as the optional initializer operand to the OpVariable instruction.

    Fixes: https://github.com/KhronosGroup/glslang/issues/1259

    Signed-off-by: Neil Roberts [email protected] (the code) Signed-off-by: Alejandro Piñeiro [email protected] (the tests)

    SPIR-V WIP (don't merge) GLSL/ESSL 
    opened by infapi00 21
  • Crash when trying to access a non-existing member of a struct returned by a function

    Crash when trying to access a non-existing member of a struct returned by a function

    If you have a function returning a struct and you directly try to access a member from this struct from the function call, but this member does not actually exist, glslang, as a library, and glslangValidator will crash.

    Shader example :

    #version 460

struct A {
	float x;
};

A test() {
	return A(1.0);
}

void main() {
	test().z; // A.z does not exist, causes a crash
}

    Crash happens during the parsing stage, in ParseHelper.cpp, in the handleDotDereference function : https://github.com/KhronosGroup/glslang/blob/06a7078ce74ab5c7801a165b8145859678831fb8/glslang/MachineIndependent/ParseHelper.cpp#L1037-L1042

    The while loop is checking if baseSymbol is a TIntermSymbol, and if it is not, tries to dereference a binary node, which is nullptr in this case, causing a crash.

    The difference between

    test().z; // A.z does not exist, causes a crash

    and

    A c = A(1.0);
float b = c.z; // A.z does not exist, does not crash

    is that baseSymbol is of type TIntermAggregate in the first case and TIntermSymbol in the second.

    TIntermAggregate does not have a getAsSymbolNode nor a getAsBinaryNode member function and use the base class TIntermNode implementations instead, which both return nullptr.

    getAsBinaryNode is implemented by TIntermBinary, so

    auto baseSymbol = base;
while (baseSymbol->getAsSymbolNode() == nullptr) 
    baseSymbol = baseSymbol->getAsBinaryNode()->getLeft();

    is trying to get a TIntermSymbol and estimates that if baseSymbol is not a TIntermSymbol, then it is a TIntermBinary, which is not the case here, as it is a TIntermAggregate.

    One possible fix is to isolate both cases, one where baseSymbol is a TIntermBinary and one where baseSymbol is a TIntermAggregate, then getting the name of either the TIntermSymbol or the TIntermAggregate and write a different message when the error is from a TIntermAggregate :

    auto baseSymbol = base;
while (baseSymbol->getAsSymbolNode() == nullptr) {
    if (baseSymbol->getAsBinaryNode() == nullptr) {
        break;
    }
    baseSymbol = baseSymbol->getAsBinaryNode()->getLeft();
}
TString structName;
if (baseSymbol->getAsSymbolNode() != nullptr) {
    structName.append("\'").append(baseSymbol->getAsSymbolNode()->getName().c_str()).append("\'");
    error(loc, "no such field in structure", field.c_str(), structName.c_str());
} else if (baseSymbol->getAsAggregate() != nullptr) {
    structName.append("\'").append(baseSymbol->getAsAggregate()->getName().c_str()).append("\'");
    structName.erase(structName.end() - 2);
    error(loc, "no such field in structure returned by function", field.c_str(), structName.c_str());
}

    I don't know if any more types can reach this code path so I am not sure if it actually works in all cases.

    With the example code :

    ERROR: 0:15: 'z' : no such field in structure returned by function 'test'
ERROR: 0:15: '' : compilation terminated
ERROR: 2 compilation errors.  No code generated.
    opened by ZaOniRinku 0
  • Usage of any fields of gl_MeshPrimitivesEXT is enabling capability FragmentShadingRateKHR even if gl_PrimitiveShadingRateEXT is not used

    Usage of any fields of gl_MeshPrimitivesEXT is enabling capability FragmentShadingRateKHR even if gl_PrimitiveShadingRateEXT is not used

    You can see this bug in glslang's own test suite:

    ./Test/spv.ext.meshShaderBuiltins.mesh source file uses gl_MeshPrimitivesEXT but does not use gl_PrimitiveShadingRateEXT field in that array of structures. Despite that, the output for that test (./Test/baseResults/spv.ext.meshShaderBuiltins.mesh.out) starts with:

    spv.ext.meshShaderBuiltins.mesh
// Module Version 10400
// Generated by (magic number): 8000b
// Id's are bound by 158

                              Capability ClipDistance
                              Capability CullDistance
                              Capability FragmentShadingRateKHR
                              Capability DrawParameters
                              Capability MultiView
                              Capability MeshShadingEXT
                              Extension  "SPV_EXT_mesh_shader"
                              Extension  "SPV_KHR_fragment_shading_rate"

    Out of these, all capabilities other than FragmentShadingRateKHR are expected, as the shader does fill them. It looks like glslang's SPV output calls TGlslangToSpvTraverser::decorateStructType whenever the variable of that type is being written to at all, but doesn't filter out members that were never used in the shader, and as such we get FragmentShadingRateKHR capability.

    The reason why this is a problem is that this results in a further validation layer error when loading the shader, assuming VK_KHR_fragment_shading_rate is not used:

    VUID-VkShaderModuleCreateInfo-pCode-01091(ERROR / SPEC): msgNum: -1480880714 - Validation Error: [ VUID-VkShaderModuleCreateInfo-pCode-01091 ] Object 0: handle = 0x55555606d9f0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0xa7bb8db6 | vkCreateShaderModule(): The SPIR-V Capability (FragmentShadingRateKHR) was declared, but none of the requirements were met to use it. The Vulkan spec states: If pCode declares any of the capabilities listed in the SPIR-V Environment appendix, one of the corresponding requirements must be satisfied (https://vulkan.lunarg.com/doc/view/1.3.236.0/linux/1.3-extensions/vkspec.html#VUID-VkShaderModuleCreateInfo-pCode-01091)
    bug SPIR-V GLSL/ESSL 
    opened by zeux 1
  • Rename

    Rename "External" to "external"; fix Bazel rules.

    The "External" directory is unfortunately incompatible with Bazel. I'm renaming it to "external" which is compatible. In this PR I'm also fixing the Bazel rules so that one can build this straight from source.

    opened by RafaelMarinheiro 0
  • 1.3.236.0: test suite is failing in `glslang-testsuite` unit

    1.3.236.0: test suite is failing in `glslang-testsuite` unit

    cmake setup

    -- Cache values
BUILD_EXTERNAL:BOOL=ON
BUILD_SHARED_LIBS:BOOL=ON
BUILD_TESTING:BOOL=ON
CMAKE_BUILD_TYPE:STRING=RelWithDebInfo
CMAKE_INSTALL_PREFIX:PATH=/usr
ENABLE_CTEST:BOOL=ON
ENABLE_EXCEPTIONS:BOOL=OFF
ENABLE_GLSLANG_BINARIES:BOOL=ON
ENABLE_GLSLANG_JS:BOOL=OFF
ENABLE_HLSL:BOOL=ON
ENABLE_OPT:BOOL=ON
ENABLE_PCH:BOOL=ON
ENABLE_RTTI:BOOL=OFF
ENABLE_SPVREMAPPER:BOOL=ON
SKIP_GLSLANG_INSTALL:BOOL=OFF
USE_CCACHE:BOOL=OFF
    opened by kloczek 4
  • Unsupported types in HLSL: float16_t2 and float16_t3

    Unsupported types in HLSL: float16_t2 and float16_t3

    When trying to compile the shader from here I got the following compilation error:

    ERROR: 0:21: 'scalar or vector type' : Expected 
ERROR: 0:21: 'declaration' : Expected 
(21): error at column 22, HLSL parsing failed.

    So these types (float16_t2 and float16_t3) don't get treated as actual types by the compiler while float16_t exists. As a workaround it is possible to make a typedef before the actual code using them. But a proper solution would be better.

    To clarify I have tried whether it just depends on the 16bit type feature but independent of me enabling it, the vector types are not treated as existing types.

    enhancement SPIR-V HLSL 
    opened by TheJackiMonster 1
  • HLSL: Order of const keyword can break parsing

    HLSL: Order of const keyword can break parsing

    While trying to compile some HLSL shaders I encountered the following issue with the const keyword using for local variables and function arguments.

    If you use following syntax, everything is fine:

    const float f = 1.0f;

    But using the following syntax will throw an error by the HLSL parser:

    float const f = 1.0f;

    Unfortunately some shaders are written by people crosing both variants. ^^'

    Another example how the current parser seems to evaluate code with functions:

    GOOD:

    void test(const float3 f) {}

    BAD:

    void test(float3 const f) {}
    enhancement HLSL 
    opened by TheJackiMonster 1
Releases(master-tot)
Owner
The Khronos Group
Connecting Software to Silicon
The Khronos Group
GitHub
HLSL Parser and Translator for HLSL, GLSL, and MSL.

HLSLParser This is a fork of Unknownworld's hlslparser adapted to our needs in The Witness. We currently use it to translate pseudo-HLSL shaders (usin

null 3 Jul 2, 2022
HLSL Parser and Translator for HLSL, GLSL, and MSL.

HLSLParser This is a fork of Unknownworld's hlslparser adapted to our needs in The Witness. We currently use it to translate pseudo-HLSL shaders (usin

null 315 Dec 25, 2022
glslcc: Cross-compiler for GLSL shader language (GLSL->HLSL,METAL,GLES,GLSLv3)

glslcc: Cross-compiler for GLSL shader language (GLSL->HLSL,METAL,GLES,GLSLv3) @septag glslcc is a command line tool that converts GLSL code to HLSL,

Sepehr Taghdisian 435 Dec 17, 2022
⚔️ A tool for cross compiling shaders. Convert between GLSL, HLSL, Metal Shader Language, or older versions of GLSL.

A cross compiler for shader languages. Convert between SPIR-V, GLSL / GLSL ES, HLSL, Metal Shader Language, or older versions of a given language. Cross Shader wraps glslang and SPIRV-Cross, exposing a simpler interface to transpile shaders.

Alain Galvan 207 Dec 30, 2022
SMOL-V: like Vulkan/Khronos SPIR-V, but smaller.

SMOL-V: like Vulkan/Khronos SPIR-V, but smaller. Overview SMOL-V encodes Vulkan/Khronos SPIR-V format programs into a form that is smoller, and is mor

Aras Pranckevičius 271 Dec 19, 2022
The SPIR-V Tools project provides an API and commands for processing SPIR-V modules.

SPIR-V Tools Overview The SPIR-V Tools project provides an API and commands for processing SPIR-V modules. The project includes an assembler, binary m

The Khronos Group 827 Jan 6, 2023
Minify and obfuscate GLSL or HLSL code

Shader Minifier Shader Minifier is a tool that minifies and obfuscates shader code (GLSL and HLSL). Its original use-case is for the demoscene, for op

Laurent Le Brun 251 Jan 2, 2023
Shader cross compiler to translate HLSL (Shader Model 4 and 5) to GLSL

XShaderCompiler ("Cross Shader Compiler") Features Cross compiles HLSL shader code (Shader Model 4 and 5) into GLSL Simple to integrate into other pro

Lukas Hermanns 345 Dec 9, 2022
HLSL to GLSL language translator based on ATI's HLSL2GLSL. Used in Unity.

HLSL to GLSL shader language translator ⚠️ As of mid-2016, the project is unlikely to have any significant developments. At Unity we are moving to a d

Aras Pranckevičius 522 Dec 18, 2022
GLSL optimizer based on Mesa's GLSL compiler. Used to be used in Unity for mobile shader optimization.

GLSL optimizer ⚠️ As of mid-2016, the project is unlikely to have any significant developments. At Unity we are moving to a different shader compilati

Aras Pranckevičius 1.6k Jan 3, 2023
C++ front-end package manager for embedding and redistributing with native applications

Pacm Simple C++ package manager Homepage: https://sourcey.com/pacm Documentation: https://sourcey.com/libsourcey/api-pacm/ Dependencies: LibSourcey (b

Sourcey 84 Jun 5, 2022
Projeto pessoal: Obter a temperatura ambiente e através de um termistor ligado a um arduino e disponibilizar esses dados em tempo real via API NodeJS. No front-end os dados são acessados por uma interface em React JS.

INTEGRAÇÃO DA API COM OS DADOS DO ARDUINO FORNECIDOS PELO TERMISTOR Código Desenvolvido por Lucas Muffato. MATERIAIS 1 Placa de Arduino; 1 Cabo de con

Lucas Muffato 35 Aug 16, 2022
Windows 11 Drag & Drop to the Taskbar (Partial Fix)

Windows 11 Drag & Drop to the Taskbar (Partial Fix) This program partially fixes the missing "Drag & Drop to the Taskbar" support in Windows 11. In th

null 1.3k Dec 29, 2022
SPIRV-Cross is a tool designed for parsing and converting SPIR-V to other shader languages.

SPIRV-Cross SPIRV-Cross is a tool designed for parsing and converting SPIR-V to other shader languages. Features Convert SPIR-V to readable, usable an

The Khronos Group 1.6k Jan 2, 2023
yariv.h is a single C/C++ header to encode and decode SPIR-V shaders into a more compressed form I've called YARI-V.

YARI-V yariv.h is a single C/C++ header to encode and decode SPIR-V shaders into a more compressed form I've called YARI-V. YARI-V is an alternative e

Neil Henning 31 Dec 8, 2022
This repository contains machine-readable files for the SPIR-V Registry

SPIR-V Headers This repository contains machine-readable files for the SPIR-V Registry. This includes: Header files for various languages. JSON files

The Khronos Group 201 Jan 6, 2023
『HLSL シェーダーの魔導書』（ISBN978-4-7981-6428-1）のサンプルファイル

# サンプルデータについて 本データは、『HLSL シェーダーの魔導書』（清原 隆行 著、翔泳社 刊）の付属データです。 なお、本データは以下のサイトから入手可能です。 - Github：https://github.com/shoeisha-books/hlsl-grimoire-sampl

SEBook 翔泳社の本 102 Dec 15, 2022
A Visual Studio extension that provides enhanced support for editing High Level Shading Language (HLSL) files

HLSL Tools for Visual Studio This extension is for Visual Studio 2017 / 2019. Go here for the Visual Studio Code extension. HLSL Tools is a Visual Stu

Tim Jones 433 Dec 27, 2022
ShaderConductor is a tool designed for cross-compiling HLSL to other shading languages

ShaderConductor ShaderConductor is a tool designed for cross-compiling HLSL to other shading languages. Features Converts HLSL to readable, usable and

Microsoft 1.5k Dec 29, 2022