Descriptor count for INLINE_UNIFORM_BLOCK WriteDescriptorSet

[kevinboulain]

I might be missing something but there's a small paper cut in WriteDescriptorSet's builder API:

let data: &[u8] = ...;
let mut inline_uniform_block = vk::WriteDescriptorSetInlineUniformBlock::default().data(data);
let mut descriptor_write = vk::WriteDescriptorSet::default()
  .descriptor_type(vk::DescriptorType::INLINE_UNIFORM_BLOCK)
  .dst_set(set)
  .dst_binding(binding)
  .push_next(&mut inline_uniform_block);
descriptor_write.descriptor_count = data.len().try_into().unwrap();

The spec for VkWriteDescriptorSet says:

descriptorCount is the number of descriptors to update. If the descriptor binding identified by dstSet and dstBinding has a descriptor type of VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK, then descriptorCount specifies the number of bytes to update. Otherwise, descriptorCount is one of

• the number of elements in pImageInfo
• the number of elements in pBufferInfo
  [...]

Currently, descriptorCount is set by the builder API depending on the descriptor type so there's no descriptor_count() method but it's not special cased for INLINE_UNIFORM_BLOCK hence the assignment todescriptor_count afterwards.

I guess there's a similar issue for VkWriteDescriptorSetAccelerationStructureKHR's accelerationStructureCount.

[MarijnS95]

Correct, but there's no proposed question, request, or solution?

[kevinboulain]

I'm not familiar with the code generation but I'd assume the preferred fix would be to hook into push_next and set descriptor_count from there? Otherwise, simply providing a descriptor_count() would allow one to keep everything as a single expression.

[MarijnS95]

I would simply expose descriptor_count() rather than poking around in fields inside push_next() behind the users' back (we're not a wrapper, just exposing the low-level bits in Rust form). Would that "solve" this "paper cut" that has a clear workaround work for you?

[kevinboulain]

Like I tried to convey, it's really not that big of an issue, I'd even say it's mostly cosmetic :)
I was simply a bit surprised when I had to write this bit the first time because descriptor_count is automatically set for you for the types that aren't extensions and isn't really exposed otherwise (assuming the preferred API is via the builder pattern) and it felt like I was doing something I shouldn't be doing or that it was an omission in the exposed interface.

The only downside of exposing descriptor_count() is that users could invoke it after using buffer_info()/image_info()/... but as you said, Ash is "not a wrapper", so automatically setting descriptor_count in some cases could be regarded as a small quality of life improvement and having descriptor_count() would allow one to override the default when it's incorrect (e.g.: I assume you could pass a big array of pImageInfo but only want to write a subset).

So, yeah, if I have to propose something: let's expose descriptor_count() if it's not too annoying because I feel like it's less surprising to the user and it actually allows a few more use cases via what, I assume, is the preferred API (the builder pattern). Otherwise, feel free to close :)

[MarijnS95]

e.g.: I assume you could pass a big array of pImageInfo but only want to write a subset

That is a non-argument because this is exactly what sub-slicing is designed to do: .image_info(&lots_of_images[..just_the_number_that_we_care_about]).

---

Think I'll tune the generator to expose this function.