Invalid SPIR-V generated from program-scope global variables

[jrprice]

Compiling this with -cl-std=CL2.0 -inline-entry-points:

const int data = 42;
kernel void foo() {}

produces SPIR-V that fails to validate:

error: line 22: StorageBuffer OpVariable <id> '11[%11]' has illegal type.
From Vulkan spec, section 14.5.2:
Variables identified with the StorageBuffer storage class are used to access transparent buffer backed resources. Such variables must be typed as OpTypeStruct, or an array of this type
  %11 = OpVariable %_ptr_StorageBuffer_uint StorageBuffer %uint_42

Program-scope variables default to the global address space in OpenCL 2.x. Marking the variable as either static or constant fixes it.

[alan-baker]

These should likely be treated similarly to how constant data initializers are treated currently. Allocate a descriptor and binding and record the initializer if any.

[BukeBeyond]

These should likely be treated similarly to how constant data initializers are treated currently. Allocate a descriptor and binding and record the initializer if any.

Greetings. I am new!

It seems there is no way to use writable variables in global program scope until Clspv implements that memory can be bound to them. There are many useful cases for such global variables. I use them for graphical debug functions, where a Show function can be called from anywhere, outputting graphic feedback on various algorithmic variables, bypassing all further pixel output (using a global state).

On the other hand, I would like to express my deepest gratitude to the creators of this extraordinary project! It has been my dream to see C++ running on the GPU through mainstream desktop APIs for a over a decade. I am running Clspv in Windows, over Vulkan, with live compilation and graphics, in C++, with templates, lambdas, operators, constructors, devirtualization, and Clspv has demonstrated to be far more stable than HLSL21 and Slang in all my tests so far! HLSL21 currently crashes on the simplest templates, and does not even implement the assignment operator, or constructors yet. It will be a long time before any of these languages catch up to the level of Clang C++, a solid and superior investment in compilers. Yes, HLSL can handle the fixed triangle graphics pipeline for games, descriptor indexing (say for hundreds of textures passed in an array), and physical addressing. My engine (currently in OpenGL) renders nextgen UI, video compositing and 3d entirely in compute. And now with Vulkan and Clspv, I will implement custom memory allocation and a custom image system in large buffers. Having practically full and stable C++ is such a pleasure to program (vs hacking with toy languages), I am looking forward to it!

Thank you for Clspv again!

[rjodinchr]

This is now passing