This repository contains machine-readable files for the SPIR-V Registry

Overview

SPIR-V Headers

This repository contains machine-readable files for the SPIR-V Registry. This includes:

  • Header files for various languages.
  • JSON files describing the grammar for the SPIR-V core instruction set and the extended instruction sets.
  • The XML registry file.
  • A tool to build the headers from the JSON grammar.

Headers are provided in the include directory, with up-to-date headers in the unified1 subdirectory. Older headers are provided according to their version.

In contrast, the XML registry file has a linear history, so it is not tied to SPIR-V specification versions.

How is this repository updated?

When a new version or revision of the SPIR-V specification is published, the SPIR-V Working Group will push new commits onto master, updating the files under include.

The SPIR-V XML registry file is updated by Khronos whenever a new enum range is allocated.

Pull requests can be made to

  • request allocation of new enum ranges in the XML registry file
  • register a new magic number for a SPIR-V generator
  • reserve specific tokens in the JSON grammar

Registering a SPIR-V Generator Magic Number

Tools that generate SPIR-V should use a magic number in the SPIR-V to help identify the generator.

Care should be taken to follow existing precedent in populating the details of reserved tokens. This includes:

  • keeping generator numbers in numeric order
  • filling out all the existing fields

Reserving tokens in the JSON grammar

Care should be taken to follow existing precedent in populating the details of reserved tokens. This includes:

  • pointing to what extension has more information, when possible
  • keeping enumerants in numeric order
  • when there are aliases, listing the preferred spelling first
  • adding the statement "version" : "None"

How to install the headers

mkdir build
cd build
cmake ..
cmake --build . --target install

Then, for example, you will have /usr/local/include/spirv/unified1/spirv.h

If you want to install them somewhere else, then use -DCMAKE_INSTALL_PREFIX=/other/path on the first cmake command.

Using the headers without installing

Using CMake

A CMake-based project can use the headers without installing, as follows:

  1. Add an add_subdirectory directive to include this source tree.
  2. Use ${SPIRV-Headers_SOURCE_DIR}/include} in a target_include_directories directive.
  3. In your C or C++ source code use #include directives that explicitly mention the spirv path component.
#include "spirv/unified1/GLSL.std.450.h"
#include "spirv/unified1/OpenCL.std.h"
#include "spirv/unified1/spirv.hpp"

See also the example subdirectory. But since that example is inside this repostory, it doesn't use and add_subdirectory directive.

Using Bazel

A Bazel-based project can use the headers without installing, as follows:

  1. Add SPIRV-Headers as a submodule of your project, and add a local_repository to your WORKSPACE file. For example, if you place SPIRV-Headers under external/spirv-headers, then add the following to your WORKSPACE file:
local_repository(
    name = "spirv_headers",
    path = "external/spirv-headers",
)
  1. Add one of the following to the deps attribute of your build target based on your needs:
@spirv_headers//:spirv_c_headers
@spirv_headers//:spirv_cpp_headers
@spirv_headers//:spirv_cpp11_headers

For example:

cc_library(
  name = "project",
  srcs = [
    # Path to project sources
  ],
  hdrs = [
    # Path to project headers
  ],
  deps = [
    "@spirv_tools//:spirv_c_headers",
    # Other dependencies,
  ],
)
  1. In your C or C++ source code use #include directives that explicitly mention the spirv path component.
#include "spirv/unified1/GLSL.std.450.h"
#include "spirv/unified1/OpenCL.std.h"
#include "spirv/unified1/spirv.hpp"

Generating headers from the JSON grammar for the SPIR-V core instruction set

This will generally be done by Khronos, for a change to the JSON grammar. However, the project for the tool to do this is included in this repository, and can be used to test a PR, or even to include the results in the PR. This is not required though.

The header-generation project is under the tools/buildHeaders directory. Use CMake to build and install the project, in a build subdirectory (under tools/buildHeaders). There is then a bash script at bin/makeHeaders that shows how to use the built header-generator binary to generate the headers from the JSON grammar. (Execute bin/makeHeaders from the tools/buildHeaders directory.) Here's a complete example:

cd tools/buildHeaders
mkdir build
cd build
cmake ..
cmake --build . --target install
cd ..
./bin/makeHeaders

