corechecks: Add setting to enable fine-grained locking #3646
Conversation
|
CI Vulkan-ValidationLayers build queued with queue ID 9085. |
|
CI Vulkan-ValidationLayers build # 5808 running. |
jeremyg-lunarg
force-pushed
the
jeremyg-lock-setting
branch
from
8de2f06 to
b19bf03
Compare
|
CI Vulkan-ValidationLayers build queued with queue ID 9095. |
|
@christophe-lunarg Ping. We will want these settings exposed by vkconfig. |
jeremyg-lunarg
requested review from
christophe-lunarg,
ncesario-lunarg and
mark-lunarg
|
CI Vulkan-ValidationLayers build # 5809 running. |
|
CI Vulkan-ValidationLayers build # 5809 failed. |
There was a problem hiding this comment.
The manifest file is not correct (default is a boolean), here is a fix with some clean up:
"settings": [
{
"key": "fine_grained_locking",
"env": "VK_LAYER_FINE_GRAINED_LOCKING",
"label": "Fine Grained Locking",
"description": "Enable fine grained locking for Core Validation, which should improve performance in multithreaded applications. This is an experimental feature which may cause stability problems or incorrect errors to be reported.",
"status": "BETA",
"type": "BOOL",
"default": false,
"platforms": [ "WINDOWS", "LINUX", "MACOS", "ANDROID" ]
},
There is no "experimental" status for settings only "alpha", "beta", "stable" and "deprecated".
I would add this setting first in the list for where it will be exposed in Vulkan Configurator UI
I only made a little change in Vulkan Configurator to display the status next to the label :
jeremyg-lunarg
force-pushed
the
jeremyg-lock-setting
branch
from
b19bf03 to
8a6fd5e
Compare
|
CI Vulkan-ValidationLayers build queued with queue ID 9837. |
jeremyg-lunarg
force-pushed
the
jeremyg-lock-setting
branch
from
8a6fd5e to
5bf28fd
Compare
|
CI Vulkan-ValidationLayers build queued with queue ID 9852. |
| @@ -563,6 +563,16 @@ | |||
| } | |||
| ], | |||
| "default": [] | |||
| }, | |||
| { | |||
There was a problem hiding this comment.
@christophe-lunarg , I think I pulled in your fix. Not sure if I got it right though.
|
CI Vulkan-ValidationLayers build # 5828 running. |
|
CI Vulkan-ValidationLayers build # 5828 passed. |
jeremyg-lunarg
force-pushed
the
jeremyg-lock-setting
branch
from
5bf28fd to
c199825
Compare
|
CI Vulkan-ValidationLayers build queued with queue ID 16739. |
|
CI Vulkan-ValidationLayers build # 5952 running. |
|
CI Vulkan-ValidationLayers build # 5952 passed. |
jeremyg-lunarg
force-pushed
the
jeremyg-lock-setting
branch
from
c199825 to
4047dc7
Compare
|
CI Vulkan-ValidationLayers build queued with queue ID 18081. |
|
CI Vulkan-ValidationLayers build # 5961 running. |
|
CI Vulkan-ValidationLayers build # 5961 passed. |
Add a setting to make calls to ValidationObject::ReadLock() and WriteLock() be no-ops, because locking in other parts of the code has made these global locks unnecessary. Currently this only affects Core Validation, but eventually it should also change the behavior of Best Practices and Synchronization Validation. The setting defaults to off for now and there is logging when fine grained locking is enabled, since this is an experimental feature which make cause stability problems or incorrect errors to be reported. Once this stabilizes, the setting will default to on and the log message will report when it is turned off, because that will be slow.
jeremyg-lunarg
force-pushed
the
jeremyg-lock-setting
branch
from
4047dc7 to
71f9045
Compare
|
CI Vulkan-ValidationLayers build queued with queue ID 19506. |
|
CI Vulkan-ValidationLayers build # 5980 running. |
WIP! This is one of the last changes I intend to merge for the locking improvements, but it needs sooner review because it involves user-visible names that need to end up in documentation in several different places.
Add a setting to make calls to ValidationObject::ReadLock() and
WriteLock() be no-ops, because locking in other parts of the code
has made these global locks unnecessary.
Currently this only affects Core Validation, but eventually it should
also change the behavior of Best Practices and Synchronization
Validation.
The setting defaults to off for now and there is logging when fine grained
locking is enabled, since this is an experimental feature which
make cause stability problems or incorrect errors to be reported.
Once this stabilizes, the setting will default to on and the log message
will report when it is turned off, because that will be slow.