Git Product home page Git Product logo

shaderc's Introduction

Shaderc

A collection of tools, libraries and tests for shader compilation. At the moment it includes:

  • glslc, a command line compiler for GLSL/HLSL to SPIR-V, and
  • libshaderc, a library API for accessing glslc functionality.

Note: The fact that that libshaderc is not named libshaderc_glslc is a quirk of history, and a known inconsistency. Changing it would require a significant amount of renaming and breaking of downstream projects, so it is being left as is.

glslc wraps around core functionality in glslang and SPIRV-Tools. glslc and its library aims to to provide:

  • a command line compiler with GCC- and Clang-like usage, for better integration with build systems
  • an API where functionality can be added without breaking existing clients
  • an API supporting standard concurrency patterns across multiple operating systems
  • increased functionality such as file #include support

Downloads

Note: These binaries are just the artifacts of the builders and have not undergone any QA, thus they should be considered unsupported.

LinuxLinux Build Status MacOSMacOS Build Status WindowsWindows Build Status

More downloads

Status

Shaderc has maintained backward compatibility for quite some time, and we don't anticipate any breaking changes. Ongoing enhancements are described in the CHANGES file.

Shaderc has been shipping in the Android NDK since version r12b. (The NDK build uses sources from https://android.googlesource.com/platform/external/shaderc/. Those repos are downstream from GitHub.) We currently require r25c.

For licensing terms, please see the LICENSE file. If interested in contributing to this project, please see CONTRIBUTING.md.

This is not an official Google product (experimental or otherwise), it is just code that happens to be owned by Google. That may change if Shaderc gains contributions from others. See the CONTRIBUTING.md file for more information. See also the AUTHORS and CONTRIBUTORS files.

File organization

  • android_test/ : a small Android application to verify compilation
  • cmake/: CMake utility functions and configuration for Shaderc
  • examples/: Example programs
  • glslc/: an executable to compile GLSL to SPIR-V
  • libshaderc/: a library for compiling shader strings into SPIR-V
  • libshaderc_util/: a utility library used by multiple shaderc components
  • third_party/: third party open source packages; see below
  • utils/: utility scripts for Shaderc

Shaderc depends on glslang, the Khronos reference compiler for GLSL.

Shaderc depends on SPIRV-Tools for assembling, disassembling, and transforming SPIR-V binaries.

For testing, Shaderc depends on:

Library URL Description
Googletest https://github.com/google/googletest Testing framework
Effcee https://github.com/google/effcee Stateful pattern matcher inspired by LLVM's FileCheck
RE2 https://github.com/google/re2 Regular expression matcher
Abseil https://github.com/abseil/abseil-cpp Common basic utilities in C++

In the following sections, $SOURCE_DIR is the directory you intend to clone Shaderc into.

Getting and building Shaderc

If you only want prebuilt executables or libraries, see the Downloads section.

The rest of this section describes how to build Shaderc from sources.

Note: Shaderc assumes Glslang supports HLSL compilation. The instructions below assume you're building Glslang from sources, and in a subtree of shaderc/third_party. In that scenario, Glslang's HLSL support is automatically enabled. Shaderc also can be built using a Glslang from outside the shaderc/third_party tree. In that case you must ensure that that external Glslang is built with HLSL functionality. See Glslang's ENABLE_HLSL CMake setting.)

  1. Check out the source code:
git clone https://github.com/google/shaderc $SOURCE_DIR
cd $SOURCE_DIR
./utils/git-sync-deps

Note: The known-good branch of the repository contains a known_good.json file describing a set of repo URLs and specific commits that have been tested together. This information is updated periodically, and typically matches the latest update of these sources in the development branch of the Android NDK. The known-good branch also contains a update_shaderc.py script that will read the JSON file and checkout those specific commits for you.

  1. Ensure you have the requisite tools -- see the tools subsection below.

  2. Decide where to place the build output. In the following steps, we'll call it $BUILD_DIR. Any new directory should work. We recommend building outside the source tree, but it is also common to build in a (new) subdirectory of $SOURCE_DIR, such as $SOURCE_DIR/build.

4a) Build (and test) with Ninja on Linux or Windows:

cd $BUILD_DIR
cmake -GNinja -DCMAKE_BUILD_TYPE={Debug|Release|RelWithDebInfo} $SOURCE_DIR
ninja
ctest # optional

4b) Or build (and test) with MSVC on Windows:

cd $BUILD_DIR
cmake $SOURCE_DIR
cmake --build . --config {Release|Debug|MinSizeRel|RelWithDebInfo}
ctest -C {Release|Debug|MinSizeRel|RelWithDebInfo}

4c) Or build with MinGW on Linux for Windows:

cd $BUILD_DIR
cmake -GNinja -DCMAKE_BUILD_TYPE={Debug|Release|RelWithDebInfo} $SOURCE_DIR \
   -DCMAKE_TOOLCHAIN_FILE=$SOURCE_DIR/cmake/linux-mingw-toolchain.cmake
ninja

After a successful build, you should have a glslc executable somewhere under the $BUILD_DIR/glslc/ directory, as well as a libshaderc library somewhere under the $BUILD_DIR/libshaderc/ directory.

The default behavior on MSVC is to link with the static CRT. If you would like to change this behavior -DSHADERC_ENABLE_SHARED_CRT may be passed on the cmake configure line.

See the libshaderc README for more on using the library API in your project.

Tools you'll need

For building, testing, and profiling Shaderc, the following tools should be installed regardless of your OS:

  • A C++17 compiler. Recent versions of Clang, GCC, and MSVC work.
  • CMake 3.14 or later: for generating compilation targets.
    • Shaderc is tested with cmake 3.17.2
  • Python 3: for utility scripts and running the test suite.

On Linux, if cross compiling to Windows:

  • mingw: A GCC-based cross compiler targeting Windows so that generated executables use the Microsoft C runtime libraries. The MinGW compiler must support C++17.

On Windows, the following tools should be installed and available on your path:

  • Visual Studio 2017 or later. Previous versions of Visual Studio may work but are untested and unsupported.
  • Git - including the associated tools, Bash, diff.

Optionally, the following tools may be installed on any OS:

Building and running Shaderc using Docker

Please make sure you have the Docker engine installed on your machine.

To create a Docker image containing Shaderc command line tools, issue the following command in ${SOURCE_DIR}: docker build -t <IMAGE-NAME> .. The created image will have all the command line tools installed at /usr/local internally, and a data volume mounted at /code.

Assume <IMAGE-NAME> is shaderc/shaderc from now on.

To invoke a tool from the above created image in a Docker container:

docker run shaderc/shaderc glslc --version

Alternatively, you can mount a host directory (e.g., example) containing the shaders you want to manipulate and run different kinds of tools via an interactive shell in the container:

$ docker run -i -t -v `pwd`/example:/code shaderc/shaderc
/code $ ls
test.vert
/code $ glslc -c -o - test.vert | spirv-dis

Bug tracking

We track bugs using GitHub -- click on the "Issues" button on the project's GitHub page.

Bindings

Bindings are maintained by third parties, may contain content offered under a different license, and may reference or contain older versions of Shaderc and its dependencies.

shaderc's People

Contributors

antiagainst avatar awoloszyn avatar ben-clayton avatar chaocnv avatar dgkoch avatar digit-google avatar dj2 avatar dneto0 avatar dnfield avatar ehsannas avatar fjhenigman avatar google-shaderc-autoroll avatar hujiajie avatar jiawei-shao avatar kainino0x avatar kangz avatar keenuts avatar mark-grimes avatar mgadams avatar nicebyte avatar pmistrynv avatar qining avatar quaresmajose avatar realitix avatar rob2309 avatar rofrol avatar s-perron avatar sarahm0 avatar sudonatalie avatar zoddicus avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

shaderc's Issues

New file structure breaks Vulkan API Samples build

