layers: Updated README.md and details doc

README.md was woefully out of date so this is a big improvement, but still more work to be done. May want to merge this doc with details doc in the future as they cover similar ground.

2 files changed, 24 insertions, 22 deletions

diff --git a/layers/README.md b/layers/README.md
index c87629a9..4e53ed8c 100644
--- a/layers/README.md
+++ b/layers/README.md
@@ -31,48 +31,51 @@ Note that some layers are code-generated and will therefore exist in the directo
 -include/vkLayer.h  - header file for layer code.
 
 ### Templates
-layer/Basic.cpp (name=Basic) simple example wrapping a few entrypoints. Shows layer features:
+layers/basic.cpp (name=Basic) simple example wrapping a few entrypoints. Shows layer features:
 - Multiple dispatch tables for supporting multiple GPUs.
 - Example layer extension function shown.
 - Layer extension advertised by vkGetXXXExtension().
 
-layer/Multi.cpp (name=multi1:multi2) simple example showing multiple layers per library
+layers/multi.cpp (name=multi1:multi2) simple example showing multiple layers per library
     
 (build dir)/layer/generic_layer.cpp (name=Generic) - auto generated example wrapping all VK entrypoints.
 
+### Layer Details
+For complete details of current validation layers, including all of the validation checks that they perform, please refer to the document layers/vk_validation_layer_details.md. Below is a brief overview of each layer.
+
 ### Print API Calls and Parameter Values
-(build dir)/layer/api_dump.cpp (name=APIDump) - print out API calls along with parameter values
+(build dir)/layers/api_dump.cpp (name=APIDump) - print out API calls along with parameter values
 
 ### Print Object Stats
-(build dir)/layer/object_track.cpp (name=ObjectTracker) - Track object CREATE/USE/DESTROY stats. Individually track objects by category. VkObjectType enum defined in vulkan.h.
+(build dir)/layers/object_track.cpp (name=ObjectTracker) - Track object creation, use, and destruction. As objects are created, they're stored in a map. As objects are used, the layer verifies they exist in the map, flagging errors for unknown objects. As objects are destroyed, they're removed from the map. At vkDestroyDevice() and vkDestroyInstance() times, if any objects have not been destroyed, they are reported as leaked objects. If a Dbg callback function is registered, this layer will use callback function(s) for reporting, otherwise uses stdout.
 
-### Report Draw State
-layer/draw\_state.cpp (name=DrawState) - DrawState reports the Descriptor Set, Pipeline State, and dynamic state at each Draw call. DrawState layer performs a number of validation checks on this state. Of primary interest is making sure that the resources bound to Descriptor Sets correctly align with the layout specified for the Set.
+### Validate Draw State
+layers/draw\_state.cpp (name=DrawState) - DrawState tracks the Descriptor Set, Pipeline State, and dynamic state performing some point validation as states are created and used, and further validation at each Draw call. Of primary interest is making sure that the resources bound to Descriptor Sets correctly align with the layout specified for the Set. If a Dbg callback function is registered, this layer will use callback function(s) for reporting, otherwise uses stdout. 
 
 ### Track GPU Memory
-layer/mem\_tracker.cpp (name=MemTracker) - MemTracker functions mostly as a validation layer, attempting to ensure that memory objects are managed correctly by the application.  These memory objects are bound to pipelines, objects, and command buffers, and then submitted to the GPU for work.  As an example, the layer validates that the correct memory objects have been bound, and that they are specified correctly when the command buffers are submitted.  Also, that only existing memory objects are referenced, and that any destroyed memory objects are not referenced.  Another type of validation done is that before any memory objects are reused or destroyed, the layer ensures that the application has confirmed that they are no longer in use, and that they have been properly unbound before destruction.
-
-### Device Limits
-<build dir>/layer/device_limits.cpp (name=DeviceLimits) - Check that parameters used do not exceed device limits.
+layers/mem\_tracker.cpp (name=MemTracker) - The MemTracker layer tracks memory objects and references and validates that they are managed correctly by the application.  This includes tracking object bindings, memory hazards, and memory object lifetimes. MemTracker validates several other hazard-related issues related to command buffers, fences, and memory mapping. If a Dbg callback function is registered, this layer will use callback function(s) for reporting, otherwise uses stdout.
 
 ### Check parameters
-<build dir>/layer/param_checker.cpp (name=ParamChecker) - Check the input parameters to API calls for validity. Currently this only checks ENUM params directly passed to API calls and ENUMs embedded in struct params.
+layers/param_checker.cpp (name=ParamChecker) - Check the input parameters to API calls for validity. If a Dbg callback function is registered, this layer will use callback function(s) for reporting, otherwise uses stdout.
 
