Extending GL_EXT_spirv_intrinsics

[rdb]

GL_EXT_spirv_intrinsics maps GLSL function declarations to SPIR-V instructions, but a spirv_instruction prototype must be fixed-arity, and its arguments are limited to 32-bit int/bool/float literals or by-id objects. Two classes of instruction therefore can't be defined in a header today:

• instructions with a variable-length operand tail, and
• instructions taking literal-string operands.

An example of such an instruction that is established today is debugPrintfEXT, which cannot currently be expressed using GL_EXT_spirv_intrinsics. As discussed in KhronosGroup/glslang#2679, I would like to add this ability, extending the usefulness of this extension to both existing and potentially new use cases.

Based on the fact that GL_EXT_spirv_intrinsics is established and (de facto) no longer in Draft, I understand I should propose new extensions. I could fold it into a single extension but the functionality cleanly separates along these two orthogonal axes:

Variadic tail support (GL_EXT_spirv_intrinsics_variadic)

This would permit a spirv_instruction-qualified function declaration to end in a trailing ..., which allows 0..n arguments to be passed in. Default encoding is by id, matching the default. For completeness, spirv_literal ... could be made valid which would encode the whole tail as literal operands (a la OpVectorShuffle):

// OpVectorShuffle (literal tail)
spirv_instruction(id = 79)
vec4 shuffle(vec4 a, vec4 b, spirv_literal ...);

String support (GL_EXT_spirv_intrinsics_string)

This would add a new spirv_string pseudo-type, which can only occur in a spirv_instruction-qualified function declaration. It would also allow literal strings to be passed to variadic arguments. They would normally be encoded as an OpString id.

An open question is the combination spirv_literal spirv_string. Current NonSemantic extensions take an OpString by id, but literal string operands are well-established in SPIR-V, such as in OpEntryPoint, where the characters are encoded in successive uint32_t arguments until a null byte is encountered. As far as I know there is no current use case for this, as I'm not aware of any such instruction that can appear in a function body, but it does kind of fall naturally out of the specification so I would be willing to add it for completeness' sake.

Using spirv_by_reference spirv_string would not be allowed since no pointers to string literals can be constructed.

The combination of these extensions allows fully and cleanly capturing GL_EXT_debug_printf:

#extension GL_EXT_spirv_intrinsics : enable
#extension GL_EXT_spirv_intrinsics_variadic : enable
#extension GL_EXT_spirv_intrinsics_string : enable

spirv_instruction(extensions = ["SPV_KHR_non_semantic_info"],
                  set = "NonSemantic.DebugPrintf", id = 1)
void debugPrintfEXT(spirv_string format, ...);

I have no prior experience drafting extensions, so I would like some feedback on whether I'm going in the right direction before proceeding with working out the exact grammar and drafting the extension text.

[Tobski]

Thanks for raising this - would be good to see this happen! Both of these things makes sense. For the question about spirv_literal and spirv_string, I think they should be considered incompatible, and an error should be raised. Otherwise most of what you're suggesting makes sense to me!

For the string portion, one thing I'd note is that there are a couple ways to handle strings for SPIR-V now, based on the recent "abort" extension, where you can pass string data as a regular byte array, rather than using string literals. I suspect we'll be using that kind of handling in future as well, so would be good to provision for that option, but it is probably more involved.

If you wanted to tackle this, it would be nice to see automatic translation of literal strings to uint8_t arrays, like this:

const uint8_t myString[] = "abc";

Which would effectively be the same as:

// This is horrible
const uint8_t cdata[] = uint8_t[](uint8_t(61'),uint8_t(62),uint8_t(63),uint8_t(0));

Any time you then see "spirv_string" on an intrinsic, that array would just be captured and turned into an OpString instead.

But, that is extra work which you've not signed up for so I'm not going to push too hard on that - and it could be handled separately later.