25 +# List of device extensions to ensure that we support regardless of whether 26 +# the actual driver supports them or not.
I think for an extension to be "faked" it has to be fully unsupported by the underlying VK implementation. For simplicity I think it makes most sense if this is only used in-practice for platform==win32 extensions.
Theoretically winevulkan could fake a "normal" extension that's just not available from the current driver, but that seems like a weird path to go down, and I think it would be best to avoid.
Could the comment be updated to reflect the intended scope of faked extensions?
It won't matter for this initial implementation/usage, but it's interesting to consider if we want conditional support for faked extensions in the future.
27 +FAKED_EXTENSIONS = [ 28 + # Needed to not have an array size of 0. 29 + {"name": "VK_DUMMY_extension", "version": 4} 30 +]
I think the generator code should just handle an empty list, rather than have a stub put in-place.
It would also be nice to have support for FAKED_DEVICE_EXTENSIONS and FAKED_INSTANCE_EXTENSIONS. For now I think it's fine to just implement this for device extensions, but I think the naming should be reflective of the fact this is only for device extensions.
100 +static BOOL wine_vk_device_extension_faked(const char *name) 101 +{ 102 + unsigned int i; 103 + for (i = 0; i < wine_vk_device_extension_faked_count(); i++) 104 + { 105 + if (strcmp(wine_vk_device_extension_faked_idx(i)->extensionName, name) == 0) 106 + return TRUE; 107 + } 108 + return FALSE; 109 +} 110 +
I don't have a strong reason as to why, but the _idx() and _count() functions feel kind of weird to me. What about having this wine_vk_device_extension_faked() as a generated function? It could live around the same area of make_vulkan as wine_vk_device_extension_supported() and wine_vk_instance_extension_supported() are defined. Although then we're left with _idx() used when populating the driver-advertised list of extensions. I don't really have any better suggestions for what to do here, so I'm not too concerned about this part as-is.
Thanks,
Liam Middlebrook
On 7/16/20 12:42 AM, Joshua Ashton wrote: