Allow setting a load order for implicit layers

[DadSchoorse]

For explicit layers it's easy to manage the order with the VK_INSTANCE_LAYERS env var but currently there is no way to specify which implicit layer should be loaded first.
Such a way would be useful for making sure that post processing layers like reshade or vkBasalt get applied before the steam overlay / other overlay layers.
As for how to achieve this, my proposal would be a signed integer value in the manifest file to specify the load priority for each layer.

[samwalls-arm]

Hey, just out of curiosity @lenny-lunarg is there any expected timeline for the P2 milestone contents (this feature in particular) to reach the SDK?

[MarkY-LunarG]

This is something we're looking at starting in about a month or two. We have already started designing it, but are going through internal discussions on making it as clean and easy to use as possible. I hope to have a status for you in about a month. Sorry it's taking so long.

[samwalls-arm]

Hi @MarkY-LunarG, no worries at all. Just wondering what the plans are 👍

[mfncharm]

It seems to me that implicit layer ordering is indeed an area that deserves to be improved. In terms of actual implementation, I am not sure using an integer to capture load priority is a good approach. Who would choose the integers? The system integrator or the layers' developers? Also the chosen integer value would have no meaning by itself. It would only acquire meaning when compared with the integers assigned by all other layers. So assigning these integers requires some coordination. Said that, I think this problem could be solved by providing some guidelines. Or maybe a few priority labels (e.g. LOADED_FIRST, LOADED_LAST, ...) could be used instead of plain integers.

I wonder whether having layers declaring dependencies and/or intent would work. A layer could list other layers (or Vulkan extensions) as its dependencies. Or maybe it could declare the intent of implementing an extension VS adding overlays VS tracing, etc. The loader could use this information to figure out the order. This is just an idea, I think going down this route definitely requires a bit more thought. For example, for instrumentation/validation layers it is not unconceivable wanting to change the order with respect to other layers rather than having it determined in the manifest files.

[MarkY-LunarG]

First, sorry, this actually got dropped in priority as we were working on other items.

Who would choose the integers? The system integrator or the layers' developers?

The layer developers, they have the most knowledge on where their layer would be most useful in general. for example, layers implementing driver type features (like synchronization 2) should be closer to the driver, but layers doing overlay style features should be closer to the application.

Also the chosen integer value would have no meaning by itself... Or maybe a few priority labels (e.g. LOADED_FIRST, LOADED_LAST, ...) could be used instead of plain integers.

The concern about the few lables is you still have the issue of conflicts. Just look at the number of layers that have been encountered at GPUInfo.org. Unless we have something along the lines of more labels:

• NEAREST_TO_APP
• CLOSE_TO_APP
• MIDDLE_BUT_CLOSE_TO_APP
• MIDDLE
• MIDDLE_BUT_CLOSE_TO_DRIVER
• CLOSE_TO_DRIVER
• NEAREST_TO_DRIVER

I wonder whether having layers declaring dependencies and/or intent would work. A layer could list other layers (or Vulkan extensions) as its dependencies

Sounds like we would end up with a lot of circular dependencies that would be hard to work through. However, we were thinking that at least VkConfig could override layer ordering. Always possible we could investigate other options in the future as well.

Unfortunately, due to shifting priorities this is taking longer than I originally hoped.