Jon Leech

OK, finally managed to close this after several bogus attempts. Probably clicking on the wrong button.

Re discussion on the mesa issue, Khronos does not "approve" new vendor extensions, though we do try and consistency-check them and make sure they're following the extension guidelines before we...

> Then can the numbers be allocated first, so that I can update headers and start implementation? @yuq how many do you need? We allocate in blocks of 16. I...

> I need 22, aligned to 16 is 32. I reused some enum numbers from GL_NV_mesh_shader, only those begin with 0xF need to be allocated. > > How about the...

> For completeness, the `vk-parse` (CC @krolli) crate that we use under the hood [currently requires `number` to be set](https://github.com/krolli/vk-parse/blob/11f1a1f44e9462cb4c610d9a01b6e2e9793d8c11/vk-parse/src/parse.rs#L958). That should be relaxed to an `Option` and `depends` should...

> @oddhack can you look at this? see if we need a change. I don't have any ability to do Windows development. As far as "why", the header is approaching...

> I don't know, how the generation of the Vulkan-Hpp files could be triggered there. The build is not triggered there AFAIK, unless some of the LunarG folks are doing...

Compilation of the headers is now failing in the clang++-18 portion of the tests for Vulkan-Headers: https://github.com/KhronosGroup/Vulkan-Headers/actions/runs/18392928205/job/52406731689?pr=572 .

I am going to go ahead and publish the Vulkan-Headers update as the problem (seems) confined to a fringe case of the experimental modules with an older C++ version.

If you want to propose a PR to tweak the XML and extension spec that's fine. This all sounds reasonable if very dated.