google / shaderc Goto Github PK
View Code? Open in Web Editor NEWA collection of tools, libraries, and tests for Vulkan shader compilation.
License: Other
A collection of tools, libraries, and tests for Vulkan shader compilation.
License: Other
is there intention to create official dll support for shaderc?
the header could get a prefix similar to how GLFW for example handles dll import/export
https://github.com/glfw/glfw/blob/master/include/GLFW/glfw3.h#L182
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.
Use LOCAL_CPPFLAGS instead of LOCAL_CXXFLAGS.
LOCAL_CPPFLAGS is newer and recommended.
The blurb for this function promises that name/value can be modified or deleted after it returns. But that's currently not true: the underlying implementation merely keeps pointers to name/value. The function should obey its contract.
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?
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 still expects google test to be downloaded.
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.
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
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.
"""
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.
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?
glslang has two command-line options to generate SPIR-V:
-V
: under Vulkan semantics-G
: under OpenGL semanticsshaderc should also support some kind of command-line option to select the mode.
Also, the glslc test framework doesn't distinguish intentional failure from failure-by-crash (signal).
Issue was found by [email protected]
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.
I may be missing something, but it's not clear to me how to construct a shaderc_includer_response when the path is incorrect or content-reading fails.
This is a bug in the CMakeLists.txt files.
This causes the build to fail on Windows. Instead of running add_copyright.py, it just opens up an editor (e.g. developer studio) to edit that script.
If input shader does not end with newline, glslc.exe will hang.
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.
There should be a way for glslc to output what optimization passes are performed for a given optimization level.
Refer to -###
in clang.
For the command line, use similar conventions as GCC and Clang.
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.
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.
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
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
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.
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.
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?
Should just be adding tests
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?
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_module_get_success only exists in header
It currently only admits "Copyright 2015". It should allow any year.
It almost certainly implies linking to SPIRV-Tools itself.
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.
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.
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.
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?
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
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
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.
For example, GCC 4.8.1 throws an internal error
See
#83
In particular, what versions of GCC, Clang, and MSVC are supposed to work?
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.
For example, Shaderc defaults .maxDrawBuffers to 2, but Vulkan has maxColorAttachments minimum requirement of 4. (First check that they mean the same thing.)
I think including ShaderC in every project that is to be built against it is suboptimal. Since cmake install is an option, one could use this mechanism to enable automatic finding of build and installed shaderc. See "Exporting targets" in https://cmake.org/Wiki/CMake/Tutorials/Exporting_and_Importing_Targets.
Hello. I have problems with Nvidia. How to disable output of "GL_GOOGLE_include_directive" codes in productive shaders?
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]
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:
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.