openharmony/third_party_vulkan-loader
1
0
Fork 0
mirror of https://gitee.com/openharmony/third_party_vulkan-loader synced 2024-11-23 07:10:23 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

loader: change so LoaderAndLayerInterface document is the sole document

Browse Source
This commit is contained in:
Jon Ashburn 2016-02-14 21:00:39 -07:00
parent b4a1203d60
commit 7e9dd6fbf0
3 changed files with 4 additions and 628 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

275
loader/LinuxICDs.txt
View File

@ -1,275 +0,0 @@
This is a specification for how the Vulkan loader should identify Vulkan
installable client drivers (ICDs) and layers on Linux systems. This is
designed for production installation of Vulkan ICDs and layers. The design is
shown first for ICDs, and then the variation for layers will be discussed.
1. Installable Client Drivers:
1.1. Properly-Installed ICDs
In order to find properly-installed ICDs, the Vulkan loader will scan the files
in the following Linux directories:
/usr/share/vulkan/icd.d
/etc/vulkan/icd.d
These directories will contain text information files (a.k.a. "manifest
files"), that use a JSON format (NOTE: The JSON in this version of the
specification is for illustration purposes, and isn't completely valid yet).
The Vulkan loader will open each info file to obtain the name or pathname of an
ICD shared library (".so") file. For example:
{
"file_format_version": "1.0.0",
"ICD": {
"library_path": "path to ICD library",
"api_version": "1.0.3"
}
}
The "library_path" specifies either a filename, a relative pathname, or a full
pathname to an ICD shared library file. If the ICD is specified via a
filename, the loader will attempt to open that file as a shared object using
dlopen(), and the file must be in a directory that dlopen is configured to look
in (Note: various distributions are configured differently). A distribution is
free to create Vulkan-specific system directories (e.g. ".../vulkan/icd"), but
is not required to do so. If the ICD is specified via a relative pathname, it
is relative to the path of the info file. Relative pathnames are those that do
not start with, but do contain at least one directory separator (i.e. the '/'
character). For example, "lib/vendora.so" and "./vendora.so" are examples of
relative pathnames.
The "file_format_version" provides a major.minor.patch version number in case
the format of the text information file changes in the future. If the same ICD
shared library supports multiple, incompatible versions of text info file
format versions, it must have multiple text info files (all of which may point
to the same shared library).
The “api_version” specifies the major.minor.patch version number of the Vulkan
API that the shared library (referenced by "library_path") was built with.
The "/usr/share/vulkan/icd.d" directory is for ICDs that are installed from
Linux-distribution-provided packages. The "/etc/vulkan/icd.d" directory is for
ICDs that are installed from non-Linux-distribution-provided packages.
There are no rules about the name of the text files (except the .json suffix).
There are no rules about the name of the ICD shared library files. For
example, if the "/usr/share/vulkan/icd.d" directory contain the following
files, with the specified contents:
Text File Name Text File Contents
--------------------------------------------------------------------------
vk_vendora.json { "ICD": { "library_path": "vendora.so" }}
vendorb_vk.json { "ICD": { "library_path": "vendorb_vulkan_icd.so" }}
vendorc_icd.json { "ICD": { "library_path": "/usr/lib/VENDORC/icd.so" }}
then the loader will open the three files mentioned in the "Text File Contents"
column, and then try to load and use the three shared libraries mentioned
indicated by the ICD.library_path value.
1.2. Using Pre-Production ICDs
IHV developers (and sometimes other developers) need to use special,
pre-production ICDs. In some cases, a pre-production ICD may be in an
installable package. In other cases, a pre-production ICD may simply be a
shared library in the developer's build tree. In this latter case, we want to
allow developers to point to such an ICD without modifying the
properly-installed ICD(s) on their system.
This need is met with the use of the "VK_ICD_FILENAMES" environment variable,
which will override the mechanism used for finding properly-installed ICDs. In
other words, only the ICDs listed in "VK_ICD_FILENAMES" will be used.
The "VK_ICD_FILENAMES" environment variable is a colon-separated list of ICD
text information files, containing the following:
- A filename (e.g. "libvkicd.json") in the "/usr/share/vulkan/icd.d" or
"/etc/vulkan/icd.d" system directories
- A full pathname (e.g. "/my_build/my_icd.json")
Typically, "VK_ICD_FILENAMES" will only contain a full pathname to one info
file for a developer-built ICD. A colon is only used if more than one ICD is
listed.
For example, if a developer wants to refer to one ICD that they built, they
could set the "VK_ICD_FILENAMES" environment variable to:
/my_build/my_icd.json
If a developer wants to refer to two ICDs, one of which is a properly-installed
ICD, they can use the name of the text file in the system directory:
vendorc_vulkan.json:/my_build/my_icd.json
Notice the colon between "vendorc_vulkan.json" and "/my_build/my_icd.json".
NOTE: this environment variable will be ignored for suid programs.
2. Layers:
2.1. Properly-Installed Layers
In order to find properly-installed layers, the Vulkan loader will use a
similar mechanism as used for ICDs. Text information files, that use a JSON
format, are read in order to identify the names and attributes of layers and
their extensions. The use of text info files allows the loader to avoid
loading any shared library files when the application does not query nor
request any extensions. Layers and extensions have additional complexity, and
so their info files contain more information than ICD info files. For example,
a layer shared library file may contain multiple layers/extensions (perhaps
even an ICD).
The Vulkan loader will scan the files in the following Linux directories:
/usr/share/vulkan/explicit_layer.d
/usr/share/vulkan/implicit_layer.d
/etc/vulkan/explicit_layer.d
/etc/vulkan/implicit_layer.d
Explicit layers are those which are enabled by an application (e.g. with the
vkCreateInstance function), or by an environment variable (see below).
Implicit layers are those which are enabled by their existence. For example,
certain application environments (e.g. Steam or an automotive infotainment
system) may have layers which they always want enabled for all applications
that they start. Other implicit layers may be for all applications started
on a given system (e.g. layers that overlay frames-per-second). Implicit
layers are enabled automatically, whereas explicit
layers must be enabled explicitly. What distinguishes a layer as implicit or
explicit is by which directory its layer information file exists in.
The "/usr/share/vulkan/*_layer.d" directories are for ICDs that are installed
from Linux-distribution-provided packages. The "/etc/vulkan/*_layer.d"
directories are for ICDs that are installed from
non-Linux-distribution-provided packages.
The information file is in the JSON format and contains the following
information:
- (required) "file_format_version" – same as for ICDs, except that the format
version can vary independently for ICDs and layers.
- (required) "name" - layer name
- (required) "type" - which layer chains should the layer be activated on.
Allowable values are "INSTANCE", "DEVICE", "GLOBAL". Global means activate
on both device and instance chains.
- (required) "library_path" - filename / full path / relative path to the text
file
- (required) "api_version" – same as for ICDs.
- (required) "implementation_version" – layer version, a single number increasing with backward compatible changes.
- (required) "description" – informative decription of the layer.
- (optional) "device_extensions" or "instance_extensions" - array of extension information as follows
- (optional) extension "name" - Vulkan registered name
- (optional) extension "spec_version" - extension specification version, a single number, increasing with backward compatible changes.
- (optional) extension "entrypoints" - array of device extension entrypoints; not used for instance extensions
- (sometimes required) "functions" - mapping list of function entry points. If
multiple layers exist within the same shared library (or if a layer is in the
same shared library as an ICD), this must be specified to allow each layer to
have its own vkGet*ProcAddr entrypoints that can be found by the loader. At
this time, only the following two functions are required:
- "vkGetInstanceProcAddr" name
- "vkGetDeviceProcAddr" name
- (optional for implicit layers) "enable_environment" requirement(s) -
environment variable and value required to enable an implicit layer. This
environment variable (which should vary with each "version" of the layer, as
in "ENABLE_LAYER_FOO_1") must be set to the given value or else the
implicit layer is not loaded. This is for application environments
(e.g. Steam) which want to enable a layer(s) only for applications that they
launch, and allows for applications run outside of an application environment
to not get that implicit layer(s).
- (required for implicit layers) "disable_environment" requirement(s) -
environment variable and value required to disable an implicit layer. Note:
in rare cases of an application not working with an implicit layer, the
application can set this environment variable (before calling Vulkan
functions) in order to "blacklist" the layer. This environment variable
(which should vary with each "version" of the layer, as in
"DISABLE_LAYER_FOO_1") must be set (not particularly to any value). If
both the "enable_environment" and "disable_environment" variables are set,
the implicit layer is disabled.
For example:
{
"file_format_version" : "1.0.0",
"layer": {
"name": "OverlayLayer",
"type": "DEVICE",
"library_path": "libvkOverlayLayer.so",
"api_version" : "1.0.3",
"implementation_version" : "2",
"description" : "LunarG HUD layer",
"functions": {
"vkGetInstanceProcAddr": "Overlaylayer_GetInstanceProcAddr",
"vkGetDeviceProcAddr": "OverlayLayer_GetDeviceProcAddr"
},
"instance_extensions": [
{
"name": "VK_LUNARG_DEBUG_REPORT",
"spec_version": "1"
},
{
"name": "VK_VENDOR_DEBUG_X",
"spec_version": "3"
}
],
"device_extensions": [
{
"name": "VK_LUNARG_DEBUG_MARKER",
"spec_version": "1",
"entrypoints": ["vkCmdDbgMarkerBegin", "vkCmdDbgMarkerEnd"]
}
],
"disable_environment": {
"DISABLE_LAYER_OVERLAY_1": ""
}
}
}
The "library_path" specifies either a filename, a relative pathname, or a full
pathname to a layer shared library (".so") file, which the loader will attempt
to load using dlopen(). If the layer is specified via a filename, the loader
will attempt to open that file as a shared object using dlopen(), and the file
must be in a directory that dlopen is configured to look in (Note: various
distributions are configured differently). A distribution is free to create
Vulkan-specific system directories (e.g. ".../vulkan/layers"), but is not
required to do so. If the layer is specified via a relative pathname, it is
relative to the path of the info file (e.g. for cases when an application
provides a layer that is in the same directory hierarchy as the rest of the
application files).
There are no rules about the name of the text files (except the .json suffix).
There are no rules about the name of the layer shared library files.
2.2. Using Pre-Production Layers
As with ICDs, developers may need to use special, pre-production layers,
without modifying the properly-installed layers.
This need is met with the use of the "VK_LAYER_PATH" environment variable,
which will override the mechanism using for finding properly-installed layers.
Because many layers may exist on a system, this environment variable is a
colon-separated list of directories that contain layer info files. Only the
directories listed in "VK_LAYER_PATH" will be scanned for info files. Each
colon-separated entry is:
- The full pathname of a directory containing layer info files
In addition to overriding the mechanism for finding layers, the following
environment variables are used to select one or more layers/extensions
(respectively) to explicitly enable:
- "VK_INSTANCE_LAYERS" for instance/global layers/extensions, enabled at
vkCreateInstance time
- "VK_DEVICE_LAYERS" for device layers/extensions, enabled at vkCreateDevice
time
These are colon-separated lists of extension names, as listed in the "name"
field of the info file. The loader will load all layers/extensions that match
the given extension name(s), ignoring the "version" fields.
NOTE: these environment variables will be ignored for suid programs.

91
loader/README.md
View File

@ -1,91 +1,8 @@
# Loader Description
# Loader Specification and Interfaces
See LoaderAndLayerInterface.md.
## Overview
The Loader implements the main VK library (e.g. "vulkan-1.dll" on Windows and
"libvulkan.so" on Linux). It handles layer management and driver management. The
loader fully supports multi-gpu operation. As part of this, it dispatches API
calls to the correct driver, and to the correct layers, based on the GPU object
selected by the application.
# Building
Builds for Linux and Windows are supported via CMake. See top level BUILD.md file.
The loader's driver management includes finding driver libraries and loading
them. When a driver is initialized, the loader sets up its dispatch tables,
using a very light-weight "trampoline" mechanism. To do so, it reserves space
for a pointer in API objects (see below for more information about this).
The loader's layer management includes finding layer libraries and activating
them as requested. The loader correctly sets up each activated layer, and its
own dispatch tables in order to support all activated layers. Each active
layer can intercept a subset of the full API entrypoints. A layer which
doesn't intercept a given entrypoint will be skipped for that entrypoint. The
loader supports layers that operate on multiple GPUs.
## ICD discovery
See file LinuxICDs.txt and WindowsICDs.txt for description of how the loader
finds ICD driver libraries.
## Interface to driver (ICD)
Currently two supported methods of the loader finding ICD entry points are supported:
1) Recommended
- vk_icdGetInstanceProcAddr exported in the ICD library and returns valid function pointers for all the VK API entrypoints
both core entry points and any instance or device extension entrypoints
- ICD supports NULL instance handle for the global Vulkan entrypoints when called from vk_icdGetInstanceProcAddr
- all other Vulkan entrypoints either NOT exported from the ICD library or else will not use the official Vulkan function names
if they are exported. (NOTE: this requirement is for ICD libraries that include other functionality (such as OpenGL library)
and thus could be loaded prior to when the Vulkan loader library is loaded by the app. Thus the ICD library exported Vulkan symbols must not
clash with the loader's exported Vulkan symbols).
2) Deprecated
- vkGetInstanceProcAddr exported in the ICD library and returns valid function pointers for all the VK API entrypoints.
- vkCreateInstance exported in the ICD library
- vkEnumerateInstanceExtensionProperties exported in the ICD library
- WSI surface extensions (vk_KHR_*surface) handling:
1. Loader handles the vkCreate*SurfaceKHR() and vkDestroySurfaceKHR() functions including creating/destroying the VkSurfaceKHR object
2. VkSurfaceKHR objects have the underlying structure (VKIcdSurface*) as defined in include/vulkan/vk_icd.h
3. ICDs can cast any VkSurfaceKHR object to a pointer to the appropriate VKIcdSurface* structure
4. VkIcdSurface* structures include VkIcdSurfaceWin32, VkIcdSurfaceXcb, VkIcdSurfaceXlib, VkIcdSurfaceMir, and VkIcdSurfaceWayland
- all objects created by an ICD can be cast to (VK\_LAYER\_DISPATCH\_TABLE \*\*)
where the loader will replace the first entry with a pointer to the dispatch table which is
owned by the loader. This implies three things for ICD drivers:
1. The ICD must return a pointer for the opaque object handle
2. This pointer points to a regular C structure with the first entry being a pointer.
Note: for any C++ ICD's that implement VK objects directly as C++ classes.
The C++ compiler may put a vtable at offset zero, if your class is virtual.
In this case use a regular C structure (see below).
3. The reservedForLoader.loaderMagic member must be initialized with ICD\_LOADER\_MAGIC, as follows:
```
#include "vkIcd.h"
struct {
VK_LOADER_DATA reservedForLoader; // Reserve space for pointer to loader's dispatch table
myObjectClass myObj; // Your driver's C++ class
} vkObj;
vkObj alloc_icd_obj()
{
vkObj *newObj = alloc_obj();
...
// Initialize pointer to loader's dispatch table with ICD_LOADER_MAGIC
set_loader_magic_value(newObj);
...
return newObj;
}
```
Additional Notes:
- loader will filter out extensions requested in vkCreateInstance and vkCreateDevice
before calling into the ICD;
Filtering will be of extensions advertised by entities (eg layers) different from the ICD in question
- loader will not call ICD for vkEnumerate*LayerProperties() as layer properties are obtained from
the layer libraries and ICD files.
- loader will not call ICD for vkEnumerate*ExtensionProperties(pLayerName != NULL)
- The ICD may or may not implement a dispatch table.
- ICD entrypoints can be named anything including the offcial vk name such as vkCreateDevice(). However, beware of interposing by dynamic OS library loaders if the offical names are used. On Linux, if offical names are used, the ICD library must be linked with -Bsymbolic.
## Layer library discovery
See file LinuxICDs.txt and WindowsICDs.txt for description of how the loader
finds layer libraries.
## Interface to layer libraries
TBD