Error:error: 'C:/Users/Jack/AppData/Local/Android/sdk/ndk-bundle/sources/third_party/shaderc/libs/gnustl_static/x86/libshaderc.a', needed by '../../../../build/intermediates/cmake/debug/obj/x86/libvulkan_sample.so', missing and no known rule to make it

Intel HD Graphics does not support "#line" directive

I getting error with "GOOGLE" extensions and "#line" directives in Intel HD Graphics. Nvidia just warnings with this extensions, but parse "#line" directive. AMD not tested, I have no this GPU. Compiled with "-E" flag. How to disable these directives and bake code?

Compiling without linking (and linking afterwards)

Hello,

I'm trying to use glslc to check each of my files for errors before joining them in a single file and compiling them all together. However, the -c flag doesn't seem to work as expected. The manual specifies that the -c flag only does preprocessing and compiling, and not linking. However, if I try to compile the following code with the -std=450 -fshader-stage=compute -c flags:

int sum(int a, int b) {
  return a + b;
}

I get the following error:

sum.glsl: error: Linking compute stage: Missing entry point: Each stage requires one entry point

This clearly means that glslc is trying to link the source into a binary. How can I only preprocess and compile the GLSL shader, and not link it into a final binary?

Debug build suffix

Since installing is enabled, it would help to differentiate debug binaries from optimized ones, so that they can coexist. E.g. a "d" suffix for debug binaries. Very useful in windows builds.

Problems with atomics - can't change resource limits

Hello. My Nvidia GTX 970 supports multiple atomic counter, but compiler thinks another.

C:\Users\acterhd\Documents\GitHub\ogl-reflections\src\shaders\voxelizer>call glslc --target-env=opengl_compat -DSPIRV_EDITION unlocker.comp -o unlocker.comp.spv
unlocker.comp:22: error: 'binding' : atomic_uint binding is too large; see gl_MaxAtomicCounterBindings
1 error generated.

Full source can be found in my project.
https://github.com/acterhd/ogl-reflections/blob/master/src/shaders/voxelizer/unlocker.comp

Use libshaderc to assemble SPIR-V assembly into binary

Currently, I only see a way to have GLSL source code and produce either preprocessed GLSL source, SPIR-V assembly or SPIR-V binary from it.
Is there a way to produce SPIR-V binary when having the SPIR-V assembly text?
Or do I have to just use SPIRV-Tools directly for that?

Vulkan conformance test gets access violation in spvValidate

Specifics
Windows 7, Nvidia GTX 660 Ti, Driver 368.39

Have Vulkan SDK 1.0.21 installed for validation layers and set environment variable VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_standard_validation

To reproduce I run all of the dEQP-VK.glsl.functions.control_flow.* tests from the Vulkan Conformance Test Suite

Message:
Exception thrown: read access violation.
this was nullptr. (debugger confirms that variable "this" is NULL)

Location:
BasicBlock.h:

76 /// Returns true if the block is reachable in the CFG
77 bool reachable() const { return reachable_; }

Call Stack:
`
VkLayer_core_validation.dll!libspirv::BasicBlock::reachable() Line 77 C++

VkLayer_core_validation.dll!libspirv::StructuredControlFlowChecks(const libspirv::ValidationState_t & _, const libspirv::Function & function, const std::vector<std::pair<unsigned int,unsigned int>,std::allocator<std::pair<unsigned int,unsigned int> > > & back_edges) Line 349 C++

VkLayer_core_validation.dll!libspirv::PerformCfgChecks(libspirv::ValidationState_t & _) Line 478    C++

VkLayer_core_validation.dll!spvValidate(const spv_context_t * const context, spv_const_binary_t * const binary, spv_diagnostic_t * * pDiagnostic) Line 209  C++

VkLayer_core_validation.dll!core_validation::CreateShaderModule(VkDevice_T * device, const VkShaderModuleCreateInfo * pCreateInfo, const VkAllocationCallbacks * pAllocator, VkShaderModule_T * * pShaderModule) Line 9069  C++

VkLayer_object_tracker.dll!object_tracker::CreateShaderModule(VkDevice_T * device, const VkShaderModuleCreateInfo * pCreateInfo, const VkAllocationCallbacks * pAllocator, VkShaderModule_T * * pShaderModule) Line 3583    C++

VkLayer_parameter_validation.dll!parameter_validation::CreateShaderModule(VkDevice_T * device, const VkShaderModuleCreateInfo * pCreateInfo, const VkAllocationCallbacks * pAllocator, VkShaderModule_T * * pShaderModule) Line 2621    C++

VkLayer_threading.dll!threading::CreateShaderModule(VkDevice_T * device, const VkShaderModuleCreateInfo * pCreateInfo, const VkAllocationCallbacks * pAllocator, VkShaderModule_T * * pShaderModule) Line 1133  C++

deqp-vk.exe!vk::DeviceDriver::createShaderModule(vk::VkDevice_s * device, const vk::VkShaderModuleCreateInfo * pCreateInfo, const vk::VkAllocationCallbacks * pAllocator, vk::Handle<14> * pShaderModule) Line 218  C++

deqp-vk.exe!vk::createShaderModule(const vk::DeviceInterface & vk, vk::VkDevice_s * device, const vk::VkShaderModuleCreateInfo * pCreateInfo, const vk::VkAllocationCallbacks * pAllocator) Line 209    C++

deqp-vk.exe!vk::createShaderModule(const vk::DeviceInterface & deviceInterface, vk::VkDevice_s * device, const vk::ProgramBinary & binary, unsigned int flags) Line 206 C++
deqp-vk.exe!vkt::`anonymous namespace'::PipelineProgram::PipelineProgram(vkt::Context & context, const glu::sl::ShaderCaseSpecification & spec) Line 745    C++

deqp-vk.exe!vkt::`anonymous namespace'::ShaderCaseInstance::ShaderCaseInstance(vkt::Context & context, const glu::sl::ShaderCaseSpecification & spec) Line 1410 C++

deqp-vk.exe!vkt::`anonymous namespace'::ShaderCase::createInstance(vkt::Context & context) Line 1791    C++

deqp-vk.exe!vkt::TestCaseExecutor::init(tcu::TestCase * testCase, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & casePath) Line 246   C++

deqp-vk.exe!tcu::TestSessionExecutor::enterTestCase(tcu::TestCase * testCase, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & casePath) Line 181   C++

deqp-vk.exe!tcu::TestSessionExecutor::iterate() Line 101    C++

deqp-vk.exe!tcu::App::iterate() Line 172    C++

deqp-vk.exe!main(int argc, const char * * argv) Line 55 C++
[External Code] 

`

Bisected to spirv-tools commit: f61db0bcc6717b4b60a7e38e7c3c58ad02110aa8
Validator structured flow checks: back-edge, constructs

Tighten irregularities re: working directory and file search

If I have files:
subdir/a.vert
And I run:
glslc -c -working-directory subdir -o pwd/a.spv a.vert
Then when I run the following from /build/dir/ I get:
glslc: error: cannot open output file: 'subdir//build/dir/a.spv': No such file or directory

PR #115 goes partway to fixing that but is confusing and looks like it has bugs.

The current description of output file placement has some missing cases and can be confusing.
This is a proposal at making it more regular. This is intended as comment to go above FileCompiler::GetOutputFileName in glslsc/src/file_compiler.h
It's text should also be used as the basis for an update to glslc/README.asciidoc

// Let "target directory" be the user-specified working directory, if
// provided, and the current working directory otherwise.
// Let "result extension" be ".spv" when generating a SPIR-V binary, and
// ".s" when generating SPIR-V assembly text.
// Let "resolved input filename" be the input filename if it's absolute,
// or the input filename appended to the target directory otherwise.
//
// If the user specified an output filename, then:
// If the specified output filename is an absolute path, then return that.
// Otherwise, return the specified output filename relative to the target
// directory.
// If the user did not specify an output filename, then:
// If linking is performed, return "a.spv" relative to the target
// directory.
// Otherwise, derive the output filename from the input filename as follows:
// If the input filename has a standard stage extension (e.g. .vert)
// then return the resolved input filename but add the result extension.
// Otherwise, return the resolved input filename but where its extension
// is replaced with the result extension. (If the resolved input filename
// does not have an extension, then append the result extension.)

This is very similar to Clang's behavior with -working-directory.
There's a small difference in that Clang behaves unexepctedly when both -o and -working-directory are
used with a relative path for -o.
For example, if I've got
subdir/x.c
subdir/subsubdir/
And I go:
clang -c -working-directory subdir x.c -o subsubdir/x.o
Then I get an error because the Clang driver is trying to make subsubdir/x.o without prepending the -working-directory subdir argument.

I found very few tests in Clang for -working-directory so I'll choose to interpret this irregularity as a missed case in Clang's implementation.

#include issue

Hello,
I am using libshaderc to compile glsl ot Spir-V for Vulkan.
I want to use the #include preprocessor but I got an error during compilation.

Here the glsl:

  #version 450
  #extension GL_ARB_separate_shader_objects : enable
  
  #include "path/test.glsl"
 
  layout(location = 0) in vec2 i_position;
  layout(location = 1) in vec2 i_textureCoordinates;
  layout(location = 2) in vec4 i_color;
  
  layout(location = 0) out vec4 o_color;
  layout(location = 1) out vec2 o_textureCoordinates;
  
  layout(set = 0, binding = 0) uniform Uniform {
      mat4 u_combinedMatrix;
  };
  
  out gl_PerVertex {
      vec4 gl_Position;
  };
  
  
  void main() {
      o_color = i_color;
      o_textureCoordinates = i_textureCoordinates;
      gl_Position = u_combinedMatrix * vec4(i_position, 0., 1.);
  }

I got the following error:

spritebatch.vs.glsl:4: error: '#include' : #error u [ for header name: path/test.glsl

Like you can see, there is an error in the output, it's not proper ASCCI or UTF-8, there are strange characters u [ .

Is this a known error, maybe I misuse the library.

Thanks.

shaderc_compile_into_spv_assembly doesn't disassemble `TimeAMD` properly

The following snippet compiles just fine with shaderc_compile_into_spv, but doesn't compile properly with shaderc_compile_into_spv_assembly.

It fails with this internal error:

shaderc: internal error: compilation succeeded but failed to disassemble: 23: Invalid extended instruction import 'SPV_AMD_gcn_shader'

#version 450

#extension GL_ARB_separate_shader_objects : enable
#extension GL_ARB_shading_language_420pack : enable
#extension GL_ARB_gpu_shader_int64 : enable
#extension GL_AMD_gcn_shader : enable

void main() 
{
	uint64_t v = timeAMD();
}

Looks like some minor support for it is still missing.

third_party/Android.mk enhancement: Build all components with with -Werror

All subcomponents should build with -Werror even using latest NDK.
Currently NDK r14-beta1 canary builds have some warnings.

Example:

../third_party/glslang/hlsl/hlslParseHelper.h:137:10: warning: 'finalizeGlobalUniformBlockLayout' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
../third_party/glslang/hlsl/hlslParseHelper.h:53:10: warning: 'initializeExtensionBehavior' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
../third_party/glslang/hlsl/hlslParseHelper.h:55:10: warning: 'setLimits' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
../third_party/glslang/hlsl/hlslParseHelper.h:56:10: warning: 'parseShaderStrings' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
../third_party/glslang/hlsl/hlslParseHelper.h:57:25: warning: 'getGlobalUniformBlockName' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
../third_party/glslang/hlsl/hlslParseHelper.h:59:10: warning: 'reservedPpErrorCheck' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
../third_party/glslang/hlsl/hlslParseHelper.h:60:10: warning: 'lineContinuationCheck' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
../third_party/glslang/hlsl/hlslParseHelper.h:61:10: warning: 'lineDirectiveShouldSetNextLine' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
../third_party/glslang/hlsl/hlslParseHelper.h:64:10: warning: 'handlePragma' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]

HLSL descriptor mapping doc ?

glslc is able to build hlsl shader but it's not obvious how to describe descriptor layout. I'm not sure if it's possible to embed a root signature and how it maps to vulkan layouts.

Opengl bindless support for SPIR-V

We preparing to support SPIR-V, but I want ask question. Will shaderc and SPV support bindless texture? When I tried to compile, I got errors that extension not support.

Shaderc C++ compilation API should accept entry point name.

You need to name the entry point. glslangValidator has a -e option for this.
Glslang performs shader linking on HLSL compiles, but does not check if there is an entry point defined. It then generates an invalid SPIR-V module in that case.

We need a few fixes:

  1. The C compilation API already has an entry-point parameter, but doesn't pass it into Glslang. It should now be passed into the TShader object in Glslang. This will only take effect for HLSL, since Glslang forces an entry point name of "main" for GLSL.
  2. The Shaderc C++ API should have methods where the caller supplies the entry point name. It should be passed down into the C API.
  3. In glslc, the default name for the entry point should be "main". Glslc should support an -fentry-point= option which applies to subsequent compilation units.

Archive architecture linking problem

So I build according to the README (cmake -GNinja -DCMAKE_BUILD_TYPE=Release ../)

and then as I need to use option 3 in shaderc/libshaderc's README I link in libshaderc_combined.a and include libshaderc/include, all on the same computer (and ergo same architecture)

But when I try to compile my code I get this warning:

ld: warning: ignoring file libshaderc/libshaderc_combined.a, file was built for archive which is not the architecture being linked (x86_64): libshaderc/libshaderc_combined.a

and when I run lipo -info on libshaderc_combined.a I get:

fatal error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: archive with no architecture specification: libshaderc/libshaderc_combined.a (can't determine architecture for it)

But even when I had converted the libshaderc_combined so lipo recognized it as x86_64 I was getting the same warning.

And because of the warning when I run my code I get:

dyld: lazy symbol binding failed: Symbol not found: _shaderc_compiler_initialize
Referenced from: shader
Expected in: flat namespace

Any ideas?

shaderc creates output file anyway on failure

Expected behaviour:
If compilation fails because of an error, the output file is not touched.

Actual behviour:
Upon failure, an empty output file is created anyway.

This breaks make-based build systems: make assumes that no recompilation is necessary because the output file is newer than the input file.

glslc writes bad dependency file if `-o -`

If glslc is given option '-o -' and one of the -M* dependency
options, then it wrote an incorrect dependency file. For example:

$ glslc -MD -S -o - a.glsl | sed ...
$ ls
-.d a.glsl
$ cat ./-.d
-: a.glsl

It doesn't make sense to write a dependency file when the compilation
output is stdout. So glslc should catch this error when parsing the command line flags.j

Build fail [88/99] ar -M

While trying to compile on MacOS it works fine at first but stopped near the end, during linking:

****-macbookpro:build ****$ ninja
[35/99] Building CXX object third_party/glslang/SPIRV/CMakeFiles/SPIRV.dir/GlslangToSpv.cpp.o
../third_party/glslang/SPIRV/GlslangToSpv.cpp:1561:33: warning: comparison of constant 4294967295 with expression of type 'spv::BuiltIn' is always true [-Wtautological-constant-out-of-range-compare]
                    if (builtIn != spv::BadValue)
                        ~~~~~~~ ^  ~~~~~~~~~~~~~
../third_party/glslang/SPIRV/GlslangToSpv.cpp:3023:17: warning: comparison of constant 4294967295 with expression of type 'spv::BuiltIn' is always true [-Wtautological-constant-out-of-range-compare]
    if (builtIn != spv::BadValue)
        ~~~~~~~ ^  ~~~~~~~~~~~~~
../third_party/glslang/SPIRV/GlslangToSpv.cpp:3032:13: warning: comparison of constant 4294967295 with expression of type 'spv::Decoration' is always true [-Wtautological-constant-out-of-range-compare]
    if (dec != spv::BadValue)
        ~~~ ^  ~~~~~~~~~~~~~
../third_party/glslang/SPIRV/GlslangToSpv.cpp:3039:13: warning: comparison of constant 4294967295 with expression of type 'spv::Decoration' is always true [-Wtautological-constant-out-of-range-compare]
    if (dec != spv::BadValue)
        ~~~ ^  ~~~~~~~~~~~~~
../third_party/glslang/SPIRV/GlslangToSpv.cpp:3046:13: warning: comparison of constant 4294967295 with expression of type 'spv::Decoration' is always true [-Wtautological-constant-out-of-range-compare]
    if (dec != spv::BadValue)
        ~~~ ^  ~~~~~~~~~~~~~
5 warnings generated.
[88/99] Generating libshaderc_combined.a
FAILED: cd /Users/****/Documents/dev/vulkan/sharder_compiler/shaderc/build/libshaderc && /bin/echo -e create\ libshaderc_combined.a\\naddlib\ /Users/****/Documents/dev/vulkan/sharder_compiler/shaderc/build/libshaderc/libshaderc.a\\naddlib\ /Users/****/Documents/dev/vulkan/sharder_compiler/shaderc/build/third_party/glslang/SPIRV/libSPIRV.a\\naddlib\ /Users/****/Documents/dev/vulkan/sharder_compiler/shaderc/build/libshaderc_util/libshaderc_util.a\\naddlib\ /Users/****/Documents/dev/vulkan/sharder_compiler/shaderc/build/third_party/glslang/glslang/libglslang.a\\naddlib\ /Users/****/Documents/dev/vulkan/sharder_compiler/shaderc/build/third_party/glslang/OGLCompilersDLL/libOGLCompiler.a\\naddlib\ /Users/****/Documents/dev/vulkan/sharder_compiler/shaderc/build/third_party/glslang/glslang/OSDependent/Unix/libOSDependent.a\\nsave\\nend | /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar -M
usage:  ar -d [-TLsv] archive file ...
    ar -m [-TLsv] archive file ...
    ar -m [-abiTLsv] position archive file ...
    ar -p [-TLsv] archive [file ...]
    ar -q [-cTLsv] archive file ...
    ar -r [-cuTLsv] archive file ...
    ar -r [-abciuTLsv] position archive file ...
    ar -t [-TLsv] archive [file ...]
    ar -x [-ouTLsv] archive [file ...]
[88/99] Building CXX object libshaderc/CMakeFiles/shaderc_shaderc_cpp_test.dir/src/shaderc_cpp_test.cc.o
ninja: build stopped: subcommand failed.
****-macbookpro:build ****$ 

I haven't found a work around yet (And I've never used ninja ...)

shaderc_compile_into_spv cannot handle NULL input_file_name argument

I think the input_file_name should only really be used when trying to deduce the shader kind from the file name. But when the shader kind is given as explicit argument, then the file name should not need to be given as well.
Currently, when calling shaderc_compile_into_spv with a NULL input_file_name argument, it crashes the process.
Where is not having a file name useful?
When using the shaderc_compile_into_spv with runtime-generated sources.

PYTHON_EXE-NOTFOUND when python is in PATH

OS: Windows 7 x64
Compiler: MSVC 14 "2015" x64
CMake: 3.5.0-rc3
Python: 2.7.11

There seem to be currently two different CMake properties/defines for where the Python exe is located.
My generated CMakeCache.txt looks like this:

//Path to a program.
PYTHON_EXE:FILEPATH=PYTHON_EXE-NOTFOUND

//Path to a program.
PYTHON_EXECUTABLE:FILEPATH=C:/Programme/Python27/python.exe

The CMake -G "Visual Studio 14 2015 Win64" runs successfully and also finds Python.
It seems that the vcxproj files only use the above property PYTHON_EXE:FILEPATH when they should've used the other one.

This causes the build to fail.
When I patch the above property in all vcxproj files to use the found python path, the whole build works and everything is fine.

ndk build for opcode.inc has cross-ABI dependency

From @AWoloszyn comment on #188

"""
I'm willing to let this go, but it does create a fairly strange build dependency, because now for the arm64 build depends on the x86 opcode.inc file.

The only thing I can thing that would solve this is as part of your build do something like copy $(SPVTOOLS_LOCAL_PATH)/source/opcode.cpp -&gt; $(1)/opcode.cpp and change your build to use that opcode.cpp instead of $(SPVTOOLS_LOCAL_PATH)/source/opcode.cpp.

Then arm64 would only depend on arm64 stuff. However that is very complicated, and I don't think will actually make any difference in practice.
"""

Publish Blaze/Bazel build files

Since this is a Google project I am somewhat sure that internally, you have BUILD files for building all this. Please make them available to the public.

Build fails when using make with multiple jobs

Configuring CMake with -G"Unix Makefiles" and then make V=1 -j$(nproc). Fails with the following message:

*** No rule to make target `libshaderc/libshaderc.a', needed by `libshaderc/libshaderc_combined.a'.  Stop.

Support for compiling to C/C++ header

For many applications, it would be very convenient to be able to compile GLSL directly to a SPIR-V encoded as a static const uint32_t[].

In smaller projects, and especially for embedded/mobile, it is very useful to bake the SPIR-V shaders directly into the binary.

CompilationResult begin end

I run into a problem feeding a CompilationResult<uint32_t> (acquired from shaderc::Compiler::CompileGlslToSpv) to vk::Device::createShaderModule (through vk::ShaderModuleCreateInfo). The size of the code was computed as the distance between begin and end. This distance needed to be multiplied by 4 (sizeof(uint32_t)) to correctly compute code size. This is a bit confusing if not incorrect.

CMake Warning (dev) at cmake/utils.cmake:110 (get_target_property)

When configuring on Mac with bootstrapped-from-source cmake, I get this:

-- Found Google Mock, building tests.
CMake Warning (dev) at cmake/utils.cmake:110 (get_target_property):
Policy CMP0026 is not set: Disallow use of the LOCATION target property.
Run "cmake --help-policy CMP0026" for policy details. Use the cmake_policy
command to set the policy and suppress this warning.

The LOCATION property should not be read from target "glslang". Use the
target name directly with add_custom_command, or use the generator
expression $<TARGET_FILE>, as appropriate.

