minor changes to section 5.1 only

1 files changed, 39 insertions, 40 deletions

diff --git a/linuxgraphicsdrivers.lyx b/linuxgraphicsdrivers.lyx
index 8071316..8ad801e 100644
--- a/linuxgraphicsdrivers.lyx
+++ b/linuxgraphicsdrivers.lyx
@@ -5216,8 +5216,8 @@ y to user space.
 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.
+ Instead, the framebuffer driver has been removed and framebuffer support
+ is implemented from within the DRM.
 \end_layout
 
 \begin_layout Standard
@@ -5445,16 +5445,16 @@ One of the duties of the DRM is to multiplex the GPU itself between multiple
  user space processes.
  
 \lang american
-Given that the GPU holds graphics state, a problem arises when multiple
+Given that the GPU holds the graphics state, a problem arises when multiple
  applications use the same GPU: if nothing is done, the applications can
  stomp over each other's state.
- Depending on the hardware at hand, there are two major cases:
+ Depending on the hardware, there are two main cases:
 \end_layout
 
 \begin_layout Itemize
 When the GPU features hardware state tracking, the hardware sharing is simpler
- since each application can send to a separate context, and the GPU tracks
- each application's state itself.
+ since each application can send to a separate context, and the GPU itself
+ tracks each application's state.
  This is the way the nouveau driver works.
 \end_layout
 
@@ -5466,13 +5466,13 @@ When the GPU doesn't have multiple hardware contexts, the common way of
  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 begining of each batch
- buffer, the state from other DRM processes will leak onto it.
+ buffer, the state from other DRM processes will leak into it.
 \end_layout
 
 \begin_layout Standard
 
 \lang english
-The DRM also prevent simultaneous access to the same hardware.
+The DRM also prevents simultaneous access to the same hardware.
 \end_layout
 
 \begin_layout Subsection
@@ -5486,22 +5486,22 @@ Memory management and security
 \lang english
 The kernel has the ability to move memory areas around to handle high memory
  pressure situations.
- Depending on the hardware, there are two ways to achieve it:
+ Depending on the hardware, there are two ways to do this:
 \end_layout
 
 \begin_layout Itemize
 If the hardware has complete memory protection and virtualization, then
- it is possible to page in memory resources into the GPU as they get allocated
+ it is possible to page memory resources into the GPU as they get allocated
  and isolate them per-process.
- Therefore not much is required to support memory protection of GPU memory.
+ In this case not much is required to support memory protection for GPU
+ memory.
 \end_layout
 
 \begin_layout Itemize
 
 \lang english
 When the hardware doesn't have memory protection, this can still be achieved
- entirely in the kernel, in a way where the user space is completely oblivious
- to it.
+ entirely in the kernel, transparently to user space.
  In order to allow relocations to work for a user space process which is
  otherwise unaware of them, the command submission ioctl will rewrite the
  command buffers in the kernel by replacing all the hardware offsets to
@@ -5516,7 +5516,7 @@ To prevent access to arbitrary GPU memory, the command submission ioctl
  can also check that each of these offsets is owned by the calling process,
  and reject the batch buffer if it isn't.
  That way it is possible to implement memory protection when the hardware
- doesn't provide that functionality.
+ doesn't provide the functionality.
  Although there is some overhead for doing command buffer parsing, it is
  bearable, and this is how the open source radeon drivers work.
 \end_layout
@@ -5528,19 +5528,19 @@ GEM Buffer management
 \begin_layout Standard
 GPU buffer allocation and management is done in the kernel and exposed to
  the userspace through the GEM interface.
- Such buffer is then called an object or a buffer object (BO).
+ The resulting buffer is then called an object or a buffer object (BO).
 \end_layout
 
 \begin_layout Standard
-GEM has been introduced by Intel in 2008 to simplify Tungsten Graphics'
- TTM (Translation Table Maps) and became the standard way to allocate, read,
- write and sharing BOs between applications.
+GEM was introduced by Intel in 2008 to simplify Tungsten Graphics' TTM (Translat
+ion Table Maps) and became the standard way to allocate, read, write and
+ sharing BOs between applications.
  It is however impossible to share buffers between drivers through GEM.
 \end_layout
 
 \begin_layout Standard
-As the GEM interface is driver-dependent, it is advised to use the driver-depend
-ent libdrm calls to manage your buffers.
+As the GEM interface is driver-dependent, it is best to use the driver-dependent
+ libdrm calls to manage your buffers.
  However, the general outline of the interface remains fairly constant.
 \end_layout
 
@@ -5574,7 +5574,7 @@ pread/pwrite : syscalls to read/write to/from a buffer object.
 \end_layout
 
 \begin_layout Itemize
-mapping the BO : it is possible for the userspace to map the BO in his memory
+mapping the BO : it is possible for the userspace to map the BO in its memory
  space.
  Mapping takes the BO offset and size that should be mapped as an argument.
  It then returns the address of the BO in the user's virtual address space.
@@ -5590,27 +5590,27 @@ The GEM interface specifies a way for applications/clients to share buffers.
 \end_layout
 
 \begin_layout Enumerate
-call GEM_FLINK with the handle of the buffer object to be shared.
- An uint32 name will be returned.
+Call GEM_FLINK with the handle of the buffer object to be shared.
+ A uint32 name will be returned.
 \end_layout
 
 \begin_layout Enumerate
-transfer this name to the clients that should access the buffer object
+Transfer this name to the clients that should access the buffer object.
 \end_layout
 
 \begin_layout Enumerate
-the remote clients should open the BO by name by using the GEM_OPEN IOCTL.
+The remote clients should open the BO by name, using the GEM_OPEN IOCTL.
 \end_layout
 
 \begin_layout Standard
 By default, no buffers are shared between clients.
  However, when one buffer is shared, any authenticated client can read/write
- to the BO.
+ the BO.
  No access control is done between authenticated clients.
 \end_layout
 
 \begin_layout Standard
-A client is said to be authenticated if his euid is 0 (root) or if an already-au
+A client is said to be authenticated if its euid is 0 (root) or if an already-au
 thenticated client added this client to the authenticated-clients list.
 \end_layout
 
@@ -5619,16 +5619,16 @@ The procedure to authenticate a non-root client is:
 \end_layout
 
 \begin_layout Enumerate
-get a magic cookie from the dri interface (drm_getmagic)
+Get a magic cookie from the dri interface (drm_getmagic).
 \end_layout
 
 \begin_layout Enumerate
-send the magic cookie to an already-authenticated client
+Send the magic cookie to an already-authenticated client.
 \end_layout
 
 \begin_layout Enumerate
-the authenticated client calls drm_authmagic to authenticate the cookie
- and thus, the original client
+The authenticated client calls drm_authmagic to authenticate the cookie
+ and thus the original client.
 \end_layout
 
 \begin_layout Subsubsection*
@@ -5636,8 +5636,8 @@ Learning more about GEM
 \end_layout
 
 \begin_layout Standard
-The best documentation for GEM is the source code the drivers exposing it
- (libdrm for the userspace, the drm driver for the kernelspace).
+The best documentation for GEM is the source code of the drivers exposing
+ it (libdrm for userspace, the drm driver for kernelspace).
  However, it is worth reading the initial proposal called 
 \begin_inset CommandInset href
 LatexCommand href
@@ -5665,9 +5665,9 @@ DMA-Buf is a driver-independent buffer-sharing mechanism for clients.
 \begin_layout Standard
 
 \lang english
-Contrarily to GEM buffer sharing, a fd is returned to the client willing
+Unlike GEM buffer sharing, with DMA-Buf a fd is returned to the client willing
  to export a buffer.
- It is then the client's responsability to export this fd to the other clients
+ It is then the client's responsibility to export this fd to the other clients
  using a UNIX socket as explained by this 
 \begin_inset CommandInset href
 LatexCommand href
@@ -5677,16 +5677,15 @@ target "http://archives.neohapsis.com/archives/postfix/2000-09/1476.html"
 \end_inset
 
 .
- This sharing solution is more secure since clients cannot access to buffers
- unless explicitely allowed by the exporter contrarily to GEM where names
- are guessable.
+ This sharing solution is more secure since clients cannot access buffers
+ unless explicitly allowed by the exporter, whereas with GEM names are guessable.
 \end_layout
 
 \begin_layout Standard
 
 \lang english
-For more information, look at /Documentation/dma-buf-sharing.txt in your
- kernel tree.
+For more information, see /Documentation/dma-buf-sharing.txt in your kernel
+ tree.
 \end_layout
 
 \begin_layout Section