Maik Klein

@kvark Thanks for the reply. IIRC the last time I had a look at the portability lib I wanted to use `portabilitiy-gfx` directly, so that I can essentially just create...

> Not sure what build issues you are referring to: we have extensive CI coverage both here and on gfx-rs, all master branches should build without issues. Because in the...

I am not sure if that is an ash bug. The spec says `any other case, not covered above | NULL` from https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkGetDeviceProcAddr.html so it should just return a nullptr.

> Ash, maybe it shouldn't ask for these pointers then? Possibly, but ash follows the spec here. Not sure how hard it would be to change that. I don't know...

After thinking about it for a while, I think the situation can be improved. As in only load function pointers for `1.1` if you have requested it. `KhrSwapchainFn_1_0`, `KhrSwapchainFn_1_1` etc...

* ffi signatures: Yes probably? But we are already exposing `&T` in our higher level bindings, so the win doesn't seem that big. * ffi types: Potentially yes? I was...

Yes this is something that is a bit annoying. I think what we can do is this ``` unsafe trait Cast { type Target; } ``` ``` pub fn subpasses(...

> @MaikKlein Is the whole idea undesirable, or just the implementation with unsafe trait in #253? I am actually thinking of bringing this PR back. I just didn't like the...

I don't think any of the allocation functions are in the hot path, so we don't really need to optimize for this. `AsMut` + `Extend` would work but I am...

A few high level comments: This would need a readme that quickly explains the purpose of this library (The why and how). Similar to what ash-window has. We should probably...