-### Image Checker
-<build dir>/layer/image.cpp (name=Image) - Verify parameters on Vulkan calls that use VkImage.
+### Image parameters
+layers/image.cpp (name=Image) - The Image layer is intended to validate image parameters, formats, and correct use. Images are a significant enough area that they were given a separate layer. If a Dbg callback function is registered, this layer will use callback function(s) for reporting, otherwise uses stdout.
 
 ### Check threading
-<build dir>/layer/threading.cpp (name=Threading) - Check multithreading of API calls for validity. Currently this checks that only one thread at a time uses an object in free-threaded API calls.
+<build dir>/layers/threading.cpp (name=Threading) - Check multithreading of API calls for validity. Currently this checks that only one thread at a time uses an object in free-threaded API calls. If a Dbg callback function is registered, this layer will use callback function(s) for reporting, otherwise uses stdout.
 
 ### Swapchain
 <build dir>/layer/swapchain.cpp (name=Swapchain) - Check that WSI extensions are being used correctly.
 
-### Shader Checker
-<build dir>/layer/shader_checker.cpp (name=ShaderChecker) - Verify SPIR-V shader layout matches descriptor set.
+### Validate Shaders
+<build dir>/layers/shader_checker.cpp (name=ShaderChecker) - The ShaderChecker layer inspects the SPIR-V shader images and fixed function pipeline stages at PSO creation time. It flags errors when inconsistencies are found across interfaces between shader stages. The exact behavior of the checks depends on the pair of pipeline stages involved. If a Dbg callback function is registered, this layer will use callback function(s) for reporting, otherwise uses stdout.
+
+### Device Limitations
+layers/device_limits.cpp (name=DeviceLimits) - This layer is intended to capture underlying device features and limitations and then flag errors if an app makes requests for unsupported features or exceeding limitations. This layer is a work in progress and currently only flags some high-level errors without flagging errors on specific feature and limitation. If a Dbg callback function is registered, this layer will use callback function(s) for reporting, otherwise uses stdout.
 
 ## Using Layers
 
-1. Build VK loader  and i965 icd driver using normal steps (cmake and make)
+1. Build VK loader and i965 icd driver using normal steps (cmake and make)
 2. Place libVKLayer<name>.so in the same directory as your VK test or app:
 
     cp build/layer/libVKLayerBasic.so build/layer/libVKLayerGeneric.so build/tests
@@ -90,10 +93,10 @@ vkCreateDevice and/or vkCreateInstance or environment variables.
 ## Tips for writing new layers
 
 1. Must implement vkGetInstanceProcAddr() (aka GIPA) and vkGetDeviceProcAddr() (aka GDPA);
-2. Must have a local dispatch table to call next layer (see vkLayer.h);
+2. Must have a local dispatch table to call next layer (see vk_layer.h);
 3. Must have a layer manifest file for each Layer library for Loader to find layer properties (see loader/README.md)
-4. next layers GXPA can be found in the wrapped instance or device object;
-5. Loader calls a layer's GXPA first  so initialization should occur here;
+4. Next layers GXPA can be found in the wrapped instance or device object;
+5. Loader calls a layer's GXPA first so initialization should occur here;
 6. all entrypoints can be wrapped but only will be called after layer is activated
     via the first vkCreatDevice or vkCreateInstance;
 7. entrypoint names can be any name as specified by the layers vkGetXXXXXProcAddr
@@ -112,4 +115,3 @@ vkCreateDevice and/or vkCreateInstance or environment variables.
 - multi.cpp Layer needs rewrite to allow manifest file to specify multiple layers
 - multi1  and multi2 layers from multi.cpp: only multi1 layer working
 
-
diff --git a/layers/vk_validation_layer_details.md b/layers/vk_validation_layer_details.md
index 80081328..774ea626 100644
--- a/layers/vk_validation_layer_details.md
+++ b/layers/vk_validation_layer_details.md
@@ -130,7 +130,7 @@ Additional work to be done
 
 ### MemTracker Overview
 
-The MemTracker layer tracks memory objects and references and validates that they are managed correctly by the application.  This includes tracking object bindings, memory hazards, and memory object lifetimes.. MemTracker validates several other hazard-related issues related to command buffers, fences, and memory mapping.
+The MemTracker layer tracks memory objects and references and validates that they are managed correctly by the application.  This includes tracking object bindings, memory hazards, and memory object lifetimes. MemTracker validates several other hazard-related issues related to command buffers, fences, and memory mapping.
 
 ### MemTracker Details Table