Fix some typos and terminology

d3d/WorkGraphs.md

@@ -496,7 +496,7 @@ Input record size can be 0 - discussed under [record struct](#record-struct).  T
 
 ## Node types
 
-[Broadcasting launch nodes](#broadcasting-launch-nodes) : one input seen my many thread groups
+[Broadcasting launch nodes](#broadcasting-launch-nodes) : one input seen by many thread groups
 [Thread launch nodes](#thread-launch-nodes) : one input per thread
 [Coalescing launch nodes](#coalescing-launch-nodes) : variable inputs seen by each thread group
 
@@ -521,9 +521,9 @@ The dispatch grid size can either be part of the input record or be fixed for th
 
 The thread group is fixed in the shader.  
 
-All thread groups that are launched share the same set of input parameters.  The exception is the ususal ID system values which identify individual threads within the set.
+All thread groups that are launched share the same set of input parameters.  The exception is the usual system ID values which identify individual threads within the group.
 
-For wave packing see [Thread visiblity in wave operations](#thread-visibility-in-wave-operations).
+For wave packing see [Thread visibility in wave operations](#thread-visibility-in-wave-operations).
 
 ---
 
@@ -547,11 +547,11 @@ Of course the system will attempt to fill each thread group with the maximum dec
 
 Launched thread groups can see the full set of input available as an array.  The shader can discover how many inputs there are and is responsible for distributing work items across threads in the thread group.  If threads don't have any work to do, they can simply exit immediately.
 
-Any time a shader declares it expects some number greater than 1 as the maximum number of input records the it can handle in a thread group, it must call the input record's [Count()](#input-record-count-method) method to discover how many records its thread group actually got.
+Any time a shader declares it expects some number greater than 1 as the maximum number of input records that it can handle in a thread group, it must call the input record's [Count()](#input-record-count-method) method to discover how many records its thread group actually got.
 
 The number of records sent to any given thread group launch is implementation-defined, and not necessarily repeatable on a given implementation.  This is true independent of the method that produces the input -- i.e. whether it comes from another node or from DispatchGraph.  And it is true regardless size of input records, including 0 size records in particular.
 
-For wave packing see [Thread visiblity in wave operations](#thread-visibility-in-wave-operations).
+For wave packing see [Thread visibility in wave operations](#thread-visibility-in-wave-operations).
 
 ---
 
@@ -565,7 +565,7 @@ While a coalescing launch node can express what a thread launch node can do, it
 
 ![thread launch](images/workgraphs/ThreadLaunchNode.png)
 
-For wave packing see [Thread visiblity in wave operations](#thread-visibility-in-wave-operations).
+For wave packing see [Thread visibility in wave operations](#thread-visibility-in-wave-operations).
 
 > Thread launch nodes can be thought of somewhat like the callable shaders that are in DXR, except they do not return back to the caller.  And instead of appearing as a function call from a shader, which would be a different path to invoking threads of execution than the work graph itself, thread launch nodes are by definition part of the work graph structure.  It may still prove interesting to support DXR-style callable shaders in the future, but for now at least, thread launch nodes serve as alternative that embraces a unified model for launching work - nodes in a work graph, while still allowing applications to indicate situations when their workload does involve independent threads of work.