GLSL spec says:

The memory qualifiers coherent, volatile, restrict, readonly, and writeonly may be used in the declaration of buffer variables (i.e., members of shader storage blocks). When a buffer variable is declared with a memory qualifier, the behavior specified for memory accesses involving image variables described above applies identically to memory accesses involving that buffer variable. It is a compile-time error to assign to a buffer variable qualified with readonly or to read from a buffer variable qualified with writeonly.

SPIR-V spec says:

Restrict
Apply only to a memory object declaration, to indicate the compiler may compile as if there is no aliasing. See the Aliasing section for more detail.

Possibly relevant, from the change-log:

Khronos SPIR-V Issue #408: (Re)allow the decorations Volatile, Coherent, NonWritable, and NonReadable on members of blocks. (Temporarily dropping this functionality was accidental/clerical; intent is that it has always been present.)

Was the intent to continue disallowing Restrict on members of blocks?

It's worth pointing out that glslang accepts GLSL code with such declarations, and turns them into what is technically invalid SPIR-V:

e.g.

layout(std430, binding=1) coherent restrict buffer _PeakDetect_2_0 {
    layout(offset=0) vec2 average;
    layout(offset=8) int frame_sum;
    layout(offset=12) int frame_max;
    layout(offset=16) uint counter;
};

becomes:

               OpName %_PeakDetect_2_0 "_PeakDetect_2_0"
               OpMemberName %_PeakDetect_2_0 0 "average"
               OpMemberName %_PeakDetect_2_0 1 "frame_sum"
               OpMemberName %_PeakDetect_2_0 2 "frame_max"
               OpMemberName %_PeakDetect_2_0 3 "counter"
...
               OpMemberDecorate %_PeakDetect_2_0 0 Coherent
               OpMemberDecorate %_PeakDetect_2_0 0 Restrict
               OpMemberDecorate %_PeakDetect_2_0 0 Offset 0
               OpMemberDecorate %_PeakDetect_2_0 1 Coherent
               OpMemberDecorate %_PeakDetect_2_0 1 Restrict
               OpMemberDecorate %_PeakDetect_2_0 1 Offset 8
               OpMemberDecorate %_PeakDetect_2_0 2 Coherent
               OpMemberDecorate %_PeakDetect_2_0 2 Restrict
               OpMemberDecorate %_PeakDetect_2_0 2 Offset 12
               OpMemberDecorate %_PeakDetect_2_0 3 Coherent
               OpMemberDecorate %_PeakDetect_2_0 3 Restrict
               OpMemberDecorate %_PeakDetect_2_0 3 Offset 16
               OpDecorate %_PeakDetect_2_0 Block

Which mesa's SPIRV-to-NIR compiler, in turn, rejects as invalid:

SPIR-V WARNING:
    In file ../src/compiler/spirv/spirv_to_nir.c:1073
    Decoration not allowed on struct members: SpvDecorationRestrict
    1552 bytes into the SPIR-V binary

The OpenCL cl_khr_extended_async_copies extension is missing a corresponding SPIR-V extension.

