More small changes.

1 files changed, 42 insertions, 30 deletions

diff --git a/linuxgraphicsdrivers.lyx b/linuxgraphicsdrivers.lyx
index 6706013..d6be3b6 100644
--- a/linuxgraphicsdrivers.lyx
+++ b/linuxgraphicsdrivers.lyx
@@ -712,7 +712,6 @@ The first user of the bus is the CPU.
  Today, all graphics cards feature this ability (named DMA bus mastering)
  which consists in the card requesting and subsequently taking control of
  the bus for a number of microseconds.
- 
 \end_layout
 
 \begin_layout Standard
@@ -2688,7 +2687,8 @@ reference "fig:Blitting-between-two"
  This operation is defined by the following parameters: the source and destinati
 on coordinates, the source and destination pitches, and the blit width and
  height.
- However, this is only 2D coordinates, no perspective is possible
+ However, this is limited to 2D coordinates, usually no perspective or transform
+ation is possible with a blitting engine.
 \end_layout
 
 \begin_layout Standard
@@ -2924,6 +2924,8 @@ reference "fig:Overlapping-blit-inside"
  Some cards will determine the blitting direction automatically according
  to surface overlap (for example nvidia GPUs), and others will not, in which
  case this has to be handled by the driver.
+ This is why some GPUs actually support negative pitches in order to tell
+ the 2D engine to go backwards.
 \end_layout
 
 \begin_layout Standard
@@ -3176,9 +3178,10 @@ Forward renderers
 \lang english
 Forward renderers (i.e.
  classical renderers) are GPU which render the primitives as they are submitted
- to the rendering API, and for each of those complete one of these primitives
- before moving on to the next.
+ to the rendering API, and for each of those primitives it is drawn entirely
+ before moving on to the next one.
  This is the most straightforward way of rendering 3D primitives.
+ This is the approach used in most desktop-range GPUs.
 \end_layout
 
 \begin_layout Subsubsection*
@@ -3244,8 +3247,8 @@ Deferred Renderers
 \begin_layout Standard
 Deferred renderers are a different design for GPUs.
  Instead of rendering each 3D primitive as it is submitted by the rendering
- API, the driver stores it in memory and then issues a single hardware call
- to render the whole scene.
+ API, the driver stores it in memory and when it notices the end of a frame,
+ it issues a single hardware call to render the whole scene.
  This has a number of advantages over classic architectures:
 \end_layout
 
@@ -3423,8 +3426,11 @@ DRI : bypassing encapsulation for performance-critical operations with kernel
 
 \lang english
 The Linux graphics stack has seen numerous evolutions over the years.
- The purpose of this section is to detail that history, as well as the justifica
-tion behind the changes in order to better motivate the current design.
+ The purpose of this section is to detail that history, as well as give
+ the justification behind the changes which have been made over the years.
+ Today, the design is still strongly rooted in that history, and this section
+ will explain that historyto better motivate the current design of the Linux
+ graphics stack.
 \end_layout
 
 \begin_layout Section
@@ -3688,11 +3694,15 @@ reference "cha:Framebuffer-Drivers"
 ) were getting increasingly widespread, and represented another component
  that could simultaneously access the graphics hardware directly.
  To avoid potential conflicts between the framebuffer and XFree86 drivers,
- it was decided that VT switches would emit a signal to the X server telling
- it to save the graphics hardware state.
+ it was decided that on VT switches the kernel would emit a signal to the
+ X server telling it to save the graphics hardware state.
  Asking each driver to save its complete GPU state on VT switches made the
  drivers more fragile, and life became more difficult for developers who
  suddenly faced bug-prone interaction between different drivers.
+ Keep in mind that there were at least two possibilities for XFree86 drivers
+ (xf86-video-vesa and a native XFree86 driver) and two possibilities for
+ kernel framebuffer drivers (vesafb and a native framebuffer driver), so
+ each GPU had at least four combinations of cohabitating drivers.
 \end_layout
 
 \begin_layout Standard
@@ -3946,7 +3956,7 @@ Early implementation of the Linux graphics stack using Utah-GLX.
 \lang english
 Obviously, this model had drawbacks.
  First, it required that unprivileged user space applications be allowed
- access the graphics hardware for 3D.
+ to access the graphics hardware for 3D.
  Second, as can be seen on Figure 
 \begin_inset CommandInset ref
 LatexCommand ref
@@ -3955,7 +3965,8 @@ reference "fig:Early-implementation-of"
 \end_inset
 
  all GL acceleration had to be indirect through the X protocol, which would
- slow it down.
+ slow it down significantly, especially for data-intensive functions like
+ texture uploads.
  Because of growing concerns about the security in Linux and performance
  shortcomings, another model was required.
 \end_layout
@@ -3975,7 +3986,8 @@ To address the reliability and security concerns with the Utah-GLX model,
  The advantage of this model is that trusting user space is no longer required.
  Notice that although this would have been possible, the 2D command stream
  from XFree86 still did not go through the DRM, and therefore the X server
- still required super-user privileges.
+ still required super-user privileges to be able to map the GPU registers
+ directly.
 \end_layout
 
 \begin_layout Standard
@@ -4233,8 +4245,8 @@ The old picture of the Linux graphics stack.
 
 \lang english
 The current stack evolved from a new set of needs.
- First, requiring the X server to have super-user has always had serious
- security implications.
+ First, requiring the X server to have super-user privileges always had
+ serious security implications.
  Second, with the previous design different drivers were touching a single
  piece of hardware, which would often cause issues.
  In order to resolve this the key is two-fold: first, merge the kernel framebuff
@@ -5132,7 +5144,7 @@ Implementing acceleration is optional as software fallback functions exist.
 \begin_layout Chapter
 
 \lang english
-The DRM Kernel Module
+The Direct Rendering Manager
 \begin_inset CommandInset label
 LatexCommand label
 name "cha:The-DRM-Kernel"
@@ -5153,40 +5165,40 @@ The use of a kernel module is a requirement in a complex world.
 \begin_layout Itemize
 
 \lang english
-Share the rendering hardware between multiple user space components, and
- arbitrate access.
+Put critical initialization of the card in the kernel, for example uploading
+ firmwares or setting up DMA areas.
 \end_layout
 
 \begin_layout Itemize
 
 \lang english
-Enforce security by preventing applications from performing DMA to arbitrary
- memory regions, and more generally programming the card in any way that
- could result in a security hole.
+Share the rendering hardware between multiple user space components, and
+ arbitrate access.
 \end_layout
 
 \begin_layout Itemize
 
 \lang english
-Manage the memory of the card, by providing video memory allocation functionalit
-y to user space.
+Enforce security by preventing applications from performing DMA to arbitrary
+ memory regions, and more generally from programming the card in any way
+ that could result in a security hole.
 \end_layout
 
 \begin_layout Itemize
 
 \lang english
-More recently, DRM was improved to achieve modesetting.
- This simplifies the situation where both the DRM and the framebuffer driver
- access the same GPU by removing the framebuffer driver and instead implementing
- framebuffer support in the DRM.
+Manage the memory of the card, by providing video memory allocation functionalit
+y to user space.
 \end_layout
 
 \begin_layout Itemize
 
 \lang english
-Put critical initialization of the card in the kernel, for example uploading
- firmwares or setting up DMA areas.
- 
+More recently, the DRM was improved to achieve modesetting.
+ This simplifies the previous situation where both the DRM and the framebuffer
+ driver were fighting to access the same GPU.
+ Instead, the framebuffer driver is removed and instead framebuffer support
+ is implemented in the DRM.
 \end_layout
 
 \begin_layout Standard