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.
Comments
  • Any chance to make new release?

    Any chance to make new release?

    New sdk vulkan seems needs what is now above last tagged release.

    It would be good to see better coordination about releasing stuff between spirv-* and vulkan-* repos.

    opened by kloczek 24
  • 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 ghost 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
  • doc: Missing description for OpGroupNonUniformPartitionNV

    doc: Missing description for OpGroupNonUniformPartitionNV

    According to the spec, OpGroupNonUniformPartitionNV is currently reserved, but not defined (see https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#OpGroupNonUniformPartitionNV). However, as @greg-lunarg pointed out:

    "Looking at the spec for the GLSL extension GL_NV_shader_subgroup_partitioned, subgroupPartitionNV maps directly to OpGroupNonUniformPartitionNV, so it seems OpGroupNonUniformPartitionNV is well defined."

    (See https://github.com/KhronosGroup/glslang/issues/3085 for reference.)

    The registry home page indicated that feedback should be posted to this repository.

    opened by mmoult 3
  • Add support for the execution mode RegisterMapInterfaceINTEL

    Add support for the execution mode RegisterMapInterfaceINTEL

    This SPIRV extension update will be introducing the new execution mode RegisterMapInterfaceINTEL. This PR adds support for this new mode.

    NOTE

    This execution mode is being added to an existing extension SPV_INTEL_kernel_attributes and is guarded by a new capability FPGAKernelAttributesINTELv2 which implicitly defines the existing capability FPGAKernelAttributesINTEL.

    opened by tiwaria1 3
  • Missing capabilities in spirv.core.grammar.json

    Missing capabilities in spirv.core.grammar.json

    The Vulkan 1.3.222 spec added a reference to three new SPIR-V capabilities to vk.xml:

    • TextureSampleWeightedQCOM
    • TextureBoxFilterQCOM
    • TextureBlockMatchQCOM

    These capabilities are currently missing from the spirv.core.grammar.json file.

    opened by Rua 0
  • Add SPIR-V 5 byte module header size to header file

    Add SPIR-V 5 byte module header size to header file

    from: https://github.com/KhronosGroup/Vulkan-ValidationLayers/pull/4634#discussion_r992749426

    Would be nice to have a constant value in the headers to use for code who needs to skip to first instruction without just having a magic 5 in their code

    opened by sjfricke 0
  • Add initial schema file

    Add initial schema file

    Created an entry in https://github.com/KhronosGroup/Khronos-Schemas/pull/30 that would get pulled in first

    Using the grammar file currently to generate things for SPIR-V tools has an issue of not even knowing what is valid to be in the grammar file. This PR is an attempt to create a schema for the grammar files.

    I took inspiration from the https://github.com/KhronosGroup/Vulkan-Profiles usage of a schema file.

    Has been tested on spirv.core.grammar.json and extinst.*.grammar.json

    Happy to work out the details on how to make this logistically as simple as to not add a burden to future header releases

    opened by sjfricke 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 827 Jan 6, 2023
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 618 Jan 1, 2023
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 1 Nov 15, 2022
Phan Sang 17 Dec 29, 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 6 Dec 24, 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
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. 153 Dec 8, 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 31 Dec 8, 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.4k Jan 9, 2023
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
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 5 Oct 16, 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 216 Dec 28, 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 83 Dec 28, 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 69 Dec 11, 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 149 Dec 5, 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