* Khronos doc links are now automatically generated in vk.rs
* Added doc links to all other non-generated functions
* Implemented std::error::Error for LoadingError
* Made EntryCustom public in addition to the Entry typedef so that
rustdoc no longer ignores it
* Moved Entry::new into EntryCustom (non-breaking)
* Added EntryCustom::try_enumerate_instance_version. The EntryV1_1 trait
is not implemented for any type. Even if it were, the function would
panic for Vulkan 1.0 implementations
* Added entry and instance creation example to lib docs
* Updated the Display impl for vk::Result so that it matches
other bitmask and enum conventions
* Removed lazy_static dependency because it was no longer being
referenced
193: Fix struct generation with constant size arrays r=MaikKlein a=aloucks
PR #191 introduced a bug into the generator where constant sized array struct fields were generated as slices. This PR adds a flag to `type_tokens` that will revert that behavior while still generating FFI function signatures with pointers instead of fixed sized arrays (e.g. for `set_blend_constants`).
In addition, all instances of `HashMap` and `HashSet` have been replaced with `BTreeMap` and `BTreeSet`, which makes the generation of `vk.rs` idempotent for the same `vk.xml` input. This should obviate the need for #130 and make it much easier to see how changes to the generator or `vk.xml` affect the generated output.
Co-authored-by: Aaron Loucks <aloucks@cofront.net>
All instances of HashMap and HashSet have been replaced with
BTreeMap and BTreeSet. Repeated generation of vk.rs results
in the same output given the same vk.xml and generator.
Note that this commit still contains the struct generation bug
introduced in PR #191. All structs with fixed sized arrays
are currently generated as slices.
183: [WIP] Implement extension chaining r=MaikKlein a=MaikKlein
This is only a proof on concept right now. I'll finish it up next week.
What are your thoughts? Right now this requires a cast from `*const` to `*mut`.
Co-authored-by: Maik Klein <maikklein@googlemail.com>
191: Pass constant size arrays by reference r=MaikKlein a=kvark
Note: this is a breaking change!
Some related reading: https://lkml.org/lkml/2015/9/3/428
This has been plaguing WebRender on gfx-rs port running Windows/Vulkan.
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
184: Experimental AMD extensions r=MaikKlein a=msiglreith
Addresses https://github.com/MaikKlein/ash/issues/178#issuecomment-457942089
Not fully supports all parts of the APIs, just trying to get some general feedback if this meets the expected structuring.
Co-authored-by: msiglreith <m.siglreith@gmail.com>
186: Ray tracing support r=MaikKlein a=gwihlidal
This PR adds support for VK_NV_ray_tracing! (and initial support for VK_EXT_descriptor_indexing, but more support coming for that).
One piece I'm unsure if you have a more suggested approach is what I added to ext/mod.rs for names (both of those extensions are very commonly used, and also required for ray tracing). Maybe there should be a names.rs or something which can implement a static string function for all names that don't warrant their own extension struct?
I have a local example I've been working on that has been testing against this code, as well as support for descriptor indexing. Originally, I was adding an nv_ray_tracing.rs example alongside triangle and texture, but ray tracing requires some specific extensions and also it doesn't need frame bindings, render states, etc. Additionally, this example only works on NV and with a Turing-class GPU, so I'm unsure if it should co-exist with the basic examples? Because of this, I'm going to first start with a fresh example and just get working to show everything needed - we can chat about merging it in after if desired.
These changes + my upcoming ones should take care of both VK_NV_ray_tracing and VK_EXT_descriptor_indexing from https://github.com/MaikKlein/ash/issues/178
Co-authored-by: Graham Wihlidal <graham@wihlidal.ca>
