SPIRV-Tools

Discover this repository through its Hacker News conversations.

Explore on GitHub Read Hacker News discussions

3Distinct people

4Mentions

0Explicit recommenders

1.4KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

A public description has not been verified.

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year4 dated mentions

Observed mentions: 2019-09-13 02:12:42 UTC to 2023-10-11 17:20:13 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	1	1
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	2	2
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	0	0
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	0	0
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	1	1

What Hacker News says

4 sources

pharrington·Oct 11, 2023

SPIR-V is an intermediate bytecode format. That bytecode is the data that you use in the Vulkan API, and under the hood your graphics drivers compile that bytecode into the device-specific native shader binary that runs on the graphics hardware. Vulkan doesn't come with any tools to generate that bytecode though. Foreign shader language (like HLSL, GLSL, etc) to SPIR-V compilers exist, and various graphics toolchains can generate SPIR-V. https://github.com/KhronosGroup/SPIRV-Tools does have tools to validate and optimize bytecode. edit: i lied apparently - the SPIRV-Tools does have an assembler that translates text such as the "Corresponding SPIR-V" at https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.htm... to bytecode. However, that's not something you'd want to write manually, especially if you're used to something like GLSL.

In Vulkan Documentation

caballeto·Jul 10, 2020

There is a project along these lines at Google, which is used to test graphic drivers. The generated code is randomly (but equivalently) transformated, and the result is verified to be the same. If it doesn't match, then there is a bug. Link to the project https://github.com/KhronosGroup/SPIRV-Tools.

In Neural programmer better than Quicksort

Jasper_·Jan 12, 2020

Let me offer a rebuttal to that page. > First, SPIR-V was not written with security as a first principle, and it’s unclear whether it can be modified to satisfy the security requirements of the web. At the time of this post's authoring, Google already had a set of SPIR-V restrictions to make it suitable for the web [0]. The only response from Apple I heard was "it doesn't have tests", but, again, it had more than WSL at the time [1]. [0] https://github.com/gpuweb/spirv-execution-env/blob/master/ex... [1] https://github.com/KhronosGroup/SPIRV-Tools/blob/master/test... > Forking the SPIR-V language means developers would have to recompile their shaders, possibly being forced to rewrite their source code anyway. They might have to rewrite some small portions of their shader code to target WebGPU, or run some preprocessing tools to validate i

Read the rest

t. I don't think this was ever a problem. This is basically saying "if they have to change it anyway, why not rewrite it in an entirely new language", but most realistic shader code would be unaffected. > Additionally, browsers would still be unable to trust incoming bytecode, and would be required to validate programs to make sure they are not doing anything insecure. Browsers need to validate WSL/WHLSL too for things like out-of-bounds array accesses. > And since Windows and macOS/iOS don’t support Vulkan, the incoming SPIR-V would still need to be translated/compiled into another language. This is also true for WSL/WHLSL. But SPIR-V has a leg up here, as existing community cross-compile tools like SPIRV-Cross exist [2]. [2] https://github.com/KhronosGroup/SPIRV-Cross/ The argument that we have against WSL/WHLSL is that we do not trust the developers of these specifications to correctly understand the GPU programming environment, and involving IHVs in WSL/WHLSL's design is a waste of time, when they have already produced SPIR-V over many years.

In Raw WebGPU

Jasper_·Sep 13, 2019

There's the start of some in spirv-val. https://github.com/KhronosGroup/SPIRV-Tools/blob/master/test...

In WebGPU and WSL in Safari