Notes:

  • this generator is used in a broader context within Khronos to generate the specification, and that influences the languages used, for legacy reasons
  • the C++ structures built may similarly include more than strictly necessary, for the same reason

Generating C headers for extended instruction sets

The GLSL.std.450.h and OpenCL.std.h extended instruction set headers are maintained manually.

The C/C++ header for each of the other extended instruction sets is generated from the corresponding JSON grammar file. For example, the OpenCLDebugInfo100.h header is generated from the extinst.opencl.debuginfo.100.grammar.json grammar file.

To generate these C/C++ headers, first make sure python3 is in your PATH, then invoke the build script as follows:

cd tools/buildHeaders
python3 bin/makeExtinstHeaders.py

FAQ

  • How are different versions published?

    The multiple versions of the headers have been simplified into a single unified1 view. The JSON grammar has a "version" field saying what version things first showed up in.

  • How do you handle the evolution of extended instruction sets?

    Extended instruction sets evolve asynchronously from the core spec. Right now there is only a single version of both the GLSL and OpenCL headers. So we don't yet have a problematic example to resolve.

License

Copyright (c) 2015-2018 The Khronos Group Inc.

Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and/or associated documentation files (the
"Materials"), to deal in the Materials without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Materials, and to
permit persons to whom the Materials are furnished to do so, subject to
the following conditions:

The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Materials.

MODIFICATIONS TO THIS FILE MAY MEAN IT NO LONGER ACCURATELY REFLECTS
KHRONOS STANDARDS. THE UNMODIFIED, NORMATIVE VERSIONS OF KHRONOS
SPECIFICATIONS AND HEADER INFORMATION ARE LOCATED AT
   https://www.khronos.org/registry/

THE MATERIALS ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
MATERIALS OR THE USE OR OTHER DEALINGS IN THE MATERIALS.
Issues
  • Add spirv-headers pkgconfig file

    Add spirv-headers pkgconfig file

    With installed pkgconfig file other projects build processes can detest availability of the spirv-headers and require some minimum version of the spirv-headers to be present in build environment.

    There i many problems when some other packages are failing only because installed spirv-headers version is to low. Adding that file will allow to avoid that kind of situations.

    opened by kloczek 12
  • Add a function that returns whether an opcode has a result and/or result type

    Add a function that returns whether an opcode has a result and/or result type

    For code that needs to do minor inspection/validation of SPIR-V it is often useful to be able to build an id->typeid map, but there's currently no good way to know which opcodes have a result/type and which don't, and this makes it clumsy to try to build the map.

    My original motivation for this is at: https://github.com/KhronosGroup/Vulkan-ValidationLayers/pull/742/files#diff-02aa55cdf8efb86e40256744eb74b841R1949. I needed to do some validation of cooperative matrix types, but the cooperative matrix operands could be a result of a bunch of different instructions. There were few enough that it was reasonable to whitelist the instructions in this case.

    Baldur described a case where he needed to know what type of integer an OpAccessChain operand is. This would be easy to know by building an id->typeid map and only inspecting OpTypeInt and OpAccessChain instructions.

    So I think this is generally useful, and the JSON has this information encoded in it. The core SPIR-V header seems like a natural place to put this, though I can imagine somebody objecting to having utility code creep into the header.

    opened by jeffbolznv 12
  • Question: why OpSelectionMerge and OpLoopMerge are separate instructions?

    Question: why OpSelectionMerge and OpLoopMerge are separate instructions?

    If the idea behind OpSelectionMerge and OpLoopMerge is that threads should know when they should diverge and converge, why have 2 separate instructions for conditional statements and loops? The fact that there are 2 instructions gives rise to many corner case questions, questions such as "should a OpLoopMerge block have OpSelectionMerge blocks within itself or not" (SPIR-V documentation example says no, while I sometimes see SPIR-V code in the wild that says yes). I see driver programmers from a big IHV hit these corner cases and complain about it on the Internet in the year of 2019, 5 years after the release of the spec, this is not normal, there are Android phones out there with broken SPIR-V compilers because of that, and many more will come if someone won't clarify all of this in detail.

    opened by procedural 11
  • handling of kernel struct parameters

    handling of kernel struct parameters

    Note: cross-posted from https://github.com/KhronosGroup/SPIRV-LLVM/issues/151

    given the following OpenCL C code:

    typedef struct {
        int val;
    } test_struct;
    
    kernel void struct_test(global int* buf, test_struct param) {
        buf[get_global_id(0)] = param.val;
    }
    
    kernel void int_test(global int* buf, int param) {
        buf[get_global_id(0)] = param;
    }
    

    resulting in the following IR (shortened for brevity):

    %struct.test_struct = type { i32 }
    
    define spir_kernel void @struct_test(i32 addrspace(1)* %buf, %struct.test_struct* %param) nounwind {
      %1 = getelementptr inbounds %struct.test_struct* %param, i64 0, i32 0
      %2 = load i32* %1, align 4, !tbaa !12
      %3 = tail call spir_func i64 @_Z13get_global_idj(i32 0) nounwind readnone
      %4 = getelementptr inbounds i32 addrspace(1)* %buf, i64 %3
      store i32 %2, i32 addrspace(1)* %4, align 4, !tbaa !12
      ret void
    }
    
    define spir_kernel void @int_test(i32 addrspace(1)* %buf, i32 %param) nounwind {
      %1 = tail call spir_func i64 @_Z13get_global_idj(i32 0) nounwind readnone
      %2 = getelementptr inbounds i32 addrspace(1)* %buf, i64 %1
      store i32 %param, i32 addrspace(1)* %2, align 4, !tbaa !12
      ret void
    }
    

    resulting in the following SPIR-V (shortened for brevity):

                   OpEntryPoint Kernel %12 "struct_test"
                   OpEntryPoint Kernel %25 "int_test"
                   OpDecorate %5 LinkageAttributes "__spirv_BuiltInGlobalInvocationId" Import
              %2 = OpTypeInt 64 0
              %7 = OpTypeInt 32 0
             %16 = OpConstant %2 0
             %17 = OpConstant %7 0
              %3 = OpTypeVector %2 3
              %4 = OpTypePointer UniformConstant %3
              %6 = OpTypeVoid
              %8 = OpTypePointer CrossWorkgroup %7
              %9 = OpTypeStruct %7
             %10 = OpTypePointer Function %9
             %11 = OpTypeFunction %6 %8 %10
             %18 = OpTypePointer Function %7
             %24 = OpTypeFunction %6 %8 %7
              %5 = OpVariable %4 UniformConstant
             %12 = OpFunction %6 None %11
             %13 = OpFunctionParameter %8
             %14 = OpFunctionParameter %10
             %15 = OpLabel
             %19 = OpInBoundsPtrAccessChain %18 %14 %16 %17
             %20 = OpLoad %7 %19 Aligned 4
             %21 = OpLoad %3 %5 Aligned 0
             %22 = OpCompositeExtract %2 %21 0
             %23 = OpInBoundsPtrAccessChain %8 %13 %22
                   OpStore %23 %20 Aligned 4
                   OpReturn
                   OpFunctionEnd
             %25 = OpFunction %6 None %24
             %26 = OpFunctionParameter %8
             %27 = OpFunctionParameter %7
             %28 = OpLabel
             %29 = OpLoad %3 %5 Aligned 0
             %30 = OpCompositeExtract %2 %29 0
             %31 = OpInBoundsPtrAccessChain %8 %26 %30
                   OpStore %31 %27 Aligned 4
                   OpReturn
                   OpFunctionEnd
    

    Is the way kernel struct parameters are handled really the correct/intended behavior? Considering that scalar types are directly used in OpFunctionParameter/OpTypeFunction, shouldn't structs be handled the same way instead of going through an "OpTypePointer Function" indirection? Even more, doesn't this indirection say that only a pointer argument will be set/used (4 or 8 bytes), not so much a struct object (which could be any size)? I know that the issue here is that LLVM/SPIR can only handle struct parameters as pointers, but something like that isn't specified for SPIR-V.

    How to solve this?

    Option 1 (preferable): Keep it the way it is right now, but explicitly specify that kernel pointer parameters to Function/private memory actually perform some kind of allocation of the element/pointee type on the device side, and are set as this element/pointee type on the host side (not as the pointer type). Note that private address space pointer kernel arguments are otherwise invalid.

    Option 2 (impossible?): Directly use OpTypeStruct in OpFunctionParameter/OpTypeFunction. This will however require IR/SPIR-V translator changes, since OpTypeStruct is no longer a pointer type (making all GEPs/Op*AccessChain instructions using it invalid). This might be impossible to do though, since there is no way of getting a pointer to this struct then in SPIR-V (afaik).

    edit: Option 3: Require a OpVariable in OpFunctionParameter/OpTypeFunction for struct types. This way it should be clear what is actually happening + it is still a pointer.

    question 
    opened by a2flo 11
  • Add Intel specific definitions from https://github.com/KhronosGroup/S…

    Add Intel specific definitions from https://github.com/KhronosGroup/S…

    …PIRV-LLVM-Translator

    List of extensions: SPV_INTEL_fpga_memory_attributes https://github.com/KhronosGroup/SPIRV-Registry/blob/master/extensions/INTEL/SPV_INTEL_fpga_memory_attributes.asciidoc

    SPV_INTEL_kernel_attributes https://github.com/KhronosGroup/SPIRV-Registry/blob/master/extensions/INTEL/SPV_INTEL_kernel_attributes.asciidoc

    SPV_INTEL_fpga_reg https://github.com/KhronosGroup/SPIRV-Registry/blob/master/extensions/INTEL/SPV_INTEL_fpga_reg.asciidoc

    SPV_INTEL_blocking_pipes https://github.com/KhronosGroup/SPIRV-Registry/blob/master/extensions/INTEL/SPV_INTEL_blocking_pipes.asciidoc

    SPV_INTEL_fpga_loop_controls https://github.com/KhronosGroup/SPIRV-Registry/blob/master/extensions/INTEL/SPV_INTEL_fpga_loop_controls.asciidoc

    SPV_INTEL_unstructured_loop_controls https://github.com/KhronosGroup/SPIRV-Registry/blob/master/extensions/INTEL/SPV_INTEL_unstructured_loop_controls.asciidoc

    Signed-off-by: Dmitry Sidorov [email protected]

    opened by MrSidims 9
  • Is it valid structured control flow: switch-case goto loop merge

    Is it valid structured control flow: switch-case goto loop merge

    switchcase_goto_loop_merge.spv.txt

    The switch-case is inside the loop. It branches from switch-case to loop merge block. I think it's invalid, but I'd like someone to confirm it. Is there some validator that can check it?

        %808 = OpLabel
               OpLoopMerge **%809** %810 None
               OpBranch %811
        ...
               OpSelectionMerge %813 None
               OpSwitch %849 %814 0 %815 1 %816 2 %817
        %814 = OpLabel
               OpBranch **%809**
        %815 = OpLabel
        %818 = OpLoad %211 %213
        %819 = OpLoad %215 %217
        %820 = OpSampledImage %219 %818 %819
        %822 = OpImageSampleImplicitLod %27 %820 %670
               OpBranch **%809**
        ...
        %813 = OpLabel
               OpUnreachable
        %810 = OpLabel
               OpBranch %808
        %809 = OpLabel
        ...
    
    opened by lifpan 9
  • Need to refine definition of a back edge used by structured control flow rules

    Need to refine definition of a back edge used by structured control flow rules

    The current definition of a back edge in SPIR-V is not quite correct:

    Back Edge: If a depth-first traversal is done on a function’s CFG, starting from the first block of the function, a back edge is a branch to a previously visited block. A back-edge block is the block containing such a branch.

    This was a late addition that doesn't quite work with the intent of the structured control flow rules.

    Suggestions from @dneto0, in issue https://github.com/KhronosGroup/SPIRV-Tools/issues/270 :

    I think the spec's definition of back-edge incorrectly allows cross edges to be classified as back-edges. I think it should instead say the equivalent of "A back-edge is an edge in the CFG from a block B to a block C that dominates B. B may be the same as C."

    But I think glslang's code generation is sensible, and if anything the spec should be amended to clearly allow unreachable continue-constructs.

    For B-> C to be a back edge the "previously visited" phrasing to me means "I am currently visiting B, and the edge makes me want to visit C, but I have previously visited C". It's the "I am currently visiting B" part that is not satisfied if doing a DFS starting a the entry block of the function.

    bug Fixing Inside Khronos 
    opened by johnkslang 8
  • Fix Google extension grammar error and backport

    Fix Google extension grammar error and backport

    Fix grammar error for Google decorate_string & hlsl_functionality1.

    We don't need to put "LiteralString" as a parameter to OpDecorateString itself; they should be specified by the Decoration instead.

    Note that for the backport, I also included OpDecorateId, but guarded it with an "extension" field.

    Let me know if this is not the preferred way to go. I'd happy to adjust.

    opened by antiagainst 7
  • OpLoopMerge + OpBranchConditional

    OpLoopMerge + OpBranchConditional

    According to the description of OpLoopMerge, the loop header block can contain a conditional branch (OpBranchConditional). Doing so would however require the block to contain an OpSelectionMerge in addition to the OpLoopMerge. This is currently not allowed by the spec, because both descriptions state that (OpLoopMerge|OpSelectionMerge) "must be the second-to-last instruction in its block".

    E.g. this code is currently invalid:

       OpSelectionMerge %selmergebb None
            OpLoopMerge %loopmergebb %continuebb None
    OpBranchConditional %condition %true %false
    

    Solution: either remove OpBranchConditional from the OpLoopMerge description or refine the "second-to-last" text so that both merge operations can occur in a block.

    If doing the latter: shouldn't OpLoopMerge allow OpSwitch as well then?

    question 
    opened by a2flo 7
  • Allow SubgroupSize and SubgroupLocalInvocationId with SubgroupBallotKHR

    Allow SubgroupSize and SubgroupLocalInvocationId with SubgroupBallotKHR

    As specified in https://www.khronos.org/registry/spir-v/extensions/KHR/SPV_KHR_shader_ballot.html:

     (Add the SubgroupBallotKHR capability to SubgroupSize.)
     (Add the SubgroupBallotKHR capability to SubgroupLocalInvocationId.)
    
    opened by antiagainst 6
  • Missing support for AMD extensions

    Missing support for AMD extensions

    The current public SPIR-V headers are missing headers/json for SPV_AMD_shader_ballot, SPV_AMD_shader_trinary_minmax, SPV_shader_explicit_vertex_parameter, and SPV_AMD_gcn_shader. Since at least one shipping game (DOOM) uses some of these extensions in Vulkan, we plan to implement these extensions in Mesa for radv. Since Mesa uses the C versions of the headers, and the only public version of the AMD extensions header (in glslang) is the C++ version, this means we'll have to ship modified (non-Khronos-official) versions of the SPIR-V headers in Mesa, which seems unfortunate.

    opened by cwabbott0 6
  • pkg-config file is broken when CMAKE_INSTALL_INCLUDEDIR is absolute

    pkg-config file is broken when CMAKE_INSTALL_INCLUDEDIR is absolute

    opened by alexshpilkin 0
  • CI headers check should ensure non-capability enums are guarded by capability, not by extension

    CI headers check should ensure non-capability enums are guarded by capability, not by extension

    When making a new extension, the typical best practice is that:

    • a new capability is introduced, and that is guarded by the extension
    • other new tokens: instructions and enums, are guarded by that new enum alone.

    The CI check should check this. It's the most common corrective feedback given when reviewing new extensions.

    opened by dneto0 0
  • Add repack instruction information in grammar file

    Add repack instruction information in grammar file

    As stated in https://github.com/KhronosGroup/Vulkan-ValidationLayers/pull/4018#discussion_r853691459 it would be nice to have the information about which instructions are invocation repack instruction in the grammar file to be parsed out. Happy to purpose a PR to simply just change the non-useful "class" : "Reserved", into "class" : "Repack", and a definition of the class (if the WG agrees with the direction)

    opened by sjfricke 0
  • As per SPV_KHR_ray_tracing spec minimum version SPIRV should be 1.4

    As per SPV_KHR_ray_tracing spec minimum version SPIRV should be 1.4

    As per SPV_KHR_ray_tracing spec minimum version required is 1.4 however all the enums defined in spirv.core.grammar.json don't have the version explicitly defined as 1.4. How does the spirv validator then validates this requirement?

    opened by pmistryNV 0
  • install-headers target should be disabled when SPIRV_HEADERS_SKIP_INSTALL is ON

    install-headers target should be disabled when SPIRV_HEADERS_SKIP_INSTALL is ON

    At the moment, CMake script always adds the install-headers custom target. This target should not be created when SPIRV_HEADERS_SKIP_INSTALL option is set to ON.

    opened by TheMostDiligent 0
  • [Request] Updates for Machine-readable content and the documentation.

    [Request] Updates for Machine-readable content and the documentation.

    Hii 😄

    The content of the documentation for the Machine-readable JSON grammar seems to be outdated because they miss the class and version attribute of the instructions item.

    Daniel Baumert

    opened by DanielBaumert 0
