Small corrections.

1 files changed, 64 insertions, 34 deletions

diff --git a/linuxgraphicsdrivers.lyx b/linuxgraphicsdrivers.lyx
index 03bbdb4..b89bff1 100644
--- a/linuxgraphicsdrivers.lyx
+++ b/linuxgraphicsdrivers.lyx
@@ -346,11 +346,11 @@ name "cha:A-Look-at"
 
 \begin_layout Standard
 Before diving any further into the subject of graphics drivers, we need
- to understand the hardware which is at play.
+ to understand the graphcs hardware.
  This chapter is by no means intended to be a complete description of all
- inner workings of your average computer and its graphics hardware, but
- only as an introduction thereof.
- The goal of this section is to 
+ the inner workings of your average computer and its graphics hardware,
+ but only as an introduction thereof.
+ The goal of this section is just to 
 \begin_inset Quotes eld
 \end_inset
 
@@ -358,12 +358,12 @@ cover the bases
 \begin_inset Quotes erd
 \end_inset
 
- on what will be required later on.
- Notably, most hardware concepts that will subsequently be required are
- introduced here.
+ on the knowledge we will require later on.
+ Notably, most hardware concepts that will subsequently be needed are introduced
+ here.
  Although we sometimes have to go through architecture-specific hoops, we
  try to stay as generic as possible and the concepts detailed thereafter
- generalize well.
+ should generalize well.
 \end_layout
 
 \begin_layout Section
@@ -1653,7 +1653,7 @@ There are 3 caching modes, usable both through MTRR and PAT on system memory:
 
 \begin_layout Itemize
 UC (UnCached) memory is uncached.
- No CPU read/writes to this area are cached, and each memory write instruction
+ CPU read/writes to this area are uncached, and each memory write instruction
  triggers an actual immediate memory write.
  This is helpful to ensure that information has been actually written so
  as to avoid CPU/GPU race conditions.
@@ -1784,8 +1784,8 @@ It is not uncommon for modern GPUs to feature a form of virtual memory as
  page by page, with the ability of picking system and dedicated video memory
  pages at will.
  The similarity of these with a CPU virtual address space is very striking,
- in fact you can have accesses to unmapped pages be signaled to you through
- an interrupt and act on this in a video memory page fault handler.
+ in fact unmapped page access can be signaled to the system through an interrupt
+ and acted upon in a video memory page fault handler.
  However, be careful playing with those as the implication here is that
  driver developers have to juggle with multiple address spaces from the
  CPU and GPU which are going to be fundamentally different.
@@ -1872,7 +1872,7 @@ tiled
 \emph default
 .
  The exact layout of a tiled surface is highly dependent on the hardware,
- but is usually a form of space-filling curve like the Z curve or hilbert's
+ but is usually a form of space-filling curve like the Z curve or Hilbert's
  curve.
 \end_layout
 
@@ -2679,7 +2679,11 @@ Programming the card
 \end_layout
 
 \begin_layout Standard
-Each PCI card exposes a number of PCI resources; lspci -v lists these resources.
+Each PCI card exposes a number of PCI resources; 
+\emph on
+lspci -v
+\emph default
+ lists these resources.
  These can be, but are not limited to, BIOSes, MMIO ranges, video memory
  (or only some part of it).
  As the total PCI resource size is limited, oftentimes a card will only
@@ -2700,9 +2704,13 @@ MMIO is the most direct access to the card.
  to the GPU.
  This allows the simplest for of communication of commands from the CPU
  to the GPU.
- This type of programming is synchronous, so writes are done by the CPU
- and executed on the GPU in a lockstep fashion This results in sub-par performan
-ce as each access turns into a packet on the bus.
+ This type of programming is synchronous; writes are done by the CPU and
+ executed on the GPU in a lockstep fashion.
+ This leads to sub-par performance because each access turns into a packet
+ on the bus and because the CPU has to wait for previous GPU commands to
+ complete before submitting subsequent commands.
+ For this reason MMIO is only used in the non-performance critical paths
+ of today's drivers.
 \end_layout
 
 \begin_layout Subparagraph*