OpGroupAsyncCopy exists and can be mapped to the CL C async_work_group_strided_copy buitlin, but for the 2D - 2D and 3D - 3D variants defined in cl_khr_extended_async_copies there are no corresponding SPIR-V instructions (OpGroupAsyncCopy doesn't support enough parameters for the source and destination offsets and strides in the CL C extension).

I guess we'd probably want two new instructions corresponding to the two builtins introduced in the OpenCL extension, something like OpGroupAsyncCopy2D and OpGroupAsyncCopy3D taking parameters analogous to async_work_group_copy_2D2D and async_work_group_copy_3D3D

There's a bunch of phrases like this:

If Intersection is RayQueryCommittedIntersectionKHR, there must be a current committed intersection (see OpRayQueryCommittedTypeKHR).

However, OpRayQueryCommittedTypeKHR isn't defined anywhere: grepping through this repository, the only mention is in the SPV_KHR_ray_query doc, in the above phrase. Googling, there are two hits, which are the document and the raw html version.

What is it? Where is it defined?

Clicking on any of the links in the sidebar of the ray tracing or ray query extensions will open a new page redirecting you to a raw text version of the HTML page, rather than bringing you to the appropriate section.

Link: http://htmlpreview.github.io/?https://github.com/KhronosGroup/SPIRV-Registry/blob/master/extensions/KHR/SPV_KHR_ray_query.html
Browser: Safari 14.0.3 (16610.4.3.1.4)

The NonSemantic.Shader.DebugInfo.100 has the following generic statement:

Forward references
Forward references are not allowed, to be compliant with SPV_KHR_non_semantic_info.

However, later while defining the DebugTypeComposite instruction, it says:

Members must be the <id>s of DebugTypeMember, DebugFunction, or DebugTypeInheritance. This could be a forward reference.

This statement contradicts the initial spec-wide statement, and caused some issues:

• microsoft/DirectXShaderCompiler#5218
• microsoft/DirectXShaderCompiler#4911

It seems that for those instruction to correctly support HLSL objects, we need to allow circular dependencies, hence forward references.

The spec mentions forward references should not be allowed to comply with SPV_KHR_non_semantic_info, but seems like this spec doesn't mention anything regarding forward references:
http://htmlpreview.github.io/?https://github.com/KhronosGroup/SPIRV-Registry/blob/main/extensions/KHR/SPV_KHR_non_semantic_info.html

Since the only allowed values as members are other non-semantic instructions, it seems same to allow forward references, but maybe I'm missing something.

@baldurk @sheredom (because you're mentioned on https://htmlpreview.github.io/?https://github.com/KhronosGroup/SPIRV-Registry/blob/master/extensions/KHR/SPV_KHR_non_semantic_info.html)

Hi. I think the SPV_KHR_non_semantic_info extension (which lets you use Debug Printf in shaders) is super cool. However, one limitation is that it is not supported for mixed stage shader modules:

UNASSIGNED-Debug-Printf(ERROR / SPEC): msgNum: -1804403757 - Validation Error: [ UNAS
SIGNED-Debug-Printf ] Object 0: handle = 0x2acf98cefe8, type = VK_OBJECT_TYPE_DEVICE;
 | MessageID = 0x9472fbd3 | Error during shader instrumentation: line 0: Mixed stage
shader module not supported
    Objects: 1
        [0] 0x2acf98cefe8, type: 3, name: NULL
ERROR:
VALIDATION [UNASSIGNED-Debug-Printf (-1804403757)] : Validation Error: [ UNASSIGNED-D
ebug-Printf ] Object 0: handle = 0x2acf98cefe8, type = VK_OBJECT_TYPE_DEVICE; | Messa
geID = 0x9472fbd3 | Error during shader instrumentation: line 0: Mixed stage shader m
odule not supported

error: process didn't exit successfully: `target\debug\example-runner-ash.exe -d` (ex
it code: 0xc0000005, STATUS_ACCESS_VIOLATION)

This isn't so bad for glslc (which doesn't support creating mixed stage modules anyway) but for things such as EmbarkStudios/rust-gpu#768 it's a real pain.

Are there any major factors that prevent Debug Printf being using in mixed stage modules? If not, it would be great to work towards removing this limitation.

I found a couple of inconsistencies in the registry with INTEL extensions:

• The ArbitraryPrecisionIntegersINTEL capability says it's enabled by SPV_INTEL_arbitrary_precision_integers, and that's the name on the extension page but the index name and file name is just SPV_INTEL_arbitrary_precision_int.
• RuntimeAlignedAttributeINTEL from SPV_INTEL_runtime_aligned is not listed in the grammar json at all.

On a related but tangential note I've found that quite a few INTEL extensions aren't listed in the registry index nor have specifications, but are referenced in the json. I'm not sure if that's deliberate, if these are intended to be private extensions? As far as I can see enumerants are already reserved for vendors via spir-v.xml so it's odd to have otherwise private extensions mentioned in the grammar.

A problem I routinely have when trying to read the SPIR-V spec is that finding things is a chore as some things have very generic names like Offset, R or 2D, etc which have multiple references in the spec.

I think it would be better to use fully qualified names everywhere such as ImageOperandsOffsetMask, ImageChannelOrderR, Dim2D

This is not just a problem for these specific names and enums, this problem appears for a huge amount of names in the SPIR-V specification and makes it really hard to search for things.

Hello all,

I compiled the following shader (simple.vert):

#version 450

layout(binding = 0) uniform samplerBuffer pos;

void main()
{
	gl_Position = texelFetch(pos, gl_VertexIndex);
}

with

glslc -Os --target-env=vulkan1.3 simple.vert

and i get the following message:

shaderc: internal error: compilation succeeded but failed to optimize: In SPIR-V 1.6 or later, sampled image dimension must not be Buffer
%17 = OpTypeSampledImage %16

I also compiled and optimized with glslangValidator/spirv-opt and i get the same error.
How can we use Vulkan's uniform texel buffers with Vulkan 1.3 and spirv 1.6?

I want deploy this doc site in a offline scenario.
unlike other XXX-Registry repo (OpenCl-Registry ,OpenGL-Registry) , why not a index.php file in this repo.
when I visit link https://www.khronos.org/registry/SPIR-V/specs/ ,I saw the sub dir
1.0,
1.1,
1.2
unified1

but subdir of this repo is
CODE_OF_CONDUCT.md extensions/ nonsemantic/ README.md

There seems to be conflicting information regarding what pointers OpPtrAccessChain may be applied to:

The spec classifies values obtained from that instruction as "variable pointers" (2.2.2, page 19), and later in 2.16.1 it says variable pointers may only point to StorageBuffer and Workgroup storage classes.

But in the definition of OpPtrAccessChain, it is explicitly specified what the behavior is when using the Element operand to offset a pointer in the PushConstant storage class, and the behavior is also implied to be valid (but the offset impl-defined) for other storage classes too.

To compute the new element address, Element is treated as a signed count of elements E, relative to the original Base element B, and the address of element B + E is computed using enough precision to avoid overflow and underflow. For objects in the Uniform, StorageBuffer, or PushConstant storage classes, the element’s address or location is calculated using a stride, which will be the Base-type’s Array Stride if the Base type is decorated with ArrayStride. For all other objects, the implementation calculates the element’s address or location.

The spec says this about OpTypeBool:

If they are stored (in conjunction with OpVariable), they can only be used with logical addressing operations, not physical, and only with non-externally visible shader Storage Classes: Workgroup, CrossWorkgroup, Private, Function, Input, and Output.

Does this imply that it is not possible to declare a global UniformConstant boolean variable? That would imply that declaring a uniform bool in a SPIR-V shader targeting OpenGL is illegal, which surely cannot be the intent?

PS. If this is not the right place for filing issues against the SPIR-V specification, let me know and I will file it elsewhere.

Related to KhronosGroup/SPIRV-Tools#3387

The spec https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#_image_instructions says

If the magnitude of Value is too small to represent as a normalized 16-bit floating-point value, the result may be either +0 or -0.

It sounds like the result could be +0, -0, or anything else. Is it the case ?
Or the spec wanted to say the result is either +0 or -0 and no other values are allowed ?

Hope this is the right place to report this.

Background: KhronosGroup/SPIRV-Tools#2128

Currently, the documentation on SPIR-V says to Atomic operations that Result Type must be a scalar of integer type or floating-point type. But, with the Vulkan memory model, you get an error per the linked SPIR-V tools issue. While the incompatibility might be clear to some, and it will eventually be for all that try it, it could be more clear right in the documentation.

Appendix A.1 "Changes from Version 0.99, Revision 31" says:

• Added IndependentForwardProgress Execution Mode (14271).

This is the only place within the specification where this execution mode is mentioned.

Why are the aliasing/restrict decorations supposed to go on OpVariable, and how does that work? You can eliminate all your local OpVariables through mem2reg. My pointers are loaded from a PushConstant, and don't even have an OpVariable. What is their aliasing behavior?

It makes more sense to make aliasing a storage class: PhysicalStorageRestrict and PhysicalStorageAliased. This way it won't fall off under CFG transformations.

I am assuming the SBT Index in OpExecuteCallableKHR is supposed to be a 32-bit (unsigned?) int but seems there is no explicit rule in the SPV_KHR_ray_tracing spec

Vulkan describes constraints on how types may be laid out in memory, in section 15.6.4. Offset and Stride Assignment, but then seems to not say anything about Load and Store operations that specify a lower alignment. Indeed, it seems that the only rules mentioning Aligned decoration are

VUID-StandaloneSpirv-PhysicalStorageBuffer64-04708
If the PhysicalStorageBuffer64 addressing model is enabled, all instructions that support memory access operands and that use a physical pointer must include the Aligned operand

