Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add JSON Schemas for Driver and Layer Manifests #1273

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

charles-lunarg
Copy link
Collaborator

The JSON Schema format allows for automatic validation of a given manifest file. This enhances the ability for layer and driver developers to check that their manifest files are correct, as well as clarifying the exact format that the loader expects manifest files to be in.

These files will be available inside the repo for reference, but the primary location they will be made available from is:
https://schema.khornos.org/vulkan/

Each version of the Driver and Layer Manifest formats have their own schema, allowing verification of whichever version the driver or layer intends to use.

The JSON Schema format allows for automatic validation of a given manifest file.
This enhances the ability for layer and driver developers to check that their
manifest files are correct, as well as clarifying the exact format that the
loader expects manifest files to be in.

These files will be available inside the repo for reference, but the primary
location they will be made available from is:
https://schema.khornos.org/vulkan/

Each version of the Driver and Layer Manifest formats have their own schema,
allowing verification of whichever version the driver or layer intends to use.
@ci-tester-lunarg
Copy link

CI Vulkan-Loader build queued with queue ID 20129.

@charles-lunarg charles-lunarg linked an issue Aug 8, 2023 that may be closed by this pull request
@ci-tester-lunarg
Copy link

CI Vulkan-Loader build # 2122 running.

@ci-tester-lunarg
Copy link

CI Vulkan-Loader build # 2122 passed.

@christophe-lunarg
Copy link
Contributor

Should that include the layer settings which already has a schema here https://github.com/LunarG/VulkanTools/blob/main/vkconfig_core/layers/layers_schema.json?

@charles-lunarg
Copy link
Collaborator Author

Should that include the layer settings which already has a schema here https://github.com/LunarG/VulkanTools/blob/main/vkconfig_core/layers/layers_schema.json?

So I am not against it, but it would be great if there was a way to define a 'common' base set of valid properties, so I am not having to duplicate the properties between the different manifest types (implicit, explicit, & meta).

@christophe-lunarg
Copy link
Contributor

I don't know what you mean by a way to define a 'common' base of valid properties.

My suggestion is basically to add the "features", "status", "introduction", "url", "status" element to you JSON schema. Each of these can be define in the "definitions" section and reference in each manifest types.

I think the "features" element only concern implicit and explicit layer manifests.

I can push a commit for this if you want,

@charles-lunarg
Copy link
Collaborator Author

There are separate definitions for implicit, explicit, and meta layers. To add the `"features", "introduction" fields (the "url" and "status" fields are already present) would mean copy pasting them to the implicit, explicit, and meta layer definition.

The reason I was hesitant is that this PR is adding schemas for 'the same thing' that layers_schema.json defines, which causes confusion.

Probably the best course of action is to combine both schema's, since vkconfig and the loader need common elements in the manifest (as well as having elements that are only applicable to either). That shouldn't be too hard, the common bits are easy enough to combine (since they define the same things!) and the not-common parts can be taken wholesale. What that means for layers_manifest.json, I am not sure.

@christophe-lunarg
Copy link
Contributor

I would be fine with just deleting layers_manifest.json once this is done.

`"features", "introduction" fields (the "url" and "status" fields are already present) would mean copy pasting them to the implicit, explicit, and meta layer definition.

This is confusing to me, it sounds like you imply you would have to copy the definision of each of these elements multiple times in each schema but we can define them once in schema schema and reference them for each layer manifest type.

@charles-lunarg
Copy link
Collaborator Author

This is confusing to me, it sounds like you imply you would have to copy the definision of each of these elements multiple times in each schema but we can define them once in schema schema and reference them for each layer manifest type.

I definitely am not keeping my thoughts straight. So you are definitely right about being able to have the definition once, then re-use that between the different layer types.

What I'm more annoyed with is having to copy the definitions into the schema for each version, when it should be defined in one place (common_layer_definition.json maybe) and referenced there. That would clean everything up massively, so I will pursue doing that with an update to this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Better document valid/invalid json manifests
3 participants