266
loader/WindowsICDs.txt
View File

@ -1,266 +0,0 @@
This is a specification for how the Vulkan loader should identify Vulkan
installable client drivers (ICDs) on MS Windows. This is designed for
production installation of Vulkan ICDs and layers. The design is shown first
for ICDs, and then the variation for layers will be discussed.
1. Installable Client Drivers:
1.1. Properly-Installed ICDs
In order to find properly-installed ICDs, the Vulkan loader will scan the
values in the following Windows registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\Vulkan\Drivers
For each value in this key which has DWORD data set to 0, the loader opens the
JSON format text information file (a.k.a. "manifest file") specified by the
name of the value. Each name must be a full pathname to the text info file.
The Vulkan loader will open each info file to obtain the name or pathname of
an ICD shared library (".dll") file. For example:
{
"file_format_version": "1.0.0",
"ICD": {
"library_path": "path to ICD library",
"api_version": "1.0.3"
}
}
The "library_path" specifies either a filename, a relative pathname, or a full
pathname to an ICD shared library file, which the loader will attempt to load
using LoadLibrary(). If the ICD is specified via a filename, the shared
library lives in the system's DLL search path (e.g. in the
"C:\\Windows\\System32" folder). If the ICD is specified via a relative
pathname, it is relative to the path of the info file. Relative pathnames are
those that do not start with a drive specifier (e.g. "C:"), nor with a
directory separator (i.e. the '\' character), but do contain at least one
directory separator.
The "file_format_version" specifies a major.minor.patch version number in case
the format of the text information file changes in the future. If the same ICD
shared library supports multiple, incompatible versions of text info file
format versions, it must have multiple text info files (all of which may point
to the same shared library).
The “api_version” specifies the major.minor.patch version number of the Vulkan
API that the shared library (referenced by "library_path") was built with.
There are no rules about the name of the text information files (except the
.json suffix). There are no rules about the name of the ICD shared library
files. For example, if the registry contains the following values:
[HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\Vulkan\Drivers]
"c:\\vendor a\\vk_vendora.json"=dword:00000000
"c:\\windows\\system32\\vendorb_vk.json"=dword:00000000
"c:\\windows\\system32\\vendorc_icd.json"=dword:00000000
then the loader will open the following text information files, with the
specified contents:
Text File Name Text File Contents
--------------------------------------------------------------------------
vk_vendora.json { "ICD": { "library_path": "C:\\VENDORA\\vk_vendora.dll" }}
vendorb_vk.json { "ICD": { "library_path": "vendorb_vk.dll" }}
vendorc_icd.json { "ICD": { "library_path": "vedorc_icd.dll" }}
then the loader will open the three files mentioned in the "Text File Contents"
column, and then try to load and use the three shared libraries mentioned
indicated by the ICD.library_path value.
1.2. Using Pre-Production ICDs
IHV developers (and sometimes other developers) need to use special,
pre-production ICDs. In some cases, a pre-production ICD may be in an
installable package. In other cases, a pre-production ICD may simply be a
shared library in the developer's build tree. In this latter case, we want to
allow developers to point to such an ICD without modifying the
properly-installed ICD(s) on their system.
This need is met with the use of the "VK_ICD_FILENAMES" environment variable,
which will override the mechanism used for finding properly-installed ICDs. In
other words, only the ICDs listed in "VK_ICD_FILENAMES" will be used.
The "VK_ICD_FILENAMES" environment variable is a semi-colon-separated list of
ICD text information files, containing the following:
- A full pathname (e.g. "C:\\my_build\\my_icd.json")
Typically, "VK_ICD_FILENAMES" will only contain a full pathname to one info
file for a developer-built ICD. A semi-colon is only used if more than one ICD
is listed.
For example, if a developer wants to refer to one ICD that they built, they
could set the "VK_ICD_FILENAMES" environment variable to:
C:\\my_build\\my_icd.json
If a developer wants to refer to two ICDs, one of which is a properly-installed
ICD, they can use the full pathname of the text file:
C:\\Windows\\System32\\vendorc_icd.json;C:\\my_build\\my_icd.json
Notice the semi-colon between "C:\\Windows\\System32\\vendorc_icd.json" and
"C:\\my_build\\my_icd.json".
2. Layers:
2.1. Properly-Installed Layers
In order to find properly-installed layers, the Vulkan loader will use a
similar mechanism as used for ICDs. Text information files, that use a JSON
format, are read in order to identify the names and attributes of layers and
their extensions. The use of text info files allows the loader to avoid
loading any shared library files when the application does not query nor
request any extensions. Layers and extensions have additional complexity, and
so their info files contain more information than ICD info files. For example,
a layer shared library file may contain multiple layers/extensions (perhaps
even an ICD).
In order to find properly-installed layers, the Vulkan loader will scan the
values in the following Windows registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\Vulkan\ExplicitLayers
HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\Vulkan\ImplicitLayers
Explicit layers are those which are enabled by an application (e.g. with the
vkCreateInstance function), or by an environment variable (see below).
Implicit layers are those which are enabled by their existence. For example,
certain application environments (e.g. Steam or an automotive infotainment
system) may have layers which they always want enabled for all applications
that they start. Other implicit layers may be for all applications started
on a given system (e.g. layers that overlay frames-per-second). Implicit
layers are enabled automatically, whereas explicit
layers must be enabled explicitly. What distinguishes a layer as implicit or
explicit is by which registry key its layer information file is referenced by.
For each value in these keys which has DWORD data set to 0, the loader opens
the JSON format text information file (a.k.a. "manifest file") specified by the
name of the value. Each name must be a full pathname to the text info file.
The Vulkan loader will open each info file to obtain information about the
layer, including the name or pathname of a shared library (".dll") file.
The information file is in the JSON format and contains the following
information:
- (required) "file_format_version" - same as for ICDs, except that the format
version can vary independently for ICDs and layers.
- (required) "name" - layer name
- (required) "type" - which layer chains should the layer be activated on.
Allowable values are "INSTANCE", "DEVICE", "GLOBAL". Global means activate
on both device and instance chains.
- (required) "library_path" - filename / full path / relative path to the text
file
- (required) "api_version" - same as for ICDs.
- (required) "implementation_version" - layer version, a single number increasing with backward compatible changes.
- (required) "description" - informative decription of the layer.
- (optional) "device_extensions" or "instance_extensions" - array of extension information as follows
- (optional) extension "name" - Vulkan registered name
- (optional) extension "spec_version" - extension specification version, a single number, increasing with backward compatible changes.
- (optional) extension "entrypoints" - array of device extension entrypoints; not used for instance extensions
- (sometimes required) "functions" - mapping list of function entry points. If
multiple layers exist within the same shared library (or if a layer is in the
same shared library as an ICD), this must be specified to allow each layer to
have its own vkGet*ProcAddr entrypoints that can be found by the loader. At
this time, only the following two functions are required:
- "vkGetInstanceProcAddr" name
- "vkGetDeviceProcAddr" name
- (optional for implicit layers) "enable_environment" requirement(s) -
environment variable and value required to enable an implicit layer. This
environment variable (which should vary with each "version" of the layer, as
in "ENABLE_LAYER_FOO_1") must be set to the given value or else the
implicit layer is not loaded. This is for application environments
(e.g. Steam) which want to enable a layer(s) only for applications that they
launch, and allows for applications run outside of an application environment
to not get that implicit layer(s).
- (required for implicit layers) "disable_environment" requirement(s) -
environment variable and value required to disable an implicit layer. Note:
in rare cases of an application not working with an implicit layer, the
application can set this environment variable (before calling Vulkan
functions) in order to "blacklist" the layer. This environment variable
(which should vary with each "version" of the layer, as in
"DISABLE_LAYER_FOO_1") must be set (not particularly to any value). If
both the "enable_environment" and "disable_environment" variables are set,
the implicit layer is disabled.
For example:
{
"file_format_version" : "1.0.0",
"layer": {
"name": "OverlayLayer",
"type": "DEVICE",
"library_path": "vkOverlayLayer.dll",
"api_version" : "1.0.3",
"implementation_version" : "2",
"description" : "LunarG HUD layer",
"functions": {
"vkGetInstanceProcAddr": "OverlayLayer_GetInstanceProcAddr",
"vkGetDeviceProcAddr": "OverlayLayer_GetDeviceProcAddr"
},
instance_extensions": [
{
"name": "VK_LUNARG_DEBUG_REPORT",
"spec_version": "1"
},
{
"name": "VK_VENDOR_DEBUG_X",
"spec_version": "3"
}
],
device_extensions": [
{
"name": "VK_LUNARG_DEBUG_MARKER",
"spec_version": "1",
"entrypoints": ["vkCmdDbgMarkerBegin", "vkCmdDbgMarkerEnd"]
}
],
"disable_environment": {
"DISABLE_LAYER_OVERLAY_1": ""
}
}
}
The "library_path" specifies either a filename, a relative pathname, or a full
pathname to a layer shared library (".dll") file, which the loader will attempt
to load using LoadLibrary(). If the layer is specified via a relative
pathname, it is relative to the path of the info file (e.g. for cases when an
application provides a layer that is in the same folder hierarchy as the rest
of the application files). If the layer is specified via a filename, the
shared library lives in the system's DLL search path (e.g. in the
"C:\\Windows\\System32" folder).
There are no rules about the name of the text files (except the .json suffix).
There are no rules about the name of the layer shared library files.
2.2. Using Pre-Production Layers
As with ICDs, developers may need to use special, pre-production layers,
without modifying the properly-installed layers.
This need is met with the use of the "VK_LAYER_PATH" environment variable,
which will override the mechanism using for finding properly-installed layers.
Because many layers may exist on a system, this environment variable is a
semi-colon-separated list of folders that contain layer info files. Only the
folder listed in "VK_LAYER_PATH" will be scanned for info files. Each
semi-colon-separated entry is:
- The full pathname of a folder containing layer info files
In addition to overriding the mechanism for finding layers, the following
environment variables are used to select one or more layers/extensions
(respectively) to explicitly enable:
- "VK_INSTANCE_LAYERS" for instance/global layers/extensions, enabled at
vkCreateInstance time
- "VK_DEVICE_LAYERS" for device layers/extensions, enabled at vkCreateDevice
time
These are semi-colon-separated lists of extension names, as listed in the
"name" field of the info file. The loader will load all layers/extensions that
match the given extension name(s), ignoring the "version" fields.