and

VUID-RuntimeSpirv-PhysicalStorageBuffer64-06315
If the PhysicalStorageBuffer64 addressing model is enabled the pointer value of a memory access instruction must be at least as aligned as specified by the Aligned memory access operand.

Moreover, emitting Loads and Stores of int32 with Aligned value of 1 seems not to trip the validator, though I haven't tested whether misaligned loads and stores actually happen to work or not.

Thus far it appears to me that this is hole in the specification, and it would be nice to see it clarified and validator fixed.

Hi,

Currently OpGenericCastToPtr/OpPtrCastToGeneric instructions provides casting from/to a pointer in Generic storage class to/from a pointer in Workgroup, CrossWorkgroup or Function storage classes.

In intel/llvm#1840 we added 2 more storage classes: DeviceOnlyINTEL/HostOnlyINTEL to represent global memory that can be allocated on device or host appropriately. Also we want to add in SPIR-V a possibility to cast from CrossWorkgroup pointer to DeviceOnlyINTEL/HostOnlyINTEL pointer and vice versa. There are basically two options how it can be achieved:

1. Add new instructions for that;
2. Expand OpGenericCastToPtr/OpPtrCastToGeneric potential in casting (under the extension).

The second option is slightly preferable for us, but taking in the account, that it will lead to addition of vendor customization in https://github.com/KhronosGroup/SPIRV-Tools which way is preferable for the community?

Thank you in advance.

Such code:

layout(constant_id = 0) const int N_bins = 42;
layout(set = 0, binding = 2) buffer Buf {
    uint arr[N_bins];
    float f;
};

Cannot be translated correctly. This "works" in glslang but actually will break as soon as we specialize N_bins to be anything different than 42. The issue is the Offset decoration on struct type members takes a literal, instead of a constant instruction like OpTypeArray does for its length parameter, meaning we can't express the relation with the spec constant.

Generated code for reference:

OpDecorate %N_bins SpecId 0
OpDecorate %_arr_uint_N_bins ArrayStride 4
OpMemberDecorate %Buf 0 Offset 0
OpMemberDecorate %Buf 1 Offset 168 ; problem area, this needs to depend on %N_bins
OpDecorate %Buf BufferBlock
OpDecorate %__0 DescriptorSet 0
OpDecorate %__0 Binding 2

%N_bins = OpSpecConstant %int 42
%uint = OpTypeInt 32 0
%_arr_uint_N_bins = OpTypeArray %uint %N_bins
%Buf = OpTypeStruct %_arr_uint_N_bins %float
%_ptr_Uniform_Buf = OpTypePointer Uniform %Buf
%__0 = OpVariable %_ptr_Uniform_Buf Uniform

Section 2.16.2, Validation Rules for Shader Capabilities, of the SPIR-V 1.3 Unified specification states:

At most one of RowMajor and ColMajor Decorations can be applied to a structure type.

The RowMajor and ColMajor decorations are applied to structure members, not the structure type.

Why is the conversion from GLSL to SPIR-V missing a parameter?
coopMatLoadNV -> OpCooperativeMatrixLoadNV

void coopMatLoadNV(out fcoopmatNV m, volatile coherent float16_t[] buf, uint element, uint stride, bool colMajor);
OpCooperativeMatrixLoadNV seems to miss named "element" parameter.

OpTypePointer takes a storage class. OpVariable takes an OpTypePointer and another storage class.

I don't see any validation rules regarding these two storage classes. In SPIR-V tools, I can see the following validation performed:

  // SPIR-V 3.32.8: Check that pointer type and variable type have the same
  // storage class.
  const auto result_storage_class_index = 1;
  const auto result_storage_class =
      result_type->GetOperandAs<uint32_t>(result_storage_class_index);
  if (storage_class != result_storage_class) {
    return _.diag(SPV_ERROR_INVALID_ID, inst)
           << "From SPIR-V spec, section 3.32.8 on OpVariable:\n"
           << "Its Storage Class operand must be the same as the Storage Class "
           << "operand of the result type.";
  }

However, there's no such requirement in the spec at 3.32.8 under OpVariable (or anywhere else, searching for the validation language).

What's correct here?

Context: I'm looking at performing an in-place removal of an interface variable, and am wondering if I can just do this:

 %v2float = OpTypeVector %float 2
 %_ptr_Input_v2float = OpTypePointer Input %v2float
-%ToBeRemoved = OpVariable %_ptr_Input_v2float Input
+%ToBeRemoved = OpVariable %_ptr_Input_v2float Private

(and remove the variable from OpEntryPoint of course)

Compare the wording for StorageImageMultisample and ImageMSArray.

StorageImageMultisample
Uses multi-sample images for non-sampled images

ImageMSArray
An MS operand in OpTypeImage indicates multisampled, used without a sampler.

From their descriptions alone one may believe that the two capabilities are equivalent. The ImageMSArray capability should require the Arrayed operand in OpTypeImage to be set too.

OpExecutionMode specification states:

This instruction is only valid if the Mode operand is an execution mode that takes no Extra Operands, or takes Extra Operands that are not <id> operands.

Whereas LocalSizeId as a Mode operand, takes <id> operands:

LocalSizeId Same as the LocalSize Mode, but using <id> operands instead of literals. The operands are consumed as unsigned and each must be an integer type scalar.

Same thing goes for LocalSizeHintId, etc.

Current compilers seem to use WorkgroupSize to achieve this, but that builtin is deprecated in 1.5, and specification recommends LocalSizeId as replacement.

WorkgroupSize
Deprecated (use LocalSizeId Execution Mode instead).
Work-group size in GLCompute or Kernel Execution Models. See the client API specification for more detail.

Minimal code as illustration:

#version 460

layout(local_size_x_id = 1, local_size_y_id = 2, local_size_z_id = 3) in;
void main(void)
{
}

Code emitted by glslc:

; SPIR-V
; Version: 1.5
; Generator: Google Shaderc over Glslang; 10
; Bound: 12
; Schema: 0
               OpCapability Shader
          %1 = OpExtInstImport "GLSL.std.450"
               OpMemoryModel Logical GLSL450
               OpEntryPoint GLCompute %main "main"
               OpExecutionMode %main LocalSize 1 1 1
               OpSource GLSL 460
               OpSourceExtension "GL_GOOGLE_cpp_style_line_directive"
               OpSourceExtension "GL_GOOGLE_include_directive"
               OpName %main "main"
               OpDecorate %7 SpecId 1
               OpDecorate %8 SpecId 2
               OpDecorate %9 SpecId 3
               OpDecorate %gl_WorkGroupSize BuiltIn WorkgroupSize
       %void = OpTypeVoid
          %3 = OpTypeFunction %void
       %uint = OpTypeInt 32 0
          %7 = OpSpecConstant %uint 1
          %8 = OpSpecConstant %uint 1
          %9 = OpSpecConstant %uint 1
     %v3uint = OpTypeVector %uint 3
%gl_WorkGroupSize = OpSpecConstantComposite %v3uint %7 %8 %9
       %main = OpFunction %void None %3
          %5 = OpLabel
               OpReturn
               OpFunctionEnd

The following when assembled and fed to spirv-val results in error:

; SPIR-V
; Version: 1.5
; Generator: Google spiregg; 0
; Bound: 5
; Schema: 0
               OpCapability Shader
               OpMemoryModel Logical GLSL450
               OpEntryPoint GLCompute %main "main"
               OpExecutionMode %main LocalSizeId %spec_x_uint %spec_y_uint %spec_z_uint
               OpSource HLSL 670
               OpName %main "main"

               OpDecorate %spec_x_uint SpecId 1
               OpDecorate %spec_y_uint SpecId 2
               OpDecorate %spec_z_uint SpecId 3

       %uint = OpTypeInt 32 0
       %void = OpTypeVoid
     %v3uint = OpTypeVector %uint 3
          %3 = OpTypeFunction %void

%spec_x_uint = OpSpecConstant %uint 1
%spec_y_uint = OpSpecConstant %uint 1
%spec_z_uint = OpSpecConstant %uint 1

       %main = OpFunction %void None %3
          %4 = OpLabel
               OpReturn
               OpFunctionEnd

spirv-val gives following error:

error: line 4: OpExecutionMode is only valid when the Mode operand is an execution mode that takes no Extra Operands, or takes Extra Operands that are not id operands.
  OpExecutionMode %main LocalSizeId %2 %3 %4

(This is not limited to SPV_KHR_ray_tracing but noticed it here first)