Owner
The Khronos Group
Connecting Software to Silicon
The Khronos Group
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 756 Jun 28, 2022
Exploit allowing you to read registry hives as non-admin on Windows 10 and 11

HiveNightmare aka SeriousSam, or now CVE-2021–36934. Exploit allowing you to read any registry hives as non-admin. What is this? An zero day exploit f

Kevin Beaumont 587 Jun 21, 2022
Registry viewer, editor and profile saver

Registry Profiler This app allows certain registry values like the ones for brightness & volume to change and saved into profiles. The first menu give

Codiak 4 Feb 6, 2022
An operating system. Its main goal? Readable code, developer experience and documentation.

OS Dependencies Required for development. sudo apt install build-essential nasm grub-pc-bin grub-common xorriso Required for building cross-compiler.

Stijn Rogiest 2 Jun 20, 2022
Phan Sang 4 Jun 21, 2022
An efficient tool written in C to convert base numbers dumps into human readable string and vice versa.

strtools A tool written in C to convert number bases to human readable string and vice versa. Usage Compile make Help strtools -h Output: Usage: strt

Mikey 4 May 17, 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.5k Jun 22, 2022
LLVM IR and optimizer for shaders, including front-end adapters for GLSL and SPIR-V and back-end adapter for GLSL

Licensing LunarGLASS is available via a three clause BSD-style open source license. Goals The primary goals of the LunarGLASS project are: Reduce the