Call Stack (most recent call first):
cmake/utils.cmake:105 (get_transitive_libs)
cmake/utils.cmake:127 (get_transitive_libs)
libshaderc/CMakeLists.txt:30 (combine_static_lib)
This warning is for project developers. Use -Wno-dev to suppress it.

glslc fshader-stage evaluated before preprocessor macros

I've currently been using macros with preprocessor conditionals around the shader entry points to combine multiple stages into a single glsl file. eg:

#if VERTEX_SHADER
void main() {...}
#endif
#if FRAGMENT_SHADER
void main() {...}
#endif

Using -D and -fshader-stage arguments, I always trigger the error:
.glsl file encountered but no -fshader-stage specified ahead

My current workaround has been to run glslc with -E to a intermediate file first, then process the preprocessed code with -c without any problems.

shaderc::SpvModule should be renamed to shaderc::CompilationResult

The class is the result produced from compilation: status information plus the actual bits generated by the compiler. Those bits are usually a SPIR-V module. However, it can be something else, e.g. when doing the equivalent of -E (preprocess-only) or -M (target dependencies).

This change would go along with the (in-flight) rename of shaderc_spv_module to shaderc_compilation_result
#126

Linux/cmake build error: libshaderc_combined.a missing and no known rule to create it

I'm trying to integrate shaderc into an external project using CMake. In my project's CMakeLists.txt, I have add_subdirectory(third_party/shaderc) to pull in the shaderc tree, and target_link_libraries(my_project_exe shaderc) to add it as a link dependency. This works fine on Windows, but when building on Linux I get an error at build time:
error: '../third_party/shaderc/libshaderc/libshaderc_combined.a', needed by 'third_party/shaderc/libshaderc/CMakeFiles/shaderc_combined_genfile', missing and no known rule to make it
Am I missing a step?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.