Run codespell over docs and comments

Spelling fixes reported by running codespell over docs and sources.
This commit is contained in:
Philipp Zabel 2020-10-25 13:05:28 +01:00
parent fe8094b597
commit e6473a6edc
12 changed files with 30 additions and 30 deletions

View file

@ -16,7 +16,7 @@ Index
Asynchronous & Parallel Operations <overview/async-parallel>
Memory Management Principles <overview/memory-management>
Converting GLSL/HLSL Shaders to C++ Headers <overview/shaders-to-headers>
Mobile App Intergration (Android) <overview/mobile-android>
Mobile App Integration (Android) <overview/mobile-android>
Game Engine Integration (Godot Engine) <overview/game-engine-godot>
Code Index <genindex>

View file

@ -276,7 +276,7 @@ Back to `examples list <#simple-examples>`_.
// Here we can do other work
// We can now wait for thw two parallel tasks to finish
// We can now wait for the two parallel tasks to finish
mgr.evalOpAwait("queueOne")
mgr.evalOpAwait("queueTwo")
@ -415,7 +415,7 @@ Converting to Kompute Terminology
1. Create a Sequence to record and submit GPU commands
2. Submit OpCreateTensor to create all the tensors
3. Record the OpAlgo with the Logistic Regresion shader
3. Record the OpAlgo with the Logistic Regression shader
4. Loop across number of iterations:
4-a. Submit algo operation on LR shader
4-b. Re-calculate weights from loss
@ -454,10 +454,10 @@ Converting to Kompute Terminology
#. Record the OpAlgo with the Logistic Regresion shader
#. Record the OpAlgo with the Logistic Regression shader
:raw-html-m2r:`<del>~</del>`\ :raw-html-m2r:`<del>~</del>`\ :raw-html-m2r:`<del>~</del>`\ :raw-html-m2r:`<del>~</del>`\ ~~
Once we re-record, all the instructions that were recorded previosuly are cleared.
Once we re-record, all the instructions that were recorded previously are cleared.
Because of this we can record now the new commands which will consist of the following:
@ -526,7 +526,7 @@ Because of this we can record now the new commands which will consist of the fol
// Run evaluation which passes data through shader once
sq->eval();
// Substract the resulting weights and biases
// Subtract the resulting weights and biases
for(size_t j = 0; j < bOut->size(); j++) {
wInVec[0] -= wOutI->data()[j];
wInVec[1] -= wOutJ->data()[j];

View file

@ -69,7 +69,7 @@ Sequences can be executed in synchronously or asynchronously without having to c
While this is running we can actually do other things like in this case create the shader we'll be using.
In this case we create a shader that shoudl take a couple of milliseconds to run.
In this case we create a shader that should take a couple of milliseconds to run.
.. code-block:: cpp
:linenos:
@ -164,7 +164,7 @@ Let's take a tangible example. The [NVIDIA 1650](http://vulkan.gpuinfo.org/displ
With this in mind, the NVIDIA 1650 as of today does not support intra-family parallelization, which means that if you were to submit commands in multiple queues of the same family, these would still be exectured synchronously.
However the NVIDIA 1650 does support inter-family parallelization, which menas that if we were to submit commands across multiple queues from different families, these would execute in parallel.
However the NVIDIA 1650 does support inter-family parallelization, which means that if we were to submit commands across multiple queues from different families, these would execute in parallel.
This means that we would be able to execute parallel workloads as long as we're running them across multiple queue families. This is one of the reasons why Vulkan Kompute enables users to explicitly select the underlying queues and queue families to run particular workloads on.
@ -281,7 +281,7 @@ We are able to wait for the tasks to complete by triggering the `evalOpAwait` on
// Here we can do other work
// We can now wait for thw two parallel tasks to finish
// We can now wait for the two parallel tasks to finish
mgr.evalOpAwait("queueOne")
mgr.evalOpAwait("queueTwo")