seems the cols= in the asciidoctor needs to be fixed in most the tables as they don't render correctly on Github

Example:

SPV_KHR_ray_tracing.html

SPV_KHR_ray_tracing.asciidoc

These are in the Khronos SPIR-V Registry.

I've been looking at some SPIR-V samples from https://github.com/dneto0/spirv-samples and found some that seem to be invalid. Specifically, they declare a structure, decorate that struct's members as builtins, but don't declare that structure to be a block. For example: https://github.com/dneto0/spirv-samples/blob/main/spvasm/SpvModuleScopeVarParserTest_BuiltinPosition_BuiltIn_Position.spvasm. Also see dneto0/spirv-samples#2

According the Vulkan spec this seems to be invalid:

be declared in a block whose top-level members are the built-ins.

I couldn't find explicit rules in the core SPIR-V spec for this, however. Consensus from some open source SPIR-V folks is looking towards this being a missed validation rule.

The document doesn't contain the words load, access, or copy, so I don't know if the decorator goes on the OpLoad, the OpAccessChain or the OpCopyObject.. And do I even need the OpCopyObject? And how viral is the NonUniform decorator? Would like the document to be more prescriptive.

I think it would be a good idea to describe best practices when generating the HTML artifacts for an asciidoc extension.

I've been using something like the following, which matches the HTML output for many (but not all) of the HTML extensions in this repo:

$ asciidoc -b html5 -a icons -a toc2 -a toclevels=1 -o SPV_my_extension.html SPV_my_extension.asciidoc

There is probably an equivalent that uses the more modern asciidoctor toolchain but I haven't had the need to figure out what it is... yet.

Would this be helpful? Should we document this in the README or using some other mechanism? Should we include a Makefile in this repo?

The SPIR-V spec says:

No function can be targeted by both an OpEntryPoint instruction and an OpFunctionCall instruction.
...
The Linkage Attributes Decoration cannot be applied to functions targeted by an OpEntryPoint instruction.

However, OpenCL says:

It is just a regular function call if a __kernel function is called by another kernel function.
...
The extern storage-class specifier can only be used for functions (kernel and non-kernel functions) and global variables declared in program scope or variables declared inside a function (kernel and non-kernel functions).

The OpenCL conformance test suite includes separately-compiled and linked files where one contains an extern declaration of a kernel, and a call to it from with another entrypoint, and the other file contains the definition of that kernel.

In order to properly link them, the definition should have external linkage attributes. After linking, the resulting module will have two entry points, where one includes a call to another. Is the intention that the compiler and/or linker should produce two variations of the called kernel so as to not violate the SPIR-V spec? Or should the SPIR-V spec move those validation rules to the shader section?

It is not possible to have OpSpecConstantOp for OpPtrCastToGeneric or OpGenericCastToPtr currently

Both OpPtrCastToGeneric or OpGenericCastToPtr must appear in a block so the following is invalid

%void = OpTypeVoid
%func = OpTypeFunction %void
%f32 = OpTypeFloat 32
%f32ptr_gen = OpTypePointer Generic %f32
%f32ptr_wg = OpTypePointer Workgroup %f32
%var_wg = OpVariable %f32ptr_wg Workgroup
// spirv-val error: PtrCastToGeneric must appear in a block
%ptr_gen = OpPtrCastToGeneric %f32ptr_gen %var_wg
%ptr_wg = OpGenericCastToPtr %f32ptr_wg %ptr_gen
%main = OpFunction %void None %func
%main_entry = OpLabel
OpReturn
OpFunctionEnd

but at the same time SpecConstantOp cant appear in a function declaration so the following is also invalid

%void = OpTypeVoid
%func = OpTypeFunction %void
%f32 = OpTypeFloat 32
%f32ptr_gen = OpTypePointer Generic %f32
%f32ptr_wg = OpTypePointer Workgroup %f32
%var_wg = OpVariable %f32ptr_wg Workgroup
%main = OpFunction %void None %func
%main_entry = OpLabel
// spirv-val error: SpecConstantOp cannot appear in a function declaration
%ptr_gen = OpSpecConstantOp %f32ptr_gen PtrCastToGeneric %var_wg
%ptr_wg = OpSpecConstantOp %f32ptr_wg GenericCastToPtr %ptr_gen
OpReturn
OpFunctionEnd

So I am not sure when it is possible to use something such asOpSpecConstantOp %_ PtrCastToGeneric

"Operands to OpPtrEqual, OpPtrNotEqual, and OpPtrDiff must not be pointers into the PhysicalStorageBuffer storage class."

Is this a misprint? How else do I compare these pointers?

tl;dr - It would be nice to have a more consistent knowledge where OpTypeBool are allowed

in OpTypeBool it says

only with non-externally visible shader Storage Classes: Workgroup, CrossWorkgroup, Private, Function, Input, and Output.

but other Storage Classes such as Generic, CallableDataKHR, etc would also be "non-externally visible"

Also it seems that according to spirv-val the BuiltIn decoration also matters if it is "external", but I can't find that wording anywhere in the spec

Last thing, It also says

they must only be used with logical addressing operations, not physical

but is that suppose to just mean anything without OpMemoryModel Logical as the spec doesn't define any operations that are logical, just the model

DebugEntryPoint instruction has an operand which should refer to an entry point:

Entry Point is the <id> of the OpEntryPoint being described.

But OpEntryPoint doesn't have the result id.

Perhaps the Entry Point operand could refer to the result id of an OpFunction (which is also targeted by OpEntryPoint), but in this case it would be a forward reference.

@baldurk could you please clarify?

OpWritePackedPrimitiveIndices4x8NV implicitly refer to "output variable decorated with the PrimitiveIndicesNV BuiltIn" instead of using an explicit ID. The OpEntryPoint interface is defined as

The set of Interface must be equal to or a superset of the global OpVariable Result referenced by the entry point’s static call tree, within the interface’s storage classes.

Glslang (Version: 10:11.0.0) doesn't include the variable in the interfaces if only OpWritePackedPrimitiveIndices4x8NV is used but no other explicit references. I think either:

• This is (effectively) expected behavior, and we could add a note to SPV_NV_mesh_shader clarifiying this;
• This is a bug in GLSLang, implicit reference should count for the interfaces, the spec should change either the definition of OpEntryPoint or OpWritePackedPrimitiveIndices4x8NV.

According to the Vulkan spec, PrimitiveId is legal in fragment shaders:

VUID-VkGraphicsPipelineCreateInfo-pStages-00740
If pStages includes a fragment shader stage and a geometry shader stage, and the
fragment shader code reads from an input variable that is decorated with PrimitiveID,
then the geometry shader code must write to a matching output variable, decorated with
PrimitiveID, in all execution paths

According to the latest SPIRV spec, however, the decoration requires one of Geometry, Tessellation, RayTracingNV, RayTracingKHR, MeshShadingNV, none of which (to my knowledge) should be used by the fragment stage.

Which specification is correct in this case, or have I missed something?

The SPV_AMD_gpu_shader_half_float extension references SPIR-V 1.10. This version of SPIR-V does not exist (yet).

This extension is written against Revision 1 of the version 1.10 of the SPIR-V Specification.

https://github.com/KhronosGroup/SPIRV-Registry/blob/master/extensions/AMD/SPV_AMD_gpu_shader_half_float.asciidoc#dependencies

Consider the following GLSL program:

            #version 460

            #extension GL_EXT_buffer_reference                 : require
            #extension GL_EXT_buffer_reference2                : require
            #extension GL_EXT_buffer_reference_uvec2           : require
            #extension GL_EXT_scalar_block_layout              : require
            #extension GL_EXT_shader_explicit_arithmetic_types : require

            #pragma use_vulkan_memory_model

            layout(buffer_reference, scalar) buffer uintPtr {
                uint data;
            };

            layout(buffer_reference, scalar) buffer floatPtr {
                float data;
            };

            void main() {
                uint64_t addr = 0xdeadbeef00l; /* assume this location is valid */
/* 21 */        uintPtr(addr).data = 42;
/* 22 */        floatPtr(addr).data = 1.0;
            }

lines 21 and 22 each will be translated into a sequence of OpConvertUToPtr and OpStore without any aliasing-related decorations. Vulkan SPIR-V doesn't seem to say anything about aliasing of pointers obtained by converting from an integer and it's thus unclear why the above program is valid.

SPIRV-Registry repo has more SPIR-V extensions listed than in the registry, specifically, we are missing links to:

