Application supplied Properties and Features

[expipiplus1]

At the moment it's possible for a developer to write a program which runs
correctly without any validation errors on her hardware, however if she is not
checking any feature support or device limits the program is liable to break
when run on different hardware with lower limits.

It would be desirable to have a validation layer which:

• Can be informed about any features and limits which have been checked by the
  application and are being respected.
• Warns when any unchecked feature is used.
• Warns when any limited functionality is used (and the value is above the
  mandated minimum) and the limit has not been checked.

Obviously a layer has no insight into what has been checked by the application,
so the application would need to be explicit and honest about informing this
layer.

One possible way of informing the layer of these limits would be for the
application to send back a VkPhysicalDeviceProperties and a
VkPhysicalDeviceFeatures describing the limits it's checked. The validation
layer could, instead of checking against the implementation supplied limits,
check against these application supplied limits.

For example, and application which does no checking at all at startup would
simply return a set of limits and features set to zero (or the mandated
minimum).

This is probably possible at the moment by an application inserting its own
layer just above the implementation which always responds with the checked
features and properties, but that's more complicated, and requires some
orchestration between this layer and the application.

Such a tool would be very helpful for people trying to write portable
applications using Vulkan.

[mikew-lunarg]

You might want to have a look at the Device Simulation layer. It is designed to be used in addition to the Validation layers.

DevSim provides overriding the Properties and Features using actual device configurations downloaded from vulkan.gpuinfo.org

[mark-lunarg]

We agree! The Best Practices mode of the KHRONOS validation layer implements checks such as this and warns if the query or get calls were not made. For instance, callinb BindBufferMemory on a buffer for which GetBufferMemoryRequirements was not called will get you the following warning:

VkBindBufferMemory(): Binding memory to [VkBuffer 0xnnnnnnnn] but vkGetBufferMemoryRequirements() has not been called on that buffer.

[expipiplus1]

Yeah, using a device simulator certainly scratches a similar itch. I think what I'm suggesting is just a higher fidelity version of the warnings that @mark-lunarg mentions, where the application is more explicit about what's being checked (perhaps would be too heavyweight for limits on individual resources, but for device properties and limits might not be too bad).

[mark-lunarg]

@expipiplus1, I've added this to the best-practices tracking issue #24. Closing this issue as it'll be tracked there -- thanks!

[expipiplus1]

Thanks!