Using ConstBufferPointer without int64 support/extension?

[Nestorboy]

So I was converting over a simple GLSL vertex program that's using the GL_EXT_buffer_reference extension to Slang, but I soon found out that whenever you use the generic ConstBufferPointer type it relies on GL_EXT_shader_explicit_arithmetic_types_int64 extension.

The GLSL snippet for my buffer reference looks something like this:

layout(buffer_reference, std430) readonly buffer VertexBuffer
{
    Vertex vertices[];
};

layout(push_constant) uniform Constants
{
    VertexBuffer vertexBuffer;
} PushConstants;

And the Slang version I've made looks like this:

[[vk::push_constant]]
cbuffer Constants
{
    ConstBufferPointer<Vertex> vertices;
};

But the generated SPIR-V from this Slang snippet seems to add the additional int64 extension and requires int64 support. I made the Slang compiler output the GLSL code instead of SPIR-V and I quickly noticed that it's using int64 arithmetic to offset the buffer reference pointer to access a specific element.

Is there any reason for this explicit use of int/uint64s to access elements of the buffer or am I missing something about the syntax for getting Slang to generate the desired output that doesn't depend on int/uint64s?

I'm sorta new to Slang and might be missing something, but I'm very excited to work with it. ^^

[natevm]

Vulkan device pointers are 64 bit integers (as are C++ pointers), so support for 64 bit integers is required. For some intuition, imagine an allocation of over 4GB of uint8. To access data beyond that 4GB boundary, a 64 bit address is required.

Is there a platform you are targeting which does not support 64 bit integers but that does support Vulkan’s buffer device addressing feature?

[Nestorboy]

Thank you for the detailed response! For our intents and purposes we don't need to support this combination of features as our project is purely educational.

If the need ever arose, would there be some way to work around this or is it just a non-issue?

[natevm]

Sorry for the long delay…

We might be able to work around this issue by extending the SPIR-V emit logic to output pairs of 32-bit integers.