Add more detail on task graph resources and data dependencies

Author: Ipotrick

docs/taskgraph.md

@@ -42,6 +42,42 @@ For this purpose, Daxa has TaskImageViews. A TaskImageView, similarly to an Imag
 
 All Tasks take in views instead of the resources themselves. Resources implicitly cast to the views but have the explicit conversion function `.view()`. Views also have a `.view()` function to create a new view from an existing one.
 
+### Task Resource Data Dependencies
+
+One of the main functions of the task graph is automatically generate sync and to automatically optimize execution by reordering task callbacks and their recorded commands.
+
+To know how to generate sync and when its safe to reorder commands, the tg builds a literl graph of resource uses between the tasks. Based on this graph we can infer optimal ordering and sync.
+
+#### Usage Implications
+
+when a task is added, tg will immediately form new access dependencies for all resources assigned to attachments of that task. 
+
+Example:
+
+`TaskA(write Img0), TaskB(read Img0, write Img1), TaskC(read Img1)`
+Here, TaskB reads img0, tg will see that the TaskA writing Img0 was recorded before TaskB. Tg will form a write -> read dependency when adding TaskB, forcing TaskB to be executed AFTER TaskA. Same for TaskC to TaskB. This leaves the only execution order:
+`TaskA -> TaskB -> TaskC`
+
+
+`TaskA(write Img0), TaskB(read Img0, write Img1), TaskC(write Img2), TaskD(read Img2)`
+In this example there is no dependency between TaskC to A and B, no dependency between TaskD to A and B. This allows task graph to move the execution of TaskC and TaskD earlier, this will reduce the number of barriers.
+`TaskA TaskC -> TaskB TaskD`
+
+Dependencies are always formed immediately when a task is added based on the given task resource views.
+
+### Concurrent Access
+
+Sometimes it is undesirable that two tasks that write the same resource form a `write -> write` order depdendency. For example it could be the case that TaskA writes the left half of an image and TaskB the right half or that the access is synchronized via atomics.
+
+Tg will form dependencies here per default. To avoid this, use a concurrent task access for all tasks that you want to allow them to execute at the same time.
+
+Example:
+`TaskA(write ImgA), TaskB(concurrent write ImgA), TaskC(concurrent write ImgA), TaskD(write ImgA), 
+Likely execution order generated by tg:
+`TaskA -> TaskB TaskC -> TaskD`
+
+Notice here that there are still dependencies formed to writes not marked as concurrent. So while B and C execute together, A and D form strong ordering dependencies to the concurrent writes.
+
 ## Task
 
 The core part of any render graph is the nodes in the graph. In the case of Daxa, these nodes are called tasks.