Another descriptor binding model (new data type idea)

[ghost]

Trivia:

1. Would to suggest the new vulkan descriptor model 2.0 (I have no any details, except raw binding, or using device address).
2. Would suggest to add new type: raw_buffer_t, raw_uniform_t, raw_shared_t, raw_texture_t, raw_image_t, etc.
3. raw_buffer_t, raw_uniform_t, raw_shared_t are similar to uint64_t, but with some rules, limitations and exceptions.
4. There data types respondent from real descriptor bindings. It may also need to be unified in some way.
5. The idea was also motivated by OpenCL.

Example:

layout(image_reference, rgba32f) uniform image2D imageRef;

layout(uniform_reference, scalar, uniform_reference_align = 16) uniform uniformRef {
   uvec4 data;
};

layout(buffer_reference, scalar, buffer_reference_align = 16) buffer bufferRef {
   uvec4 data;
};

layout(shared_reference, scalar, shared_reference_align = 16) shared sharedRef {
   uvec4 data;
};

layout(binding = 0) uniform raw_buffer_t buffers[]; // which can be handled similar alike buffer reference
layout(binding = 1) uniform raw_texture_t textures[]; // which can contain 2D, 3D, cubemap textures, etc.
layout(binding = 2) uniform raw_image_t images[];
raw_shared_t sharedMemory;

void main() {
  bufferRef buf = bufferRef (buffers[0]);
  texture2D tex = texture2D(textures[0]);
  sharedRef sbt = sharedRef(sharedMemory);
  imageRef imf = imageRef(images[0]);
  //vec4 imagePixel = imageLoad(imf, ivec2(coordinate));
}

Let me explain what this is all about:

1. raw_buffer_t, raw_uniform_t, raw_shared_t have a + byteOffset capability
2. References to these handles can be passed by function, with atomic operation capabilities
3. The real number is never known, they are actually virtual
4. Easier to debug because they are bound to descriptor binding, including the indexed model
5. You can check the presence of this binding (element), but again you can't know its number
6. You can't save them (those handles) to memory. You can only operate on them inside the shader.

Why did I still decide not to add the idea from shader model 6.6 in its entirety?

1. Backward compatibility with the current bindings model.
2. Avoiding some misunderstandings and conflicts in terms of typing.

And what will change?

1. Essentially the implementation of the pointer and reference model.
2. The ability to check for presence or empty binding.
3. Different data types for different purposes.
4. Ability to atomic operations on argument in functions.

Virtual device buffer address? Aka. shader model 6.6 miscellaneous. Not applicable everywhere. For example shared is more of a purely hardware thing, and it doesn't have a good binding.

// expose raw_buffer_t
struct VBA64 {
  uint32_t set_binding_index;  //de-facto device address of binding
  uint32_t byteOffset;
};

// expose raw_buffer_t (alt)
struct VBA64Indexed {
  uint16_t set_and_binding; //de-facto device address of binding
  uint16_t index; // if indexed
  uint32_t byteOffset;
};

// expose raw_shared_t
struct VSA32 {
  uint32_t byteOffset;
};

Safety. Stands between the physical device buffer address and the binding to the descriptor. And the same limit checks, validation, and debugging are available (though in bytes, in hex code). Even an availability check is available.