SPV_INTEL_shader_integer_functions2
SPV_INTEL_fpga_loop_controls
SPV_EXT_fragment_shader_interlock
SPV_NV_shader_sm_builtins

There are some issues with the current SPV_NV_cooperative_matrix extension proposal:

• ColumnMajor should be more than a Boolean that states row or column major layout since there are more layouts than just these two. At least right now, in AMX, we should be able to specify the VNNI format that consists of packing small precision data into 32 bits to be contiguous in memory. We can call this layout "word_packed".
• Making rows and columns constants is too restrictive. We should allow both constant and variables. While GPUs require constant values for diverse performance reasons, AMX and CPU hardware has no such restriction.
• We should not limit the subgroup concept to the NVIDIA size of 32. Subgroup size is the simd size and can be dictated by the user. The implementation will specify whether it supports that simd size or not. But from the interface perspective, we should not have such restriction.
• We should make sure the interface is extendable to include other operations such as transpose transform.

The spec language for these functions says "Results are computed per component. The resulting value is undefined if Operand 2 is 0". If the operands are vectors, it's not clear what that means.

Does it mean "the whole results is undefined if any component of operand 2 is zero"?
Or, does it mean "components of the result are undefined if the corresponding component of operand 2 is zero"?

From my tests, it appears that AMD (AMDVLK driver) implements for former while Intel and Nvidia implement the later.

@johnkslang @dneto0 @raunraun @HansKristian-Work and other interested parties: heads-up that we propose to rename the default branch of this repository to 'main' in late August 2021, following emerging Khronos & github practice (for Khronos members, see internal khronos-general issue 106). This will have very little impact, although if you have a checked-out repository clone, you may want to follow the simple instructions github will pop up on the repository webpage describing how to do the same locally.

If there is a concern about this, please raise it here by 2021-08-23.

Links like these from the SPIR-V registry page don't seem to work. I keep getting this error:

TypeError: NetworkError when attempting to fetch resource.

I'm using the current version of Firefox.

It would probably be better to link directly to the AsciiDoc source, since that renders properly in GitHub.

Came across this while writing validation for KhronosGroup/SPIRV-Tools#4828

I assume the following is not actually allowed, but spirv-val doesn't check it and nothing in spec to refer to it being illegal.

OpExecutionMode %entrypoint LocalSize 1 2 1
OpExecutionMode %entrypoint LocalSize 1 1 2

Description of PtrAccessChain seems to say nothing about the case when the Base belongs to PhysicalStorageBuffer class.

To compute the new element address, Element is treated as a signed count of elements E, relative to the original Base element B, and the address of element B + E is computed using enough precision to avoid overflow and underflow. For objects in the Uniform, StorageBuffer, or PushConstant storage classes, the element’s address or location is calculated using a stride, which will be the Base-type’s Array Stride if the Base type is decorated with ArrayStride. For all other objects, the implementation calculates the element’s address or location.

I believe the intent was to use ArrayStride with PhysicalStorageBuffer Base as well? In practice spirv-val seems to be happy with PhysicalStorageBuffer Base that doesn't have ArrayStride decoration. Of drivers' compilers, NIR expects an explicit stride, blowing up on an assert otherwise, and Nvidia's seems to work as if stride was size of the pointee or 1 (the pointee size this was tested with was int8, so it's unknown whether it's the former or the latter.)

Is there language on how to define perTask-tagged blocks in SPIR-V? glslang is generating Offset and MatrixStride OpMemberDecorates for perTask-tagged ins/outs, as if they were SSBOs or UBOs, but the actual storage class is Input/Output. Nowhere else, I believe, does SPIR-V use storage decorations for anything other than UniformConstant, StorageBuffer, PushConstant or ShaderRecordBuffer.

All the mesh shader interface variable declarations seem unidiomatic and I'm not confident I can get things all right just by probing glslang.

The documentation for Reflect is as follows:

In particular my issue is with "This computation assumes N is already normalized". What happens if N is not normalised? Do we get undefined behaviour or do we get a result that isn't what we would expect it to be (unnormalised) but that is still deterministic nonetheless?

The DebugSource instruction requires a File operand:

File is an OpString holding the name of the source file including its full path.

What's the appropriate OpString for a shader that is generated on the go and only exists in memory?

Is it valid to pass "" as the File operand if the Text operand is provided?

Text is an OpString that contains text of the source program the SPIR-V module is derived from.