Run codespell over docs and comments
Spelling fixes reported by running codespell over docs and sources.
This commit is contained in:
parent
fe8094b597
commit
e6473a6edc
12 changed files with 30 additions and 30 deletions
|
|
@ -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];
|
||||
|
|
|
|||
|
|
@ -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")
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue