Support (at least) the 1.1.111 spec.

[Y-Less]

Major additions:

1. alias attributes are parsed to generate new versions of commands/structs/enums pointing at the old versions. Usually when an extension has been moved in to the main spec. Also deprecates the old version. Commands will give a warning, structs are implicitly converted, enums reference each other.

Examples:

public void CmdSetDeviceMask (UInt32 deviceMask)
{
	unsafe {
		Interop.NativeMethods.vkCmdSetDeviceMask (this.m, deviceMask);
	}
}

[Obsolete ("CmdSetDeviceMaskKHR is deprecated, please use CmdSetDeviceMask instead.")]
public void CmdSetDeviceMaskKHR (UInt32 deviceMask)
{
	unsafe {
		Interop.NativeMethods.vkCmdSetDeviceMaskKHR (this.m, deviceMask);
	}
}

public enum StructureType : int
{
	...
	PhysicalDeviceBufferDeviceAddressFeaturesExt = 1000244000,
	PhysicalDeviceBufferAddressFeaturesExt = PhysicalDeviceBufferDeviceAddressFeaturesExt,
	...
}

unsafe public partial class PhysicalDeviceFeatures2Khr : PhysicalDeviceFeatures2
{
	public PhysicalDeviceFeatures2Khr () : base () {
	}

	internal PhysicalDeviceFeatures2Khr (NativePointer pointer) : base (pointer) {
	}
}

2. feature tags are now parsed in much the same way as extension tags.

3. extnumber attributes are optionally used for determining enum values.

4. Added a few more basic types: zx_handle_t, DeviceAddress, HMONITOR, GgpStreamDescriptor, and GgpFrameToken.

5. Recognise the INTEL vendor suffix.

6. Currently just disables several android- and metal-specific extensions, as they couldn't be generated correctly.

7. Also disables a few commands that needed pointers to pointers, and fixed pointer arrays (was already listed as TODO in the generator before I touched anything, so this isn't actually a change).

8. Now pulls the latest vk.xml file from the Vulkan docs, not just pinned to 1.0.

[msftclas]

All CLA requirements met.

[radekdoulik]

@Y-Less did you close the PR by a mistake?

[Y-Less]

No, I realised a bug, I'm just working on fixing it. Bit flags moved from extensions to the main spec didn't generate their aliases properly. I was going to reopen it when that was done.

[Y-Less]

It also doesn't currently generate complete enum aliases, so these lines are ignored:

        <type category="enum" name="VkPeerMemoryFeatureFlagBitsKHR"                alias="VkPeerMemoryFeatureFlagBits"/>

And thus enum PeerMemoryFeatureFlags is generated, but enum PeerMemoryFeatureFlagsKhr isn't, which would be required for backwards-compatibility.

[radekdoulik]

OK, I started fixing the whitespace issues meanwhile, so that it is easier for me to review. Let me know when it is ready and I will get back to it.

Thanks for all the work!

[Y-Less]

Sorry about the whitespace. I've fixed that now, along with I hope the other bits. The main change being that it will now generate:

	[Flags]
	public enum PeerMemoryFeatureFlags : int
	{
		CopySrc = 0x1,
		CopyDst = 0x2,
		GenericSrc = 0x4,
		GenericDst = 0x8,
		CopySrcKhr = CopySrc,
		CopyDstKhr = CopyDst,
		GenericSrcKhr = GenericSrc,
		GenericDstKhr = GenericDst,
	}

	[Obsolete ("PeerMemoryFeatureFlagsKhr is deprecated, please use PeerMemoryFeatureFlags instead.")]
	[Flags]
	public enum PeerMemoryFeatureFlagsKhr : int
	{
		CopySrc = 0x1,
		CopyDst = 0x2,
		GenericSrc = 0x4,
		GenericDst = 0x8,
		CopySrcKhr = CopySrc,
		CopyDstKhr = CopyDst,
		GenericSrcKhr = GenericSrc,
		GenericDstKhr = GenericDst,
	}

[Y-Less]

One thing I should flag is this:

9b34dc0

The old generated code contained three enum flag bits whose naming didn't match any others. Most enums have the Bit part of the name removed, except for those three. After I changed some other bits of code they also lost the Bit infix, so I manually put it back for backwards-compatibility. Maybe they should be marked [Obsolete] (maybe all the aliases should).

[radekdoulik]

I have created an api-check rule today to analyze the API changes and looks like there are still few breaking changes.

I will go thru them hopefully tomorrow to see what to do with them.

I am attaching the api-check results: api-changes.zip

[Y-Less]

Unfortunately a lot of them it isn't obvious what the correct response is. Some of them they renamed the functions (for example KHX -> KHR (which doesn't seem to have been done with any aliasing, likely as it was experimental before and now made official). Some were promoted from extensions to the main spec, I've tried to keep this backwards-compatible, but that also not always clear how. If a struct is now an alias of another one, should the old method return the new name or the old name? And how can we make them interchangable, such that the result of an older KHR function can be passed to a new renamed main spec function?

The changed base objects in that report are just my method of aliasing some things, so it is still the same base object transitively, and the removed properties are instead now inherited.

But for many of these decisions I think someone far more experienced should look at it, and compare to existing code. TBH I did this as a way to learn the library and Vulkan when I discovered that this library didn't support the new debugging interface in the main vulkan-tutorial.