summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAlan Coopersmith <alan.coopersmith@sun.com>2012-09-17 11:27:51 +0200
committerStéphane Marchesin <marcheu@chromium.org>2012-10-08 15:30:34 -0700
commit2a9547ff1a3f72db7353600bf853eeb82537b261 (patch)
tree81f78a42a982e2f615f49dc42f89de3721cc8a1b
parent9e27d83954a7f226fc5d04901e8c3976c9cf1a8d (diff)
Fix typos/use english spelling
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
-rw-r--r--linuxgraphicsdrivers.lyx24
1 files changed, 12 insertions, 12 deletions
diff --git a/linuxgraphicsdrivers.lyx b/linuxgraphicsdrivers.lyx
index 2edadac..9d41af7 100644
--- a/linuxgraphicsdrivers.lyx
+++ b/linuxgraphicsdrivers.lyx
@@ -266,7 +266,7 @@ reference "cha:X.Org-Drivers"
\end_inset
) focuses on X.Org drivers and the existing acceleration APIs available to
- the developper.
+ the developer.
Video decoding sees its own dedicated part in Chapter
\begin_inset CommandInset ref
LatexCommand ref
@@ -1332,7 +1332,7 @@ ns from the other party can begin.
\lang english
The second feature is AGP side band addressing (SBA).
Side band addressing consists in 8 extra bus bits used as an address bus.
- Instead of multiplexing the bus bandwidth between adresses and data, the
+ Instead of multiplexing the bus bandwidth between addresses and data, the
nominal AGP bandwidth can be dedicated to data only.
This feature is transparent to the driver developer.
\end_layout
@@ -1418,7 +1418,7 @@ memory
\begin_inset Quotes erd
\end_inset
- has to two main different acceptions:
+ has two main different meanings:
\end_layout
\begin_layout Itemize
@@ -1825,8 +1825,8 @@ Obviously, with so many different memory types, performance is not homogeneous;
not all combination of accesses are fast, depending on whether they involve
the CPU, the GPU, or bus transfers.
Another issue which arises is memory coherence: how can one ensure that
- memory is coherent accross devices, in particular that data written by
- the CPU is availble to the GPU (or the opposite).
+ memory is coherent across devices, in particular that data written by
+ the CPU is available to the GPU (or the opposite).
These two issues are correlated, as higher performance usually means a
lower level of memory coherence, and vice-versa.
\end_layout
@@ -2093,7 +2093,7 @@ Surfaces
\lang english
Surfaces are the basic sources and targets for all rendering.
- Althought they can be called differenty (textures, render targets, buffers...)
+ Although they can be called differently (textures, render targets, buffers...)
the basic idea is always the same.
Figure
\begin_inset CommandInset ref
@@ -5520,10 +5520,10 @@ When the GPU features hardware state tracking, the hardware sharing is simpler
\lang english
When the GPU doesn't have multiple hardware contexts, the common way of
- multiplexing the hardware is to reemit the state at the beggining of each
+ multiplexing the hardware is to reemit the state at the begining of each
batch buffer; it's the way the intel and radeon drivers multiplex the GPU.
Note that this duty of reemitting the state relies on user space entirely.
- If the user space doesn't reemit the state at the beggining of each batch
+ If the user space doesn't reemit the state at the begining of each batch
buffer, the state from other DRM processes will leak onto it.
\end_layout
@@ -5984,7 +5984,7 @@ begin{lstlisting}{}
\begin_layout Plain Layout
-/Bool LeaveVT(int scrnIndex, int flags);
+Bool LeaveVT(int scrnIndex, int flags);
\end_layout
\begin_layout Plain Layout
@@ -6769,7 +6769,7 @@ end{lstlisting}{}
\begin_layout Subsubsection*
\lang english
-DowndloadFromScreen
+DownloadFromScreen
\end_layout
\begin_layout Standard
@@ -9086,7 +9086,7 @@ Winsys
The winsys is in charge of talking to the OS/Platform of choice.
The pipe driver relies on the Winsys to talk to the hardware.
For example, this allows having a single pipe driver with multiple winsyses
- targetting different Operating systems.
+ targeting different Operating systems.
\end_layout
\begin_layout Section
@@ -9508,7 +9508,7 @@ Virtualization
\lang english
Finally, one last pre-existing tool to help reverse engineering is virtualizatio
n.
- By running a proprietary driver in a controled environment, one can figure
+ By running a proprietary driver in a controlled environment, one can figure
out the inner workings of a GPU.
The plan is then to write an emulated GPU while doing the reverse engineering
(which imposes the use of an open source virtualization solution like Qemu).