ash: Extension structs can't be chained

When a struct has a p_next member, there may be a set of structs that can be pointed to with it to access extended functionality. This is currently gracefully supported by builders. However, those structs can be chained: If Foo and Bar both extend Baz, then a Baz -> Foo -> Bar chain of p_next references is legal, even though Bar does not extend Foo. We should find a way to support this.

My first idea was to replace FooNext and BarNext with BazNext, but some extension structs (e.g. VkPhysicalDeviceVariablePointerFeatures) extend multiple structs, so there would be no correct single trait to replace their extension traits with. Another approach is to compute the union of legal extensions for every extended struct type, but this would cause a quadratic increase in generated code for every new extension struct.

Worst-case scenario, we can fall back on fn next<T>(self, &'a T) without any typechecking at all. Validation layers should do a decent job of checking these, after all.

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 19 (10 by maintainers)

Most upvoted comments

The rule that seems most obvious/natural to me is “extension structs must be preceded in a pNext chain by a struct that they extend”. @MatusT’s approach implements these semantics.

I think I will just finish up #183 as it currently is. I’ll also open an issue on the Vulkan docs, would be nice if this would be defined by the spec.

MaikKlein on Feb 22, 2019

I have an alternative idea for the next function which, however, may introduce a run-time penalty. The next function would be the same for every struct with p_next and It would simply iterate through p_next linked list to the end and append:

pub fn next<T>(mut self, append: &'a mut T) {
  current = self.inner.p_next;
  while(current.p_next != null) { current = current.p_next }
  current.p_next = append;
}

MatusT on Dec 1, 2018