@@ -2758,7 +2766,7 @@ Display devices (aka screens)
 \end_layout
 
 \begin_layout Standard
-Display devices are the last ring of the graphics chain.
+Display devices are the last link of the graphics chain.
  They are charged with presenting the pictures to the user.
 \end_layout
 
@@ -3361,6 +3369,12 @@ end{tikzpicture}
 \begin_inset Caption
 
 \begin_layout Plain Layout
+\begin_inset CommandInset label
+LatexCommand label
+name "fig:Early-implementation-of"
+
+\end_inset
+
 Early implementation of the Linux graphics stack using Utah-GLX.
 \end_layout
 
@@ -3378,8 +3392,15 @@ Early implementation of the Linux graphics stack using Utah-GLX.
 Obviously, this model had drawbacks.
  First, it required that unprivileged user space applications be allowed
  access the graphics hardware for 3D.
- Second, as can be seen on figure XXX all GL acceleration had to be indirect
- through the X protocol, which would slow it down.
+ Second, as can be seen on Figure 
+\begin_inset CommandInset ref
+LatexCommand ref
+reference "fig:Early-implementation-of"
+
+\end_inset
+
+ all GL acceleration had to be indirect through the X protocol, which would
+ slow it down.
  Because of growing concerns about the security in Linux and performance
  shortcomings, another model was required.
 \end_layout
@@ -3388,7 +3409,7 @@ Obviously, this model had drawbacks.
 To address the reliability and security concerns with the Utah-GLX model,
  the DRI model was put together; it was used in both XFree86 and its successor,
  X.Org.
- This model relies on a additional kernel component whose duty is to check
+ This model relies on an additional kernel component whose duty is to check
  the correctness of the 3D command stream, security-wise.
  The main change is now that instead of accessing the card directly, the
  unprivileged OpenGL application would submit command buffers to the kernel,
@@ -4001,22 +4022,31 @@ At the core, a framebuffer driver implements the following functionality:
 \end_layout
 
 \begin_layout Itemize
-modesetting
+Modesetting.
+ Modesetting consists in configuring video mode to get a picture on the
+ screen.
+ This includes choosing the video resolution and refresh rates.
 \end_layout
 
 \begin_layout Itemize
-basic 2d acceleration (copy, solid)
-\end_layout
-
-\begin_layout Standard
-Acceleration is sometimes made available to user space through a hook (user
- space must then program card specific bits, must be root for that)
-\end_layout
-
-\begin_layout Standard
-Framebuffer drivers do not always rely on a specific card model (like nvidiafb/a
-tyfb...).
- Drivers on top of vesa, EFI or Openfirmware exist.
+Optional 2d acceleration.
+ Framebuffer drivers can provide basic 2D acceleration used to accelerate
+ the linux console.
+ These operations include copies in video memory and solid fills.
+ Acceleration is sometimes made available to user space through a hook (the
+ user space must then program card specific MMIO registers, and this requires
+ root privileges).
+\end_layout
+
+\begin_layout Standard
+By implementing only these two pieces, framebuffer drivers remain the simplest
+ and most amenable form of linux graphics drivers.
+ Framebuffer drivers do not always rely on a specific card model (like nvidia
+ or ATI).
+ Drivers on top of vesa, EFI or Openfirmware exist; instead of accessing
+ the graphics hardware directly, these drivers call firmware functions to
+ achieve modesetting and 2D acceleration.
+ 
 \end_layout
 
 \begin_layout Standard
@@ -4397,7 +4427,7 @@ Takeaways:
 
 \begin_layout Itemize
 Framebuffer drivers are the simplest form of linux graphics driver, requiring
- little work for implementation.
+ little implementation work.
 \end_layout
 
 \begin_layout Itemize