LunarG, Inc. 151 Jun 18, 2022
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 32 May 3, 2022
Khronos-reference front end for GLSL/ESSL, partial front end for HLSL, and a SPIR-V generator.

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

The Khronos Group 2.2k Jun 25, 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 266 Jun 20, 2022
Professor Terence Parr has taught us how to create a virtual machine Now it is time to pwn virtual machine

My First real world CTF Simple Virtual Machine Challenge description Professor Terence Parr has taught us how to create a virtual machine Now it is ti

null 1 Feb 17, 2022
Maker of special .exe, which contains additional files which are unpacked when .exe is run

exe-archivator Program that make exec-me.exe, which contains additional files which are unpacked when exec-me.exe is run. After compleating unpacking

Roman Karetnikov 4 Dec 17, 2021
The given files contains a coded algorithm for a program of "OMR Evaluation" With negative marking below are brief info regarding its feature

OMR-Evalution The given files contains a coded algorithm for a program of "OMR Evaluation" With negative marking below are brief info regarding its fe

Harsh Shrivastava 4 May 14, 2022
Learn how to connect your Flexispot (LoctekMotion) desk to the internet. This repository contains a collection of scripts to get your started, combined with research and instructions.

(image source: Windows Central) Turn your LoctekMotion/FlexiSpot desk into a smart desk Recently I acquired a new standing desk from FlexiSpot. During

Mick Vleeshouwer 147 Jun 21, 2022
This repository contains toy ImPlot applications that demonstrate some of the library's functionality

ImPlot Demos This repository contains toy ImPlot applications that demonstrate some of the library's functionality.

Evan Pezent 58 Jun 26, 2022
This repository contains the source for the ANARI API SDK

ANARI-SDK This repository contains the source for the ANARI API SDK. This includes: Front-end library API utilties and helpers (mostly for implementat

The Khronos Group 59 May 27, 2022
This repository contains the tools we used in our research on the Google Titan M chip

Titan M tools In this repository, we publish the tools we used in our research on the Google Titan M chip. We presented our results at Black Hat EU 21

Quarkslab 114 May 31, 2022
This repository contains the source-code for the Robothon 24h series of workshops and competition within ENSTA Borj Cedria.

Robothon: The 24h long zero to hero robotics bootcamp What is Robothon? Robothon by Electronix ENSTABC is a 24h long event held within the walls of EN

Radhi SGHAIER 5 Mar 23, 2022