Vulkan-Docs/src/ext_loader
Jon Leech ee13fc355f Change log for May 25, 2018 Vulkan 1.1.76 spec update:
* Update release number to 76.

Internal Issues:

  * Add an exception clause to the license on `vk.xml`, enabling its use
    with GPL-based projects (internal issue 1017).
  * Remove the generated `vulkan_ext.[ch]` files, which are no longer
    supported. Add `src/ext_loader/README.md` explaining why, and update
    files in `xml/` to not generate them by default (internal issue 1268)

Other Issues:

  * Fix typos in valid usage statements for the
    ftext:vkDrawIndexedIndirectCount* commands, replacing
    sizeof(VkDrawIndirectComment) with sizeof(VkDrawIndexedIndirectCommand).
  * Modify the <<spirvenv-module-validation, Validation Rules within a
    Module>> section to require code:NonReadable or code:NonWriteable in
    SPIR-V code for images with an image format of code:Unknown if one of
    the requisite code:shaderImageReadWithoutFormat or
    code:shaderImageWriteWithoutFormat features is disabled.

New Extensions:

  * `VK_KHR_get_display_properties2`
  * `VK_KHR_draw_indirect_count`
2018-05-25 04:00:32 -07:00
..
README.md Change log for May 25, 2018 Vulkan 1.1.76 spec update: 2018-05-25 04:00:32 -07:00

README.md

What Happened To The Vulkan Extension Loader?

If you're looking for the files vulkan_ext.[ch] in this directory, they have been removed. There were two significant problems with these simple wrappers.

First, vulkan_ext exported all extension entrypoints. However, the Vulkan loader also exports entrypoints for the window system integration extensions. If someone tried to compile a project and link it to both the loader and vulkan_ext, they would get a bunch of redefined symbols. This linking error is difficult to work around, because vulkan_ext does not have an easy method of disabling the entrypoints at compile time. It is possible to remove these entrypoints when generating vulkan_ext, but even then you have to manually compile a list of every single extension to be disabled.

Second, each entrypoint is only stored once, regardless of how many instances or devices are created. This means that attempting to use multiple instances or devices in parallel can result in one device calling function pointers that are only valid on the other device, which will crash. You may be able to work around this by never initializing the device dispatch (vkExtInitDevice), but we haven't tried this.

It is still possible to retrieve the last versions of these files in the Github KhronosGroup/Vulkan-Docs repository from the 'v1.1.75' release tag. It is also possible to regenerate them from ../../xml/vk.xml, although we are no longer maintaining the generator code and it may eventually stop working correctly. See README.adoc and the extloader Makefile target in that directory.