vk-sys should be autogenerated from vk.xml #89
Comments
|
There's also the vk_generator crate which was written for this purpose. |
|
See also this issue: KhronosGroup/Vulkan-Docs#210 |
|
I'd like to bump this in priority, if possible, in relation to #525. Being able to run on Metal, D3D12, and even GL, would vastly expand the reach-ability of Vulkano and remove the blockers potential users may see in this library. We can't replace the existing vk-sys types directly, but we could easily get away with changing the generation parameters if it was done automatically with |
|
This is blocked by Osspial/vk-rs#7, Osspial/vk-rs#8 and Osspial/vk-rs#11 |
|
@tomaka all those vk-rs blockers are resolved now 🎉 |
|
I just published vk_generator 0.3, which should resolve any issues blocking vulkano using it to autogenerate the functions. |
|
I'm in the process of writing a PR to bring
|
|
@Osspial I'd prefer to leave vk-sys untouched and switch vulkano directly to vk_generator. |
|
I've pushed some code that should resolve the Vulkan handle issue, but that isn't on crates.io yet. AFAIK that was the last issue in vk_generator that needed to be resolved, and now it's just a matter of implementing the changes within vulkano. |
|
Began migrating the code! This still isn't fully working, as I haven't gotten the multiple-structs-for-different-function-categories thing resolved, but most other changes needed to get this working within Vulkano have been made. I'll submit a PR when that's ready. My instinct here is to share the function pointers between all the structs that need them with a https://github.com/Osspial/vulkano/tree/vk-sys-autogenerated |
|
Actually, scratch that - I can see a reasonably simple way to automatically split up the function pointer structs now. Besides a few entry-point functions ( |
|
@Osspial I'm not 100% certain that this is an entirely robust solution, but I'm willing to give it a go. |
|
@Osspial what's your understanding of what remains to be done here? I don't think anyone's driving at the moment. The work does sound like a valuable addition. |
|
@knappador It probably wouldn't be difficult to implement, but I haven't thought about |
|
@Osspial can you dump off any dirty work in a spiked PR or just write up the process you expect needs to be completed? I'm finishing up splitting the shaderc crate and can likely take on the groundwork if the design is laid out. If there's too much work, delegate! =) |
|
Sorry it took a few weeks to get back on this! Adding the feature should be fairly simple - you need to modify the Let me know if any more questions come up if you get around to implementing this. I'll aim to respond sooner than I did this time. |
This updates the structure types to a VK 1.2-ish state. Long term, it makes a ton of sense to autogenerate vk-sys to make adding additional features and enumerations easier [1]. For now, we can hand edit. [1] (vulkano-rs#89)
This updates the structure types to a VK 1.2-ish state. Long term, it makes a ton of sense to autogenerate vk-sys to make adding additional features and enumerations easier [1]. For now, we can hand edit. [1] (vulkano-rs#89)
This updates the structure types to a VK 1.2-ish state. Long term, it makes a ton of sense to autogenerate vk-sys to make adding additional features and enumerations easier [1]. For now, we can hand edit. [1] (vulkano-rs#89)
This updates the structure types to a VK 1.2-ish state. Long term, it makes a ton of sense to autogenerate vk-sys to make adding additional features and enumerations easier [1]. For now, we can hand edit. [1] (vulkano-rs#89)
* vulkano: image: improve formatting Ran cargo fmt --all. Should we use clippy too ? * vk_sys: add additional formats This updates the vk formats enum to the header that's on my system (vk 1.2-ish). * vulkano: image: Add NV12 and YV12 support These formats are commonly used as targets for hardware and software video decode. The common case is the swapchain allocator (gralloc in the Android use case) allocates some memory, the video stack decodes to it, and then memory can be composited by Vulkan or sent directly to the display. * vk_sys: update structure types This updates the structure types to a VK 1.2-ish state. Long term, it makes a ton of sense to autogenerate vk-sys to make adding additional features and enumerations easier [1]. For now, we can hand edit. [1] (#89) * vk_sys: add VK_KHR_external_memory_fd bindings This adds some basic external memory features. Most of these features are core in VK1.1. * vulkano: memory: add and use DeviceMemoryBuilder We'll need to: (a) Create exportable memory (b) import from a OS descriptor to create DeviceMemory (c) Also support dedicated allocations The device memory API is becoming rather complicated. Let's use the common builder pattern to simplify this. * vulkano: memory: implement some external features This change is sufficient to create exportable memory and export it. It's only been tested on Linux platforms and depends on Unix file descriptors, so enable it only there for now. Import support will be added later. Support for external buffers and images can also be added later if someone needs it.
|
How is this project going, two years onwards? Does it work? Can Vulkano use it? |
|
Vulkano now uses ash as its backend, so this is no longer needed. |
Instead of hand-coding all the definitions, they should be parsed from the same XML definitions that are used to create vulkan.h. This should also add support for the recent extensions for free. I have some WIP code that parses it and generates something that at least seems like rust, I'll try and beat it into shape so it can autogenerate vk-sys/lib.rs.
The text was updated successfully, but these errors were encountered: