Remove genvk.py from Vulkan-Headers

Per comments in #449 and INTEGRATION.md, it is not needed, nor useful in
this repository.

INTEGRATION.md

@@ -29,9 +29,9 @@ If the known-good of a repository needs to be updated, all repositories of inter
 * Typically the Vulkan-Loader's known-good is updated first, but the Vulkan-ValidationLayers known-good can also be updated first.
 * The Vulkan-ValidationLayers GitHub CI currently contains a dependency on LunarG-VulkanTools. Occasionally Vulkan-Header updates require changes to be made to LunarG-VulkanTools before updating Vulkan-ValidationLayers known-good files (see the [update LunarG known-good section](https://github.com/KhronosGroup/Vulkan-Headers/wiki/Integrating-Vulkan-Header-Updates-into-Vulkan-Repositories#update-the-lunargvulkantools-and-lunargvulkansamples-known-good-files) below for more information).
 
-### 1. Checkout and pull the `master` branch
+### 1. Checkout and pull the default branch
 
-Navigate to the directory of the project of interest and checkout the `master` branch. Pull in the most recent commits.
+Navigate to the directory of the project of interest and checkout the default (usually `main`) branch. Pull in the most recent commits.
 
 ### 2. Generate new source files using `scripts/generate_source.py`
 
@@ -42,7 +42,13 @@ Using your favorite command prompt, navigate to the `scripts` directory and run
 
 #### 2-1. Propogate `genvk.py` changes
 
-All Khronos repositories and LunarG/VulkanTools contain a flavor of Vulkan-Headers's `genvk.py`. If `genvk.py` in the Vulkan-Headers repository is modified, the same changes must be made to each version of the file in each repository as part of the header update.
+All Khronos repositories, as well as LunarG/VulkanTools contain a flavor of
+[`genvk.py` from the Vulkan-Docs repository](https://github.com/KhronosGroup/Vulkan-Docs/blob/main/scripts/genvk.py).
+When the Vulkan-Docs copy is updated, it is advisable to make corresponding
+updates to each version of the file in each repository.
+However, we have removed the copy of `genvk.py` previously kept in
+Vulkan-Headers as `genvk.py` updates are very infrequent, and its presence
+here was causing confusion for some outside developers.
 
 #### 2-2. Vulkan-ValidationLayers sub-step: check for VUID inconsistencies
 
@@ -58,15 +64,15 @@ Build the project, referring to the `BUILD.md` file in the directory if necessar
 
 ### 4. Test the build
 
-  - To test the Vulkan-Loader build, run the loader tests (`run_all_tests.sh`) found in the `build/tests` directory. Information on how to build and run the tests can be found in the [Vulkan-Loader `BUILD.md`](https://github.com/KhronosGroup/Vulkan-Loader/blob/master/BUILD.md) file. **Note**: The `VK_LAYER_PATH` environment variable must be set to point at the layers found in `Vulkan-Loader/build/tests/layers` when running the loader tests.
+  - To test the Vulkan-Loader build, run the loader tests (`run_all_tests.sh`) found in the `build/tests` directory. Information on how to build and run the tests can be found in the [Vulkan-Loader `BUILD.md`](https://github.com/KhronosGroup/Vulkan-Loader/blob/main/BUILD.md) file. **Note**: The `VK_LAYER_PATH` environment variable must be set to point at the layers found in `Vulkan-Loader/build/tests/layers` when running the loader tests.
-  
+
-  - To test the Vulkan-ValidationLayers build, run the validation layers tests (`vk_layer_validation_tests`) found in the `build/tests` directory. Information on how to build and run the tests can be found in the [Vulkan-ValidationLayers `BUILD.md`](https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob/master/BUILD.md) file.
+  - To test the Vulkan-ValidationLayers build, run the validation layers tests (`vk_layer_validation_tests`) found in the `build/tests` directory. Information on how to build and run the tests can be found in the [Vulkan-ValidationLayers `BUILD.md`](https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob/main/BUILD.md) file.
-  
+
-  - To test the Vulkan-Tools build, run `vkcube` and verify `vulkaninfo` produces reasonable output. More information on how to use `vulkaninfo` can be found [here](https://github.com/KhronosGroup/Vulkan-Tools/blob/master/vulkaninfo/vulkaninfo.md).
+  - To test the Vulkan-Tools build, run `vkcube` and verify `vulkaninfo` produces reasonable output. More information on how to use `vulkaninfo` can be found [here](https://github.com/KhronosGroup/Vulkan-Tools/blob/main/vulkaninfo/vulkaninfo.md).
 
 ### 5. Update the known-good files
 
-Every repository contains a `scripts/known_good.json` file which contains information about the known good commits for each dependent repository. Some repositories require an additional known-good file to be updated for Android builds and are specified below. Known-good updates require updating only the "commit" values of the relevant JSON objects. Using an existing tag for this value is preferred over using a full commit id. If a tag does not exist, typically the most recent commit on `master` is chosen for updating the known good. **Note**: Do not change commit values for repositories not listed below unless an update is absolutely required.
+Every repository contains a `scripts/known_good.json` file which contains information about the known good commits for each dependent repository. Some repositories require an additional known-good file to be updated for Android builds and are specified below. Known-good updates require updating only the "commit" values of the relevant JSON objects. Using an existing tag for this value is preferred over using a full commit id. If a tag does not exist, typically the most recent commit on the default branch is chosen for updating the known good. **Note**: Do not change commit values for repositories not listed below unless an update is absolutely required.
 
   - Vulkan-Loader: Update requires specifying a new `Vulkan-Headers` commit in `scripts/known_good.json`
 
@@ -80,15 +86,15 @@ Commit all changes (e.g., newly generated scripts, known-good files, etc.) in a
 
 ### 7. Create a pull request in the relevant repository
 
-Verify the branch with the proposed known-good commit is rebased on the tip of `master` and create a pull request in the GitHub repository. The repository owner will assign someone with push rights and specify reviewers for the PR. Prior to approval, the proposed changes will be run through internal LunarG CI testing.
+Verify the branch with the proposed known-good commit is rebased on the tip of the default branch (`main`) and create a pull request in the GitHub repository. The repository owner will assign someone with push rights and specify reviewers for the PR. Prior to approval, the proposed changes will be run through internal LunarG CI testing.
 
-### 8. Rebase changes onto `master`
+### 8. Rebase changes onto default branch
 
-Once the known-good update PR is approved, the assignee will rebase the approved commits onto the `master` branch.
+Once the known-good update PR is approved, the assignee will rebase the approved commits onto the default branch branch.
 
 ### 9. Tag the known-good commit
 
-Once approved and rebased onto `master`, the known-good update commit must be marked with a version tag. For more information on the version tag format see the "Version Tagging Scheme" section of each repository's `BUILD.md` file
+Once approved and rebased onto the default branch, the known-good update commit must be marked with a version tag. For more information on the version tag format see the "Version Tagging Scheme" section of each repository's `BUILD.md` file
 
 ## Update the LunarG/VulkanTools and LunarG/VulkanSamples known-good files